Android Binder由Client/Service/ServiceManager用户态组件和Binder驱动内核组件构成，通信需通过Binder驱动间接实现，Service需先注册于ServiceManager。常见问题包括误认为进程直接共享内存、跨进程传递对象需Parcel序列化、服务未注册导致的查找失败。Messenger基于Binder封装消息式通信，服务端通过Handler处理Message队列，客户端可通过 IBinder.replyTo 建立双向通信链路，但仅支持单线程串行调用且数据需序列化为Message/Bundle。适用场景对比： Binder/AIDL适合复杂RPC（多方法带返回值、并发调用），Messenger适合低频异步通知（如状态推送），双向通信需主动传递replyTo avoiding并发。 生死通知需关注IBinder.linkToDeath实现监听，服务退出会触发链接死亡回调，需重新绑定。丢消息问题需分层排查：首先确认进程绑定成功，再核对Message.what类型，多客户端共用一个Messenger时需自行协议消息归属。三种 IPC 方式差异：AIDL适合高频复杂调用，Messenger适合简单异步通知，直接使用 Binder驱动需编写C++服务管理逻辑，实际开发中较少独立调用。开发时应根据调用频次、接口复杂度及线程模型选择合适方案， Messenger应避免携带大对象数据。

在 Android 里，我们每天都在用 Binder。 你调用 startActivity()，背后会走 Binder； 你调用 getSystemService()，背后会拿到 Binder 代理； 你访问 ActivityManagerService、PackageManagerService、