4. ANR日志定位：从traces.txt提取主线程栈，识别无障碍服务阻塞点

4.1 现象识别

当SystemUI因无障碍服务（Accessibility Service）回调发生ANR（Application Not Responding）时，典型现象包括：用户触摸反馈延迟超过5秒、通知栏无法下拉、快速设置面板卡死、系统界面弹出“SystemUI无响应”对话框。在日志中，关键识别特征如下：

• 主线程长时间阻塞：traces.txt中SystemUI主线程处于RUNNABLE或BLOCKED状态，停留时间超过ANR阈值（默认5秒）。
• 栈顶指向无障碍框架：堆栈顶层方法属于android.accessibilityservice或com.android.internal.accessibility包。
• Binder调用等待：常见阻塞模式为等待AccessibilityManagerService的Binder响应，或AccessibilityService的onAccessibilityEvent回调未及时返回。
• 频繁连续触发：无障碍事件（如内容变化、窗口状态切换）高频产生，导致主线程事件队列积压。

4.2 数据采集

ANR发生时，Android会dump所有进程的线程堆栈到/data/anr/traces.txt。采集步骤如下：

1. 触发ANR场景：通过Monkey测试或手动操作复现无障碍服务卡死。
2. 抓取traces文件：使用adb命令拉取最新dump。

adb shell ls -lt /data/anr/
adb shell cat /data/anr/traces.txt > systemui_traces.txt

若SystemUI多用户场景，需确认进程UID，使用ps -A | grep systemui定位PID，再从traces.txt中筛选对应线程组。

4.3 原因定位

使用故障树分析（FTA）方法，逐层排查无障碍服务阻塞的根因。标准判断规则如下：

• 规则1（主线程栈检查）：在SystemUI的主线程（“main”线程）堆栈中，若发现以下任意模式，标记为无障碍阻塞疑点：
  • android.app.ActivityThread.handleServiceArgs → AccessibilityService.onServiceConnected → 耗时初始化
  • AccessibilityInteractionClient.findFocus → Binder通信等待 → 超时未返回
  • View.dispatchPopulateAccessibilityEvent → 父视图链遍历耗时
• 规则2（阻塞线程判断）：检查traces.txt中是否存在“Blocked”或“Waiting”状态的辅助线程，这些线程若持有主线程需要的锁，会导致间接阻塞。
• 规则3（事件频率分析）：在logcat中搜索AccessibilityEvent的日志频率，若每秒触发超过30次且处理函数未完成，判定为事件洪泛导致主线程饥饿。

典型ANR阻塞堆栈示例：

"main" prio=5 tid=1 Blocked
  at com.android.server.accessibility.AccessibilityManagerService$RemoteAccessibilityConnection.getSourceNodeId(AccessibilityManagerService.java:1825)
  - waiting to lock <0x0b7c2d1> (a com.android.server.accessibility.AccessibilityManagerService$RemoteAccessibilityConnection)
  at android.view.accessibility.AccessibilityInteractionClient.findAccessibilityNodeInfoByAccessibilityId(AccessibilityInteractionClient.java:345)
  at android.view.View.getRecord(View.java:16544)
  at android.view.View.dispatchPopulateAccessibilityEvent(View.java:11502)
  at android.widget.LinearLayout.dispatchPopulateAccessibilityEvent(LinearLayout.java:285)
  at android.widget.ListView.dispatchPopulateAccessibilityEvent(ListView.java:1630)
  at android.widget.AbsListView.onLayout(AbsListView.java:2199)
  at android.widget.LinearLayout.onLayout(LinearLayout.java:410)
  at android.view.View.layout(View.java:17212)
  at android.view.ViewGroup.layout(ViewGroup.java:5896)
  at android.widget.FrameLayout.layoutChildren(FrameLayout.java:331)
  at android.widget.FrameLayout.onLayout(FrameLayout.java:268)
  at com.android.systemui.statusbar.phone.PhoneStatusBarView.onLayout(PhoneStatusBarView.java:310)
  at android.view.View.layout(View.java:17212)
  at android.view.ViewGroup.layout(ViewGroup.java:5896)
  at android.widget.LinearLayout.setChildFrame(LinearLayout.java:174)
  at android.widget.LinearLayout.layoutVertical(LinearLayout.java:1581)
  at android.widget.LinearLayout.onLayout(LinearLayout.java:410)
  at android.view.View.layout(View.java:17212)
  at android.view.ViewGroup.layout(ViewGroup.java:5896)
  at android.widget.FrameLayout.layoutChildren(FrameLayout.java:331)
  at android.widget.FrameLayout.onLayout(FrameLayout.java:268)
  at android.view.View.layout(View.java:17212)
  at android.view.ViewGroup.layout(ViewGroup.java:5896)
  at com.android.systemui.statusbar.phone.StatusBarWindowView.onLayout(StatusBarWindowView.java:130)
  at android.view.View.layout(View.java:17212)
  at android.view.ViewGroup.layout(ViewGroup.java:5896)
  at android.widget.FrameLayout.layoutChildren(FrameLayout.java:331)
  at android.widget.FrameLayout.onLayout(FrameLayout.java:268)
  at android.view.ViewRootImpl.performLayout(ViewRootImpl.java:2609)
  at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:2348)
  at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:1493)
  at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:7136)
  at android.view.Choreographer$CallbackRecord.run(Choreographer.java:918)
  at android.view.Choreographer.doCallbacks(Choreographer.java:722)
  at android.view.Choreographer.doFrame(Choreographer.java:651)
  at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:906)
  at android.os.Handler.handleCallback(Handler.java:871)
  at android.os.Handler.dispatchMessage(Handler.java:99)
  at android.os.Looper.loop(Looper.java:171)
  at android.app.ActivityThread.main(ActivityThread.java:6755)
  at java.lang.reflect.Method.invoke(Native Method)
  at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1455)
  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1345)

此堆栈显示主线程在getSourceNodeId中因等待锁而阻塞，阻塞点位于AccessibilityManagerService内部，锁持有者为同一进程内另一个线程中的RemoteAccessibilityConnection对象。

4.3.1 判断规则表

4.4 修复动作

根据定位到的阻塞模式，采取针对性修复：

• 锁竞争优化：将临界区中不依赖锁的代码移出同步块；若无障碍服务回调需要异步处理，使用Handler.post或AsyncTask将耗时操作剥离到工作线程。
• Binder超时处理：为无障碍服务绑定函数设置超时机制，超过一定阈值（如200ms）则断开Binder连接或弃用请求，防止无限等待。
• 事件节流：在AccessibilityService的onAccessibilityEvent实现中加入限频逻辑，同一类型事件间隔小于100ms时合并处理或丢弃。示例代码片段：

// 在AccessibilityService子类中实现节流
private long lastEventTime = 0;
private static final long THROTTLE_INTERVAL_MS = 100;

@Override
public void onAccessibilityEvent(AccessibilityEvent event) {
    long now = SystemClock.uptimeMillis();
    if (now - lastEventTime < THROTTLE_INTERVAL_MS) {
        return; // 丢弃高频重复事件，防止主线程拥塞
    }
    lastEventTime = now;
    // 实际的异步处理逻辑
    new Handler(getMainLooper()).post(() -> handleEventAsync(event));
}

private void handleEventAsync(AccessibilityEvent event) {
    // 移至后台线程处理，不阻塞主线程
}

4.5 复测验证

修复后通过以下步骤验证ANR是否消除：

1. 压力复现：使用adb shell monkey -p com.android.systemui --pct-touch 70 --throttle 50 5000模拟高频操作，同时开启无障碍服务。
2. 日志监控：在logcat中过滤“ANR”和“systemui”，确认无新ANR产生。
3. 堆栈对比：若再出现traces.txt，对比修复前阻塞点（如锁等待、Binder等待）是否消失。
4. 自动化断言：编写CTS测试用例，通过AccessibilityService.getWindows()等方式触发事件，断言主线程响应时间小于500ms。

4.6 预防方案

• 开发阶段：在SystemUI的代码审查流程中加入无障碍服务性能检查项，禁止在主线程中直接调用无障碍框架的阻塞接口。
• 监控告警：部署性能监控系统，对ANR阈值（如5秒）使用StrictMode检测主线程中的无障碍相关磁盘I/O或网络请求。
• 架构设计：为无障碍事件处理设计独立的工作线程队列，将onAccessibilityEvent的回调处理移出主线程，通过HandlerThread隔离耗时操作。