基于场景解读Android四大组件

谈到Android四大组件：Activity，Service，Broadcast和ContentProvider，大部分人应该都比较熟悉了，因为会使用这四大组件是作为一个App开发者的基本功。但是，大家想过没有，Android作为一个平台，给开发者提供的为什么是四大组件，为什么不是三个或者五个？我们就得从使用场景的角度来说下这四大组件了。

我们知道一个App里面最常见的交互流程是这样的：用户在一个界面上点击一下，然后程序在后台开启一个线程去加载数据，加载完成后通知界面显示数据，如果这些数据在退出App情况下也需要的话，还要把这些数据保存到本地文件中。我们把这个流程分解成下面四个步骤：

• 前台（界面展示）；

• 后台（数据加载）；

• 通信（前台和后台通信）；

• 存储（数据存储）；

到这里可能大家会明白我想说的是什么了。这里的每一步其实就对应了一个组件，Activity就代表了前台所要提供的功能，主要负责界面的展示和用户的交互。Service就代表了后台所要提供的功能，主要负责一些耗时工作如网络请求，文件读写的处理。Broadcast就代表了通信所要提供的功能，主要负责Activity和Service之间（当然也可以是Activity和Activity，Service和Service）的通信。ContentProvider就代表了存储所要提供的功能，主要负责数据在磁盘的读写。

这里也许会有很多人不认同我的说法，比方说后台任务不一定要用Service啊，我自己搞个线程池或者开个进程也可以，消息通信也不一定需要Broadcast，我自己用Handler或者AIDL也可以做，存储也不需要ContentProvider，我自己写一套文件读写框架也可以。如果你这样想，也是可以的，但是我这里说了，我只是基于使用场景来谈这四个组件，从App层面考虑，Android作为一个SDK，就需要提供给开发者在开发产品过程中实现一个基本功能所需的基本开发组件，而这些组件就是Activity，Service，Broadcast和ContentProvider，少一个不行，多一个没必要。当然这四大组件其实也是Android为了方便开发者使用而提供的，你可以不用，自己重写一套来实现我上面说的前台，后台，通信和存储这四步（现在很多App都是这么干的）。但终归是要实现这四大功能，一个都不能少。

通过这种方式，对于四大组件的使用场景应该会有更进一步的认识（其实很多新技术的出现都可以说是基于一定的使用场景的，如果能带着这种思维方式去学习新技术，相信对于进一步加深新技术的理解会有帮助），当然这里提到的都是概念层面，概念大家都懂，但是怎么去更好使用，什么时候使用系统提供的组件，什么时候使用自定义的一套方案替代四大组件，比方说线程池替代Service，Handler和Aidl替代Broadcast等等，这就需要我们结合源码来掌握这些系统组件的工作原理，从而分析其在具体场景下的利弊（正如有人说没有最牛逼的算法只有最适合的算法），来择优选择解决方案。

第一次写技术类文章，也不知道写的好不好，如果有错误，欢迎指正。后续文章会通过具体场景来分析每个组件的利弊以及相应的替代方案，敬请期待！