第1章 无障碍线程架构全景

本章界定AOSP无障碍子系统在Android系统中的位置，从进程、线程维度拆解整体层次结构，明确各核心线程的角色与通信边界。通过一张分层架构图建立全局视角，并深入数据流向、控制信任链路及工程落地要点。

1.1 边界定义

无障碍子系统跨越三个进程边界：

• UI进程（每个应用主进程）—— 生成AccessibilityNodeInfo树，响应触摸/滚动事件。
• 系统服务进程（system_server）—— 运行AccessibilityManagerService（AMS），负责全局调度、窗口管理、注入事件。
• 辅助服务进程（AccessibilityService所在进程）—— 接收被筛选的事件，执行自动化操作或反馈。

线程边界：每个进程的主线程（UI Thread/Service主线程）主导无障碍交互；AMS内部使用独立HandlerThread处理事件路由，避免阻塞主线程。

1.2 分层与组件职责

1.3 关键数据流向与信任链路

1. 输入事件：用户触控 → InputDispatcher → ViewRootImpl（UI线程）
2. 节点推送：UI线程通过Binder将AccessibilityEvent及节点信息发送至AMS。
3. AMS分发：AMS HandlerThread按服务注册的packageNames、eventTypes过滤，通过Binder回调目标AccessibilityService。
4. 服务处理：AccessibilityService主线程收到回调，可再派发到工作线程避免ANR。
5. 信任链路：Binder验证调用方UID；AMS校验服务是否拥有BIND_ACCESSIBILITY_SERVICE权限；节点数据仅允许系统进程或已绑定的服务读取。

1.4 选型权衡

• Binder IPC vs ContentProvider：Binder提供同步/异步双向通信，适合高频率事件流；ContentProvider更重且仅适合数据查询。选择Binder是性能最优解。
• HandlerThread vs ExecutorService：AMS内部使用HandlerThread保证事件顺序处理，避免多线程并发导致状态不一致；辅助服务可选用ExecutorService处理CPU密集型任务，但需自行同步。
• 每应用单进程模型：每个AccessibilityService运行在独立进程中，与UI进程隔离，牺牲部分进程间通信开销，但提升了安全性和稳定性（服务crash不影响应用）。

1.5 风险点

1.6 落地步骤

1. 在AndroidManifest中声明服务并绑定android.permission.BIND_ACCESSIBILITY_SERVICE。
2. 在onAccessibilityEvent()中接收事件；若需耗时处理，立即使用HandlerThread或Executors切换线程。
3. 通过getWindows()或findFocus()获取节点树，提取数据。
4. 使用performAction()执行点击、长按等操作时注意检查isEnabled()和isImportantForAccessibility()。
5. 调用setServiceInfo()动态调整事件过滤，避免接收无关事件浪费CPU。
6. 监控性能：使用StrictMode检测主线程磁盘/网络访问，确保无ANR。

1.7 验收标准