核心特征：调用方向反转。常规RPC由客户端主动调用服务端；回调模式允许服务端主动调用客户端提供的接口，实现双向通信。
#### 1.2 跨进程场景分析
Binder作为Android最核心的IPC（进程间通信）机制，其回调主要解决以下跨进程场景：
| 场景 | 描述 | 典型实例 |
|------|------|----------|
| 异步结果通知 | 服务端执行耗时操作后，不阻塞等待，通过回调返回结果 | 导航路径计算完成后通知地图应用 |
| 进度状态推送 | 服务端持续回调客户端，传递操作进度或状态变化 | 导航过程中实时更新位置、路况 |
| 事件订阅/监听 | 客户端向服务端注册监听器，服务端在事件发生时回调 | 导航避让、电子眼预警 |
| 权限/资源管控 | 跨进程资源申请完成后，回调通知客户端可用 | 车载导航申请TTS语音资源 |
每个跨进程回调场景都依赖Binder驱动的序列化、线程管理和生命周期监护。
#### 1.3 与普通回调的区别
普通回调（同进程）与Binder跨进程回调存在根本性差异：
| 对比维度 | 同进程回调 | Binder跨进程回调 |
|----------|------------|------------------|
| 调用路径 | 纯函数指针/接口引用，直接跳转 | Binder驱动转接，两次IPC |
| 参数传递 | 对象引用传递 | 全量序列化(Parcel)，对象需通过Binder引用 |
| 线程模型 | 调用方线程直接执行 | Binder线程池分发，需关注线程切换 |
| 生命周期 | 轻量，随对象销毁 | 依赖Binder死亡通知和引用管理 |
| 异常处理 | 直接抛异常 | TransactionException, DeadObjectException |
| 性能开销 | 纳秒级 | 微秒~毫秒级，含两次内核切换 |
设计启示：不要试图屏蔽跨进程回调的复杂性。优秀的架构设计应当清晰界定回调的调用线程、序列化约束和生命期契约，而非简单套用同进程回调模式。
#### 1.4 典型导航应用场景
导航应用是Binder跨进程回调的典型复杂场景，客户端（地图UI进程）与服务端（导航引擎进程）通过Binder交互：
- **路径规划回调**：客户端提交起点/终点，服务端异步计算路径，通过回调返回路径点集、距离、时间。
- **导航状态回调**：导航启动后，服务端持续回调当前位置、剩余距离、车道信息、引导箭头指令。
- **避让/预警回调**：服务端检测到限速、事故、电子眼，回调客户端进行预警展示。
- **语音播报回调**：服务端根据导航状态生成播报指令，回调客户端触发TTS引擎播报。
- **用户交互回调**：用户操作（如切换路线）从客户端传递到服务端后，服务端处理完再通过回调通知客户端更新界面。
设计陷阱：导航场景中的回调通常伴随高频推送（每秒多次位置更新）和并发生命周期（导航开启/关闭/重新规划）。忽视回调的线程安全、背压控制和死亡恢复，将直接导致ANR、数据错乱或服务端内存泄漏。
#### 1.5 跨进程回调流程框架
下图展示了Binder跨进程回调在导航场景中的核心通信流程：
**流程图说明：** ① 客户端通过Binder向服务端注册回调接口（传递代理端IBinder）。② 服务端在导航引擎进程中执行逻辑（路径计算、状态监测）。③ 服务端反序列化回调接口，调用客户端提供的方法。④ 客户端在Binder线程池中接收回调，更新UI或触发播报。Binder驱动层全程负责数据序列化、线程分发和生命周期守护。
设计要点：导航场景中的高频回调应使用异步(oneway)模式，避免阻塞服务端工作线程；回调中的UI更新必须切换到主线程处理。