为什么AOSP需要Mock回放框架？

做AOSP测试久了，你会发现一个很扎心的事实：回归测试跑一遍，半天就没了。不是代码编译太慢，是刷机、烧录、环境准备把时间都吃掉了。

我自己在适配某款海外机型时，遇到过这样的场景——一个WiFi扫描的bug，每次复现要：

• 连上真实的AP热点（信号还得稳定）
• 等GPS锁星（机库环境下死活锁不住）
• 调用一次WifiManager.startScan()
• 等HAL层回传扫描结果（有时超时，有时返回空）

嗯，你算算，一个单用例跑完要2分钟。而当时我们有3000多个类似的集成测试用例……全量跑一遍，就是100个小时。你能接受吗？反正我不能。

这就是为什么我们需要Mock回放框架。说白了，就是把真实的系统行为“录下来”，然后在没有硬件、没有网络的环境里“放回去”，让被测组件以为自己还在跟真设备打交道。

它解决了三个核心痛点

痛点	传统测试	Mock回放
环境依赖	必须有真实硬件、GPS、传感器、外设	任意Linux/Mac环境，连adb都不需要
时间成本	每次刷机+重启+初始化 > 5分钟	拉起进程只需毫秒级，无刷机
结果确定性	依赖信号强度、电量、干扰，每次结果可能不同	回放相同数据，结果完全可复现

我之前踩过一个坑：某次夜间构建里的WiFi扫描测试挂了，但第二天白天手动重跑又过了。折腾了两天，最后发现是晚上机房里AP固件自动升级了，导致HAL层返回的扫描结果格式有细微差异。这种依赖外部环境的“阴晴不定”，最让人抓狂。

框架到底长什么样？

先给你一张图，看下整体结构。这张图我画了很多版本，最后定稿这个，你应该一秒就能看懂。

你仔细看这张图：录制器拦截真实设备上的Binder调用、HAL回调、系统服务广播，序列化到存储库里；回放器则在无设备的CI环境中，读取这些数据，以同样的顺序、同样的参数、同样的返回值“喂”给被测组件。最后断言器比对实际输出和预期输出，找出差异。

我在项目里怎么用？

给你讲个真实经历。去年我们做Android 14 CTS兼容性测试，WiFi模块有一项“P2P服务发现”的用例，依赖两台真实手机配对。但实验室只有两台特定机型，每天被不同团队抢占。那个用例的通过率只有60%——不是因为代码有问题，而是因为设备不稳定。

后来我用Mock回放框架，在一台正常工作的手机上录制了5次P2P服务发现的完整调用序列（包括WifiP2pManager.discoverServices、回调onPeersAvailable、onConnectionInfoAvailable等），存为YAML文件。然后在任意一台Linux机器上回放，被测组件完全感知不到区别。那次之后，这个用例的通过率变成了100%，而且每次跑只花了0.3秒。

你以为只是提速？还有更重要的

我见过的团队，往往只把Mock回放当成“加速工具”。其实它更大的价值在于测试确定性和故障隔离。

举个例子：某个服务收到一个畸形Intent，导致系统UI崩溃。传统做法你得去抓取logcat，分析上下文，重现条件。有了回放框架，你直接把触发崩溃的那组Intent参数录制下来，交给开发——他拉下来，本地回放，一秒复现。还可以反复回放、逐步调试，直到修复。

曾经有个同事花了三天定位一个悬浮窗权限问题，最后发现是ActivityManagerService内部某个flag位的默认值在不同系统版本上不一致。要是当时有Mock回放框架，他只需要对比录制下来的两个版本的行为序列，一眼就能看出差异在哪里。

框架的整体组成一览

为了方便你后面跟着课程动手搭建，我把整个框架拆成几个模块。后面每一章都会深入一个模块。

模块	职责	你会学到
Proxy 代理层	拦截系统调用与回调	AIDL动态代理、反射hook
Serializer 序列化器	将调用参数转为可存储格式	Protocol Buffers / JSON 自定义序列化
Storage 持久化层	管理录制数据文件	文件索引、增量录制
Player 回放引擎	按顺序调度并注入模拟结果	时间轴控制、异常注入
Assertion 校验器	比对实际输出与预期	结构化diff、模糊匹配

本章小结

Mock回放框架，本质上是在“可重复”和“可控制”之间搭了一座桥。录制阶段，你得到的是真实世界的一次快照；回放阶段，你得到的是隔离环境下的精确还原。这两个动作加起来，让AOSP测试从“拼人品”变成了“拼数据”。