Android 四大组件介绍

Android 四大组件介绍以及BroadcastReceiver 、ContentProvider的详细解析

Android 四大组件

四大组件：Activity，Service，BroadcastReceiver，ContentProvider

简单介绍：

其实四大组件之间没有太大关系的，真要说有关系，那估计就是四大组件之间进行协同，完成进程运转不同层级和不同职责的功能

1. Activity :帮助进程完成与用户操作UI关联的组件，作为用户操作和进程流程运转的媒介，也作为进程的主要操作点，同时和进程的各大生命周期息息相关
2. Service：完成一些进程不需要展示在界面上中的操作，比如一些后台定时任务，后台数据同步，为了完成进程中静默操作的组件
3. BroadcastReceiver ：为了完成进程与进程，或者进程与系统进程之间的通知和消息传递，为了完成特殊通知下的消息传递
4. ContentProvider ：用于完成进程之间的数据共享传递，如果要与进程之间共享部分数据，而又不想暴露原始数据信息，就可以用这个组件

BroadcastReceiver 的实现原理

Android 中的广播使用了设计模式中的观察者模式：基于消息的发布 / 订阅事件模型。
模型中主要有 3 个角色：
消息订阅者（ 广播接收者 ）
消息发布者（ 广播发布者 ）
消息中心（ AMS，即 Activity Manager Service ）

1. 广播接收者通过 Binder 机制在 AMS（ Activity Manager Service ） 注册；
2. 广播发送者通过 Binder 机制向 AMS 发送广播；
3. AMS 根据广播发送者要求，在已注册列表中，寻找合适的 BroadcastReceiver （ 寻找依据：IntentFilter / Permission ）；
4. AMS 将广播发送到 BroadcastReceiver 相应的消息循环队列中；
5. 广播接收者通过消息循环拿到此广播，并回调 onReceive() 方法。
6. 广播的发送和接受是异步的，发送者不会关心有无接收者或者何时收到。

BroadcastReceiver 安全问题

BroadcastReceiver 设计的初衷是从全局考虑可以方便应用程序和系统、应用程序之间、应用程序内的通信，所以对单个应用程序而言BroadcastReceiver 是存在安全性问题的 ( 恶意程序脚本不断的去发送你所接收的广播 ) 。为了解决这个问题 LocalBroadcastManager 就应运而生了。
LocalBroadcastManager 是 Android Support （AndroidX）包提供了一个工具，用于在同一个应用内的不同组件间发送 Broadcast。LocalBroadcastManager 也称为局部通知管理器，这种通知的好处是安全性高，效率也高，适合局部通信，可以用来代替 Handler 更新 UI

LocalBroadcastManager

1. LocalBroadcastManager 内部协作主要是靠这两个 Map 集合：mReceivers 和 mActions ，当然还有一个 List 集合 mPendingBroadcasts ，这个主要就是存储待接收的广播对象。
2. LocalBroadcastManager 高效的原因主要是因为它内部是通过 Handler 实现的，它的 sendBroadcast() 方法含义并非和我们平时所用的一样，它的 sendBroadcast() 方法其实是通过 handler 发送一个 Message 实现的；
3. 它内部是通过 Handler 来实现广播的发送的，那么相比于系统广播通过 Binder 实现那肯定是更高效了，同时使用 Handler 来实现，别的应用无法向我们的应用发送该广播，而我们应用内发送的广播也不会离开我们的应用

BroadcastReceiver 不能执行耗时操作

BroadcastReceiver 一般处于主线程，耗时操作会导致 ANR；BroadcastReceiver 启动时间较短，如果一个进程里面只存在一个 BroadcastReceiver 组件。并且在其中开启子线程执行耗时任务，系统会认为该进程是优先级最低的空进程。很容易将其杀死。

ContentProvider

提出一个问题：内容提供者中是通过ContentResolver类与ContentProvider类进行交互的，为什么不直接访问ContentProvider类呢？

ContentProvider要么是提供一些系统的接口，或者是个人自定义的数据库之类的。然后可以作为外界获取本身内容的桥梁，如果过于开放，很容易泄露一些私密信息，被别人轻易盗用

ContentProvider 是如何实现数据共享的

1. 首先自定义 一个类继承 ContentProvider , 然后覆写 query 、insert 、update 、delete 等 方法。
2. 因为其是四大组件之一因此必须在 AndroidManifest 文件中进行注册。
3. 把自己的数据通过 uri 的形式共享出去， android 系统下 不同程序 数据默认是不能共享访问，需要去实现一个类去继承 ContentProvider。

ContentProvider 应用

通讯录，短信等等

Android 设计 ContentProvider 的目的是什么呢？

1. 隐藏数据的实现方式，对外提供统一的数据访问接口；
2. 更好的数据访问权限管理。ContentProvider 可以对开发的数据进行权限设置，不同的 URI 可以对应不同的权限，只有符合权限要求的组件才能访问到 ContentProvider 的具体操作。
3. ContentProvider 封装了跨进程共享的逻辑，我们只需要 Uri 即可访问数据。由系统来管理 ContentProvider 的创建、生命周期及访问的线程分配，简化我们在应用间共享数据（ 进程间通信 ）的方式。我们只管通过 ContentResolver 访问 ContentProvider 所提示的数据接口，而不需要担心它所在进程是启动还是未启动。

对外提供数据共享，那么如何限制对方的使用呢？

1. android:exported 属性非常重要。这个属性用于指示该服务是否能够被其他应用程序组件调用或跟它交互。
2. 如果设置为 true，则能够被调用或交互，否则不能。设置为 false 时，只有同一个应用程序的组件或带有相同用户 ID 的应用程序才能启动或绑定该服务。
3. 对于需要开放的组件应设置合理的权限，如果只需要对同一个签名的其它应用开放 ContentProvider ，则可以设置 signature 级别的权限。