其实真的搞清楚了安卓四大组件的应用场景了吗

其实经历这么多年来的安卓方面的开发，最后的感觉是，它太自由了，要实现一件事，可用的方式太多了。四大组件中除了Activity需要用来UI交互，这个无可厚非，如果说到进程间的通讯，方式可多了。

举个例子：我想在APP之间同步一些状态或数据，你觉得用什么方式合适？ 

1、广播；

2、Messenger；

3、AIDL；

4、ContentProvider；

甚至还可以用SharedPreference（虽然这个跨进程共享方式已经被安卓废弃）；

1、刚开始接触安卓，就觉得广播最好用了，简单的很，一两句话就把数据发出去了，简单粗暴，但其实在以上4个方式中，广播是对系统开销最大的一个。只能适用于场景：尽量少发，避免频繁，这个消息需要多方知道，而且不需要关心谁先收到，甚至不关心谁没有收到（那是你接收方的事）。

第2第3、Messenger和AIDL效率相差不多，跨进程偶合度最低，都是基于Binder通讯，Messenger是单线程处理消息队列的，只能异步返回，AIDL则是多线程处理事务的，但它是同步返回的（调用者会等到它返回结果），在实现接口里需要注意处理多线程安全方面。如果需要有长时间实时性的数据传输，当然推荐AIDL去自己实现接口了，如果是频繁的一些事件消息，就推荐使用Messenger，比AIDL方便嘛。

4、ContentProvider也是很方便，它也是基于Binder通讯，但它并不像AIDL来的那么直接，而且通过system server的ContentProvider管理服务去绕了一圈，一次query的流程开销比service AIDL调用开销大多了，最近做项目，就发现，有的地方需要频繁query一个内存中的int变量（共享的状态变量），一次query就要花掉几百ms，相当可怕，这情况就最好避免用ContentProvider了，我理解ContentProvider仅适用于不需要频繁获取的数据共享。我说它方便，是因为它本身就有数据变化通知的功能，就不需要自己操心去回调通知了。

以上说的aidl 和messager的方式耦合度低，其实有没有想过，还有个方式耦合度更低的，那就是system service，如果做过安卓系统层的开发，需要开发个一直运行于系统中的deamon，那么以system service的方式是最妥了。因为最理想的是，永远也不担心被系统回收掉。

以上总结，只是粗略讲述，网络上这些组件的技术细节相关的文章也很多，但并没有对这些通讯方式的对比介绍，更没有通讯效率方面的实际对比，其实我也没有做过全面测试对比，仅凭经验结论，大家有更详细的见解的，欢迎留言讨论。