第2章 IPC 机制

通过本章的阅读，我们首先知道，不同进程之间内存不共享，这会带来下面几个问题。

（1）静态成员和单例模式完全失效。
（2）线程同步机制完全失效。
（3）SharedPreferences的可靠性下降。
（4）Application会多次创建。

跨进程会带来众多的问题，而有时我们的APP中某些模块又必须运行在单独进程中，所以我们更加要去了解跨进程通信中的细节。

接着，作者给我们介绍了Android中的两种对象序列化方式，分别是Serializable和Parcelable，Serializable实现起来比较简单，它更加适应于将对象序列化后存储在文件中或者通过网络进行传输，Parcelable实现起来较麻烦一些，但在内存层面进行操作效率更高。

了解过对象序列化之后，是本章的重头戏，也是Android中跨进程最重要的实现方式——Binder。在Binder这一小节中，作者并未深入介绍Binder的底层实现，而是讲解了Binder的上层使用，我们知道了Binder使用时分为服务端和客户端，一般情况下它们位于不用的进程中，服务端实现具体的功能，然后通过Binder将自身的代理传递给客户端，客户端通过服务端的代理调用服务端的方法，完成跨进程通信。除了Binder的具体使用之外，中间还介绍了使用linkToDeath给服务设置一个死亡代理，监听服务的连接情况。客户端调用Binder服务端方法后线程会处于挂起状态，而在服务端Binder运行在Binder线程池中，可以直接运行耗时任务，所以要留意避免客户端ANR。Android提供的Binder，极大的方便了我们在APP中实现跨进程通信。

介绍完Binder的使用之后，作者紧接着总结了Android上各种跨进程实现方式，这里直接摘抄书中的表格。其中Messenger，ContentProvider底层本身就是使用Binder进行跨进程通信。

IPC方式的优缺点和适用场景.png

最后，当APP的需求慢慢变得复杂，需要进行大量跨进程通信时，我们不可能为每个通信都创建一个服务，所以作者给我们介绍了Binder连接池。服务端只存在一个服务，在服务中存在一个单例的Binder连接池具体实现对象，客户端连接服务端时，服务端将此对象返回给客户端，客户端拿到连接池的实现Binder，调用连接池的相应查询方法，来获取具体需要通信业务的Binder。这样后面如果需要增加新的跨进程通信需求，只需要创建新的AIDL接口，修改连接池的查询方法即可。