简单的IPC机制学习

IPC 机制

IPC场景：只有在多进程情况下才会考虑使用进程间通信。
给四大组件在AndroidMenifest中指定android:process属性来开启多线程模式

使用android:process(进程)会带来的问题
1、静态成员和单例模式完全失效；
2、线程同步机制完全失效
3、SharedPreferences可靠性下降；
4、Application会多次创建；
Binder的工作机制

Android中的IPC方式
Bundle
文件共享（一般使用文件读写来实现共享，不建议使用系统的SharedPreferences）
Messenger（轻量级IPC，底层依然是AIDL）工作原理（Page70 & 代码）

AIDL
4.1. AIDL支持的数据类型：
基本数据类型（int、long、char、boolean、double等）；
String和CharSequence；
List只支持ArrayList，里面每个元素都必须被AIDL支持；
Map只支持HashMap，里面每个元素都必须被AIDL支持（包括key和value）；
Parcelable 所有实现了Parcelable接口对象；
AIDL接口本身；
4.2. 服务端可以使用CopyOnWriteArrayList和ConcurrentHashMap来进行自动线程同步，客户端拿到的依然是ArrayList和HashMap；
4.3. 服务端和客户端之间做监听器，服务端需要使用RemoteCallbackList，否则客户端的监听器无法收到通知（因为服务端实质还是一份新的序列化后的监听器实例，并不是客户端那份）；
dd. 客户端调用远程服务方法时，因为远程方法运行在服务端的binder线程池中，同时客户端线程会被挂起，所以如果该方法过于耗时，而客户端又是UI线程，会导致ANR，所以当确认该远程方法是耗时操作时，应避免客户端在UI线程中调用该方法。同理，当服务器调用客户端的listener方法时，该方法也运行在客户端的binder线程池中，所以如果该方法也是耗时操作，请确认运行在服务端的非UI线程中。另外，因为客户端的回调listener运行在binder线程池中，所以更新UI需要用到handler。
4.4. 客户端通过IBinder.DeathRecipient来监听Binder死亡，也可以在onServiceDisconnected中监听并重连服务端。区别在于前者是在binder线程池中，访问UI需要用Handler，后者则是UI线程。
4.5. 可通过自定义权限在onBind或者onTransact中进行权限验证。

ContentProvider
ContentProvider底层实现也是Binder ，ContentProvider我们都很熟悉了但是它的细节还是很多的，比如CRUD操作、防止SQL注入和权限控制等。
ContentProvider使用表的形式来组织数据无论数据的来源是什么，ContentProvider都会认为是一种表，然后把数据组织成表格
ContentProvider提供的方法
　　 query：查询
　　 insert：插入
　　 update：更新
　　 delete：删除
　　 getType：得到数据类型
　　 onCreate：创建数据时调用的回调函数
每个ContentProvider都有一个公共的URI，这个URI用于表示这个ContentProvider所提供的数据。Android所提供的ContentProvider都存放在android.provider包当中

Socket （套接字）一般用于网络通信，AIDL用这种方式会过于繁琐，不建议。

Binder连接池，通过BinderPool的方式将Binder的控制与Service本身解耦，同时只需要维护一份Service即可。这里用到了CountDownLatch，大概解释下用意：线程在await后等待，直到CountDownLatch的计数为0，BinderPool里使用它的目的是为了保证Activity获取BinderPool的时候Service已确定bind完成