第二章IPC机制（Android开发艺术探索）

1.Bundle传递数据实现IPC（当然传递的类型必须要bundle支持）

特殊情况：传递的数据类型Bundle不支持的情况（即无法通过intent传输），

这种情况可以考虑：我们通过A进程中的Intent启动B进程的Service（比如intentService）来进行执行，执行完后再启动B进程中的目标组件

2.使用文件共享实现IPC（要注意并发读写的问题）

在windows上面，一个文件加了排斥锁，其他线程就无法访问

但是：android 是基于linux，并发读写文件无限制

附：反序列和序列化的内容是一样的，但是是2个对象

SharedPreferences在内存中有一份文件缓存

所以在多进程模式下，系统对它的读写就变的不可靠，面对高并发的读写访问，它有很大几率丢失数据，

所以不建议在进程间通信中使用SharedPreferences

3.使用Messenger实现IPC（信使,）

Messenger是串行的方式处理客户端的消息，如果有大量的并发请求就不太合适了，

messenger的作用主要是传递消息，并不能实现跨进程方法的调用

实Messenger是对aidl进行了封装，只能发消息使用

4. 使用AIDL实现IPC

有一点要注意：客户端在onDestroy方法中解除注册到服务端的listener的时候，会出现can not unregister的情况，

原因是：对象是不能跨进程传输的，跨进程传输本质就是反序列化的过程，

这也是为什么AIDL的自定义对象都必须实现Parcelable接口的原因。

可以使用RemoteCallbackList：是系统专门提供的用于删除跨进程listener的接口（key，value的形式保存listener）

注意：

1.客户端调用远程服务的时候，如果远程方法比较耗时，那么客户端会出现ANR

解决：

避免在客户端的UI主线程中访问远程方法

2.同理，远程服务端调用客户端的耗时方法时，服务端也不要再UI线程中调用

3.如果服务端意外停止了（服务端的Binder可能意外死亡），那么客户端需要重新连接服务

方法1：服务端的Binder死亡，会收到binderDied方法的回调，我们在这个方法中重连

方法2：在onServiceDisconnected重连

两种方法的区别：

onServiceDisconnected在主线程，可以直接回调后进行ui操作

binderDied在客户端的binder线程池中回调，不能直接访问ui

AIDL权限验证：

默认情况下，远程服务任何人都可以连接

方法1：在onBind中验证，比如使用permission方式，在menifest中注册

方法2：在服务端的onTransact方法中验证

5.使用ContentProvider实现IPC

是android间专门用于不同应用间进行数据共享的方式，和messenger一样，底层是binder

6.使用socket实现IPC

socket的理解：

快递员：socket

数据发送过程：

1.产生socket

2.调用bind将socket的信息通知给驱动程序

3.应用程序把数据传给socket

4.驱动程序从socket中取出数据并通知网卡发送出去

接受数据过程：

1.产生socket

2.调用bind将socket的信息通知给驱动程序

3.驱动程序根据从网卡传送过来的数据报中”指定的目标端口号“，将处理的数据传送到相应的socket中，应用程序从socket中取数据

Binder连接池

AIDL:最常见的进程间通信方式

AIDL使用：

1.创建service接口，AIDL接口

2.创建一个类，继承AIDL接口中的Stub类，并实现抽象方法

3.在Service的onBind方法中返回这个类的对象

4.客户端绑定服务端的service，建立连接后就可以访问服务端的方法了

但是如果公司项目庞大，可能创建很多个service

解决方法：binderPool机制

1.一个业务一个AIDL

2.向服务端提供唯一标识和binder对象；服务端只需要一个service就好

3.服务端提供一个queryBinder接口，此接口返回相应的binder对象

binder连接池的作用：把每个业务模块的binder请求统一转发到远程service，这样避免重复创建service

选择合适的IPC方式

1.Bundle：优点：简单易用  缺点：只能传输Bundle支持的数据类型 使用场景：四大组件间的进程通信

2.文件共享：优点：简单易用 缺点：不适合高并发的情况，并且无法做到进程间的即时通讯 使用场景：无并发访问情况下，交换简单的数据实时性不高的情况

3.AIDL：优点：功能强大,支持一对多并发通信，支持实时通讯  缺点：需要处理好线程同步 使用场景：一对多通信且有Rpc需求

4.Messager：优点：支持一对多串行通信，支持实时通讯 缺点：不能很好处理高并发情况，不支持Rpc，数据通过Message进行传输，因此只能传输Bundle支持的数据类型 使用场景：低并发的一对多即时通信,无Rpc需求，或者无需返回结果的Rpc需求

5.ContentProvider ：优点：在数据源访问方面功能强大,支持一对多并发数据共享，可通过call方法扩展其他操作(call在源码编译下可调用http://blog.csdn.net/luoshengyang/article/details/6950440) 缺点：主要提供数据源的Crud 使用场景：一对多的进程间数据共享

6.Socket： 优点：功能强大,可以通过网络传输字节流，支持一对多并发实时通讯 缺点：实现细节有点繁琐，不支持直接的Rpc

来源： <http://blog.csdn.net/q178266871/article/details/50394486>