3. AOSP通信机制：Binder、Handler、Service

做AOSP测试框架，绕不开这三兄弟——Binder、Handler、Service。说白了，整个Android系统的“骨架”就是靠它们撑起来的。你要Mock回放，就得先把它们怎么通信、怎么调度、怎么绑定搞清楚。不然你写出来的Mock方案，很容易在真实设备上崩得一塌糊涂。

3.1 Binder：跨进程的“快递员”

Binder是Android里最核心的IPC机制。几乎所有跨进程调用，背后都是Binder在跑。我刚开始接触AOSP时，一直觉得Binder很玄乎——不就是个远程调用嘛？后来踩了坑才明白，它的设计思路和传统Linux IPC完全不同。

• 一次拷贝：传统IPC（如Socket、管道）需要两次数据拷贝（用户态→内核态→用户态），而Binder只需要一次，性能高不少。
• C/S架构：Client发起请求，Service提供服务，Binder驱动负责中转。每个Service都有一个唯一的标识（handle）。
• 引用计数：Binder对象有强引用和弱引用，跨进程传递时不会乱释放。

举个例子，你在测试框架里Mock一个系统服务，实际上就是接管了那个Service的Binder接口。我建议你在做回放之前，先把目标Service的Binder接口走一遍，用ServiceManager.getService()拿到真实的Binder对象，然后序列化它的调用数据。

// 获取真实Binder对象
IBinder binder = ServiceManager.getService("window");
// 解析接口描述符
String descriptor = binder.getInterfaceDescriptor();
// 记录每次transact调用
Parcel data = Parcel.obtain();
Parcel reply = Parcel.obtain();
int code = TRANSACTION_ADD_WINDOW;
binder.transact(code, data, reply, 0);
// 把data和reply存起来，后面回放用

3.2 Handler：线程间的“邮递员”

Handler是Android里线程通信的基础。为什么需要它？因为UI线程不允许阻塞，也不允许非UI线程直接更新UI。Handler+Looper+MessageQueue这三件套，构成了一个消息驱动模型。

我记得有一次写自动化测试，要模拟用户点击事件。直接用InputManager.injectInputEvent()发现事件没被处理，折腾了半天——原来是因为事件是在测试线程发的，而目标窗口的Handler绑定的是主线程Looper，消息队列没对上。后来我手动把事件post到主线程Handler里，问题就解决了。

在Mock回放框架里，Handler的回放尤其容易出问题。为什么呢？因为时间敏感。真实场景中，Handler消息有when字段，表示延迟时间。回放时如果忽略这个时间，可能会导致状态不一致。

3.3 Service：系统能力提供者

Service在Android里分两种：系统服务（System Service）和应用服务。我们搞测试框架，主要打交道的是系统服务——比如ActivityManagerService、WindowManagerService、PackageManagerService等等。