4. 基线建立：在无TalkBack时测量应用渲染帧率与触控响应时间

本阶段的核心目标是获取应用在无障碍服务完全关闭时的性能底数，为后续TalkBack集成后的对比提供量化依据。基线数据必须排除系统辅助功能的干扰，仅反映应用自身渲染管线与触摸处理路径的真实表现。

4.1 现象识别：无TalkBack下的性能偏差

许多团队在入场测试时未关闭系统无障碍服务，导致基线数据被污染。典型现象包括：

• 帧率曲线在无用户交互时仍出现间歇性抖动（通常来自无障碍扫描线程）。
• 触控响应时间偏大（≥150ms），但实际Android InputDispatcher并无瓶颈。
• Profile GPU Rendering显示“命令缓冲”阶段耗时异常升高。

4.2 数据采集：双指标测量协议

分别在无TalkBack环境下采集以下两个核心指标：

# 开启帧统计
adb shell dumpsys gfxinfo <package> framestats

# 输出最近128帧的耗时（单位ns）
# 关注 draw / prepare / process / execute 阶段

# 记录触控事件从输入到应用的延迟
adb shell dumpsys input latency

# 或使用自动化触摸+截图时间戳法
adb shell monkey --pct-touch 100 -v 1 > monkey.log

4.3 基线建立流程（SVG）

4.4 原因定位：基线异常的可能根因

若基线数据不达标，需按以下优先级定位：

1. 系统级干扰：检查是否开启“开发者选项”中的“显示GPU视图更新”或“严格模式”，这些会额外增加渲染开销。
2. 后台进程：使用adb shell top -n 1 | grep surfaceflinger确认SurfaceFlinger线程是否被其它服务抢占。
3. 省电策略：部分设备在省电模式下会将GPU频率锁定在低档位，导致帧率翻车。

# 检查当前帧率（持续20秒）
adb shell dumpsys gfxinfo <package> | grep "Total frames" -A 10

# 检查触控延迟历史
adb shell dumpsys input --latency

4.5 修复动作：建立干净的测试环境

• 关闭所有无障碍服务：在系统设置 → 无障碍 → 已安装的应用中逐个关闭，或通过ADB强制重置：

# 关闭所有无障碍服务（需root权限）
adb shell settings put secure enabled_accessibility_services null
adb shell settings put secure accessibility_enabled 0

• 重启SurfaceFlinger（仅调试机可用）：

adb shell stop surfaceflinger
adb shell start surfaceflinger

• 固定CPU/GPU频率（可选，用于极端稳定基线）：

# 示例（需root）
echo "performance" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

4.6 复测验证：数据一致性校验

完成环境清理后，至少重复采集3次，每次间隔1分钟，取中位数作为最终基线：

# 自动脚本示例 (bash)
for i in 1 2 3; do
  adb shell dumpsys gfxinfo com.example.app framestats >> baseline_$i.txt
  sleep 60
done

验证标准：

• 帧率标准差 ≤ 1.5 fps。
• 触控响应时间中位数波动 ≤ 10 ms。
• 如果数据波动大，需检查Wi-Fi扫描、后台同步等周期性任务。

4.7 预防方案：将基线采集纳入CI/CD