报告生成时间： 2026年4月14日
日志文件名称： WeChat-2026-04-14-203830.log

一、 基本信息与环境

二、 崩溃摘要与关键信息

核心崩溃原因：
系统看门狗 (Watchdog) 检测到微信主线程在处理场景更新 (scene-update) 时，耗时超过了 10.00 秒 的时间限额，因此强制终止了应用。此行为属于典型的“主线程卡死”导致的 Watchdog 崩溃。

关键日志片段：

"exception": {"type":"EXC_CRASH","signal":"SIGKILL"}
"termination": {
  "namespace": "FRONTBOARD",
  "reasons": [
    "<RBSTerminateContext| domain:10 code:0x8BADF00D explanation:scene-update watchdog transgression: app<com.tencent.xin>:45865 exhausted real (wall clock) time allowance of 10.00 seconds",
    "ProcessVisibility: Foreground",
    "WatchdogEvent: scene-update"
  ]
}

0x8BADF00D 是一个经典的 Watchdog 超时代码，读作 “Ate Bad Food”。

三、 主线程堆栈分析 (卡死位置)

崩溃时，主线程正忙于处理应用场景（Scene）的生命周期变化，从堆栈看，该变化是 willResignActive（即将进入非活跃状态，如退到后台、锁屏或下拉通知栏）。

关键调用栈回溯：

0   libsystem_kernel.dylib         kevent_id + 8
1   libdispatch.dylib              _dispatch_kq_poll + 220
2   libdispatch.dylib              _dispatch_event_loop_wait_for_ownership + 460
...
5   WeChat                         (大段 WeChat 内部调用)
6   CoreFoundation                 __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 128
...
14  UIKitCore                      -[_UISceneLifecycleMonitor willResignActive] + 140
...

分析结论：

1. 主线程正在处理一个同步的 (_dispatch_sync_f_slow)、与 UISceneLifecycleMonitor 相关的通知。
2. 具体触发点是 willResignActive 通知。微信注册的某个观察者 (Observer) 在处理此通知时执行了耗时极长或造成死锁的操作。
3. 主线程在 kevent_id 系统调用处阻塞，这通常意味着它在等待某个同步操作的锁释放或 I/O 完成，但该操作在后台迟迟未能返回。

四、 其他线程状态概览

日志显示微信运行时拥有大量活跃线程（超过 150 个），其中多数线程处于 __psynch_cvwait (等待条件变量) 状态。虽然这本身不一定代表问题，但复杂的多线程环境增加了发生死锁的风险。以下是部分有代表性的后台线程：

• 线程 com.apple.uikit.eventfetch-thread: 正常运行，等待系统事件。
• 线程 matrix::*, mars::*, WCDB.*, andromeda::*: 大量微信内部框架的工作线程，大部分处于空闲等待状态。
• 线程 SightCaptureLogicQueue (ID: 6529536): 此线程在崩溃时正试图停止 AVCaptureSession (-[AVCaptureSession stopRunning])，并在等待一个 NSOperation 完成。

五、 潜在原因推测

结合主线程卡在 willResignActive 通知以及后台线程正在停止 AVCaptureSession 的线索，推测崩溃流程如下：

1. 触发动作：用户可能在播放视频、进行视频通话或使用相机相关功能时，直接锁屏、按 Home 键退到后台或下拉了通知中心。
2. 场景变化：系统向微信发送 willResignActive 通知，要求应用暂停 UI 更新和部分活动。
3. 同步等待：微信的某个模块（很可能是音视频或相机相关）在接收到 willResignActive 通知后，尝试同步停止摄像头捕获会话 (AVCaptureSession stopRunning) 或等待其他资源释放。
4. 死锁或超长耗时：stopRunning 操作本身是异步的，或在特定状态下无法立即完成，导致主线程同步等待该操作超时。
5. Watchdog 触发：主线程被阻塞超过 10 秒，无法完成 scene-update 任务，最终被系统 Watchdog 强制终止。

六、 给微信开发团队的建议

1. 优化 willResignActive 处理逻辑：请重点排查 _UISceneLifecycleMonitor willResignActive 的观察者回调。任何在收到 UIApplicationWillResignActiveNotification 通知时执行的操作都应该是轻量级、非阻塞的。
2. 检查音视频模块：特别是 AVCaptureSession 的生命周期管理。stopRunning 方法不应该在主线程同步调用。应考虑将其移到后台队列，并避免主线程等待其完成。请检查 SightCaptureLogicQueue 线程的逻辑，确保其不会反向阻塞主线程。
3. 审查同步原语使用：主线程堆栈中的 _dispatch_sync_f_slow 表明存在同步派发，需确认是否存在跨队列的同步等待导致死锁。

备注：
此问题发生在 iOS 26.5 Beta 系统上。虽然 Beta 版系统本身可能存在 Bug，但从 Watchdog 机制和堆栈特征来看，应用侧存在主线程处理不当的可能性极高。建议团队在 iOS 26 环境下对应用进入后台流程进行专项测试。