Android IPC 机制

[zhangsr]

各种 IPC 方式的优缺点和适用场景（参考《Andoid开发艺术探索》，并按自己的理解做了改动）

名称	优点	缺点	适用场景	实例
Bundle	简单易用	只能传输 Bundle 支持的数据类型	Activity、Service、Broadcast 之间单向单次的进程间通信	传参启动 Activity
文件共享	简单易用	（1）不适合高并发场景（2）不适合即时通信	（1）无并发访问（2）不要求实时	SharedPreference
AIDL	（1）支持一对多并发通信（2）实时通信	（1）使用稍复杂（2）需要处理好线程同步	（1）一对多双向并发通信（2）有RPC需求	音乐播放器
Messenger	（1）支持一对多串行通信（2）实时通信	（1）低并发（2）不支持RPC（3）只能传输 Bundle 支持的数据类型	（1）一对多双向低并发通信（2）无RPC或无需返回的RPC
ContentProvider	标准数据共享接口		提供数据共享，包括CRUD操作	通讯录信息
Socket	网络传输	实现繁琐	网络传输	聊天室

其中 AIDL、Messenger、ContentProvider 都是基于 Binder

简化的 Binder 应用层原理图：

调用过程解析

非 IPC：

（1）Client 调用 Stub 接口的方法 A
（2）直接由
（3）Service 中该接口的实现响应。
（4）直接由
（5）Client 方法 A 返回

IPC：

（1）Client 调用 Stub 接口的方法 A
（2）在 Client 端，由 Stub 的内部类 Proxy 响应，并将方法id 和参数序列化，通过 transact 方法传到底层，Client 端线程阻塞。在 Service 端，系统（线程池）回调onTransact 方法，反序列化，并调用不同的 Stub 接口方法。
（3）Service 中该接口的实现响应。
（4）onTransact 方法得到结果并序列化，返回 true 标记成功，transact 方法线程阻塞解除，得到结果并反序列化，返回结果。
（5）Client 方法 A 返回

可以看出来非IPC 与 IPC 的区别只有第（2）（4）步，而这一步的代码是通过 .aidl 文件生成的，也就是系统屏蔽了进程间通信的具体实现，只暴露给开发者（1）（3）（5）三步，使得在开发者的眼里，IPC 就好像在同一个进程中一样，实现起来非常简单。