SystemUI 接口 Mock 回放概述
说实话，刚听到「Mock 回放」这个词，很多人第一反应是「测试框架又整新词儿了」。但如果你像我一样在 SystemUI 这摊事儿上折腾过几年，就会明白这个能力有多重要。我记得刚接手某大厂定制 ROM 的 SystemUI 模块时，每天被各种接口返回值不一致搞到头大——信号条显示满格但实际断网、电池电量跳变、通知栏卡顿……后来我花了两周时间做了一套 Mock 回放工具，才真正把调试效率提上来。
今天这一章，我们就聊聊什么是 SystemUI 接口 Mock 回放，它到底能用在哪，以及学完这个课程你能得到什么。
1.1 核心概念：Mock 与回放
| 术语 | 通俗解释 | 我遇到的坑 |
|---|---|---|
| Mock | 模拟真实接口的返回值，不依赖硬件或系统服务 | 曾经直接用真实设备调试，每次都要插拔线、改权限，浪费时间 |
| 回放 | 把预先录制的接口数据按时间顺序重新注入到目标模块 | 第一次写回放脚本时忘了处理时间戳对齐，导致状态乱跳 |
| SystemUI 接口 | SystemUI 内部调用的系统服务、数据源、传感器等 API | 比如 StatusBarPolicy 从 TelephonyManager 读取信号强度 |
你想想看：校验一个信号栏异常，传统方式是拿着真机在弱信号区反复走，或者用 AT 指令模拟。有了 Mock 回放，你只需要录一次弱信号场景的数据，然后无限次回放。说白了，就是把「环境依赖」变成「数据依赖」。
1.2 应用场景：什么时候该用它？
我把它分成四类，这四类基本覆盖了我在项目里碰到的所有痛点：
- 回归测试：SystemUI 模块改动后，快速验证所有状态切换是否正常。比如蓝牙连上后状态栏图标变化，WiFi 信号从强到弱再到断开。
- 紧急问题复现：线上反馈「状态栏卡死」，你只要拿到当时的接口 trace 文件，在实验室里一键回放，比拿着真机跑十遍强太多。
- 性能基准对比：同一个 Mock 数据，跑优化前后的代码，直接对比帧率和内存。
- 多人协作：前端同学不用等底层固件烧录，直接发一份 Mock 数据就能开发 UI 样式。
为什么这三个场景特别适合 Mock 回放？
- 不需要特定硬件（弱信号、高负载）
- 可重复、可回溯、可共享
- 隔离真机噪声（电池温度波动、后台应用干扰等）
我的习惯：每次遇到棘手的 SystemUI 偶发 bug，我会先尝试用 ADB 录一个 5 秒的接口 trace。如果能在本地稳定复现，再开始写 Mock 脚本。这样能省下一半的调试时间。
1.3 课程目标：你能学到什么？
这个课程不是纸上谈兵。我会从零搭建一个完整的 Mock 回放工具链，包括：
- 如何设计接口录制器（不侵入业务代码）
- 如何把复杂的数据结构（如 TelephonyDisplayInfo）序列化为 JSON / Protobuf
- 如何实现时间轴精确回放，保证状态机不跑偏
- 如何在 CI 里集成 Mock 回放做自动化回归
- 实战演练：录制 -> 回放 -> 断言 -> 报告
嗯，这里要强调一点：课程里的所有代码都是我在真实项目中用过并迭代过的，不是 Demo。我会带你踩一遍我当年踩过的坑。
避坑指南：我曾经有个同事，直接拿线上设备的 SystemUI 进程 dump 出来做 Mock 数据，结果因为 private API 行为差异导致回放崩溃。记住，Mock 数据必须来自你「最终要覆盖的那个系统版本」的接口定义，千万别跨 Android 版本用。
1.4 本章知识体系总览
下面的图帮你梳理一整章的核心脉络。你可以把它当作课程地图，之后每一章都会对应到图里的某个节点。
1.5 小结：起步之前想清楚
你可能觉得，直接拿真实设备测不是更直观？没错，但真实测试的缺点是：不可复现、依赖环境、耗时。Mock 回放不是要替代真机测试，而是作为它的补充——当你想把「偶现问题」变成「必然问题」的时候，它就派上用场了。
核心要点回顾
- Mock：接口数据模拟，不依赖硬件
- 回放：按时间序列重放录制数据
- 四大场景：回归、复现、性能、协作
- 课程产出：完整的工具链 + 实战案例