Android各种IPC机制的合适使用场景

广播

广播适合于消息发布等发送者与接受者弱关联的场景，发送者不太关心接受者是否以及何时接收到，也不关心有多少个接受者，它只管发出消息。接受者类似，不关心何时发来广播，大多也不关心是谁发送的，只管接收特定类型的消息

Content Provider

Content Provider适合于对外统一提供增删改查数据的接口，不过一般是查询，因为对方不一定可信（可用权限控制），也是弱关系对应，查询者指定uri拥有权限就能查到数据。现在不少开发者也使用该方法提供IPC 调用方法，使用call调用，优点是使用简洁，但主线程调用容易引起ANR，因为被调用者进程可能未启动，需要先调起；这种方法就不如AIDL先bindService的方法，被调用者在被绑定时就会启动

Messenger

这也是一种使用方法简单的IPC机制，它基于Binder和Handler实现。Messenger能与一个Handler建立关联并向他发送消息，Messenger类自带了一个方法getBinder()。我们需要在Service中定义一个Handler，决定Service如何响应消息，然后将Messenger跟Handler关联，这样其他组件就能通过Messenger向Service发送消息了。

AIDL

标准的IPC机制，调用者和被调者 都需要定义aidl文件，生成可用于IPC的Service文件。。。。[待完善]
调用者可以注册对被调者的死亡代理，这样在被调者进程被杀时也可以收到通知，进行相应处理，如再次bind调起被调者。

后两者对比

Messenger和AIDL都是直接使用Binder机制实现的。以上四种均是基于Binder实现的。关于广播请参考详解基于Binder的BroadcastReceiver && 基于Handler的LocalBroadcastManager
所有对Messenger发送的消息都集中到了一个线程中处理，因此也不会有线程安全之类的问题需要考虑。
而AIDL使用的binder线程池，消息是在多个线程中处理。
另外，Messenger相对AIDL功能要弱一些，大多使用在同一个app的不同进程中，而AIDL无论是否在同一个app都常使用。

SP和File等文件存储的方式

涉及较多IO操作，时间效率较低，不建议使用在对实时性要求高的场景。
SP一般也是针对同一app的不同进程可以共享数据，若不同app的不同进程因文件目录权限问题无法共享