Messenger 相比 AIDL 有哪些优缺点？适用于什么场景？
解读
国内面试中，Binder 通信是“必考高频”。面试官抛出 Messenger vs AIDL，并不是想听“哪个更快”，而是看候选人能否把“IPC 原理 + 工程成本 + 可维护性 + 国内真实环境”串成闭环。答得越贴近国内项目痛点（多人协作、需求变更快、线上崩溃零容忍），越能拿高分。
知识点
- Binder 内核：Client/Server 通过 ioctl(BINDER_WRITE_READ) 完成一次拷贝；Messenger 与 AIDL 最终都走这条通路，差异在“调用形态”而非“底层通道”。
- Messenger 本质：服务端创建一个 Handler，客户端拿到 Binder 后只发 Message，底层把 Handler 的 callback 序列化成 IMessenger.Stub，属于“单向、无接口定义、无多线程并发”的轻量封装。
- AIDL 本质：开发者手写 .aidl 接口，编译器生成 Stub/Proxy，支持同步/异步、in/out/inout 定向 tag、多线程并发回调，属于“面向接口”的完整 RPC。
- 国内常见坑：
‑ 多进程微信分享、支付、推送，任何 ANR 或 DeadObjectException 都会被应用市场投诉“闪退”；
‑ 国内 ROM 对后台进程限制极狠，Binder 线程池被系统回收后，AIDL 远程调用会抛 RemoteException，必须自己重连；
‑ 代码混淆后 AIDL 接口改名，若客户端与服务端版本不一致，会出现“方法不存在”的 IllegalArgumentException，而 Messenger 只依赖 int what，兼容性好。
答案
“Messenger 与 AIDL 的优缺点，我习惯从‘开发成本、并发能力、版本兼容、调试难度’四个维度对比，再给出国内真实场景选型。”
- 开发成本
‑ Messenger：无需写 .aidl，服务端只需 new Handler()，客户端拿到 IBinder 后直接 send(Message)，10 行代码即可跑通；需求变更时，只改 int what 与 Bundle key，适合国内敏捷迭代。
‑ AIDL：需要维护 .aidl 文件，跨模块/跨团队时，必须把接口下沉到独立模块，否则出现“接口循环依赖”编译错误；每次新增字段要同步升级客户端，版本碎片化严重。 - 并发能力
‑ Messenger：内部绑定一个 Handler，所有请求串行进入 MessageQueue，天然线程安全，但也意味着“并发高”会阻塞；一次大数据传输（>1 MB）就会触发 TransactionTooLargeException。
‑ AIDL：Binder 线程池默认 16 条线程，支持同步并发回调；可通过 inout 参数一次性传递大对象，也可注册死亡通知，适合复杂双向调用。 - 版本兼容
‑ Messenger：只依赖 int what 与 Bundle，Bundle 支持带默认值，新老版本兼容“零成本”；国内多渠道包升级节奏不一，这一点尤其重要。
‑ AIDL：新增接口方法必须写在新 .aidl，老客户端调新方法会抛 IllegalArgumentException；国内厂商 ROM 对后台保活限制严格，一旦服务端被杀，AIDL 需要重连逻辑，否则 crash 上报里全是 RemoteException。 - 调试难度
‑ Messenger：调用栈被 Handler 包装，Systrace 只能看到“Binder 通信”，定位问题需手动埋点；
‑ AIDL：编译期生成 Stub/Proxy，崩溃栈能直接看到接口签名，方便排查。
适用场景结论
选 Messenger：轻量级、单向、低并发、需求变化快，如“音乐播放服务”对外暴露播放/暂停/进度三条指令，或“推送 SDK”给第三方应用发简单事件。
选 AIDL：需要双向回调、并发高、数据量大，如“车载 IVI 系统”中导航应用与系统服务之间实时传输地图数据，或“银行 SDK”需要同步返回加密结果，且团队有能力维护接口版本。
一句话总结：国内项目若“团队人手紧、版本碎片化严重、接口生命周期短”，优先 Messenger；若“性能瓶颈在 IPC、需要并发回调、团队有专职框架层维护”，再考虑 AIDL。
拓展思考
- 国内“无后台”限制下，Binder 链路被杀后如何自恢复？
‑ 可在 Service onBind 返回 Stub 的同时，把进程优先级提升到 FOREGROUND_SERVICE，并采用 WorkManager 周期性绑定，降低被系统回收概率；
‑ 对 AIDL 场景，把接口设计为“无状态幂等”，客户端捕获 DeadObjectException 后重新 bind 并做重试令牌，防止重复扣款等业务事故。 - 混合方案：Messenger + AIDL 双通道
‑ 主通道用 Messenger 保活，维持轻量级心跳；大数据或双向回调时，通过 Messenger 把“真正的 AIDL 接口 Binder”一次性传过去，兼顾兼容与性能，国内大型音乐 SDK 已落地。 - 未来趋势：
‑ Android 14 收紧“前台服务”权限，Binder 调用将被系统统计“电池用量”，届时无论 Messenger 还是 AIDL，都需迁移到官方推荐的“前台服务 + 用户可见通知”模型；
‑ 车载场景下 Google 主推 AIDL HAL 接口（Vehicle HAL），国内厂商在 AOSP 之上再包一层 Messenger 做权限校验，形成“双 Binder”架构，面试中若能提及，可体现对“系统层 + 应用层”贯通的理解。