3.1 Android四大组件
Android的四大组件分别是Activity、Service、Broadcast和ContentProvider。
- Activity是一种展示型组件，用于向用户直接展示一个界面，并且可以接收用户的输入信息从而进行交互。
- Service是一种计算型组件，用于在后台执行那个一系列计算任务。
- Broadcast是一种消息型组件，用于在不同的组件或者应用之间传递消息。
- ContentProvider是一种数据共享型组件，用于向其他组件或者应用共享数据。
四大组件中只有BroadcastReceiver既可以在AndroidManifest文件中注册，也可以在代码中注册，其他三个组件都必须在AndroidManifest文件中注册；ContentProvider的调用不需要借助Intent，其他三个组件都需要借助Intent。
3.1.1 Activity的工作过程
Activity启动的大致流程
- 应用程序的MainActivity通过Binder进程间通信机制通知AMS，它要启动一个新的Activity；
- AMS通过Binder进程间通信机制通知MainActivity进入Paused状态；
- MainActivity通过Binder进程间通信机制通知AMS，它已经准备就绪进入Paused状态，于是AMS就准备要在MainActivity所在的进程和任务中启动新的Activity了；
- AMS通过Binder进程间通信机制通知MainActivity所在的ActivityThread，现在一切准备就绪，它可以真正执行Activity的启动操作了。
下面看一张Activity和AMS的双向通信连接：
3.1.2 Service的工作过程
Service是一种计算型组件，用于在后台执行计算任务(Android的后台就是指，它的运行不依赖UI，即使Activity被销毁，只要进程还在，Service就可以继续运行)。尽管service是用于后台执行计算的，但是它本身是运行在主线程中的，因此网络请求或者复杂的运算仍然需要在单独的线程中去完成。
为什么不直接在Activity中创建单独的线程？这是因为Activity中创建的子线程难以操作，当Activity被销毁之后，很难再获得之前创建的子线程的实例；而且一个Activity中创建的子线程，另一个Activity是无法对其进行操作。但是Service就不同了，所有的Activity都可以绑定Service，然后就可以操作其中的方法，即使Activity被销毁了，只要与Service的连接还在，就可以继续使用该Service处理后台任务。因此使用Service来处理后台任务，Activity就可以放心地finish，完全不需要担心无法对后台任务进行控制的情况。
Service组件有两种状态：启动状态和绑定状态。这两种状态是可以共存的。当service处于绑定状态时，外界可以很方便的和service进行通信，而在启动状态中是不可与外界通信的。
startService
启动Service的过程和启动Activity的过程比较相似，这里就不再详述：
bindService
Service的绑定过程大致如下：
- MainActivity调用bindService方法通知AMS，它要启动CounterService这个服务，AMS于是在MainActivity所在的进程内部把CounterService启动起来，并且调用它的onCreate函数；
- AMS把CounterService启动起来后，继续调用CounterService的onBind函数，要求CounterService返回一个Binder对象给它；
- AMS从CounterService处得到这个Binder对象后，就把它传给MainActivity，即把这个Binder对象作为参数传递给MainActivity内部定义的ServiceConnection对象的onServiceConnected函数；
- MainActivity内部定义的ServiceConnection对象的onServiceConnected函数在得到这个Binder对象后，就可以调用它的接口服务。
3.1.3 BroadcastReceiver的工作过程
BroadcastReceiver是一种消息型组件，用于在不同的组件乃至不同的应用之间传递消息，它工作在系统内部。广播有两种注册方式：静态注册和动态注册，静态注册是在AndroidManifest中注册，在应用安装的时候会被系统解析，这种广播不需要应用启动就可以收到相应的广播；动态注册需要通过Context.registerReceiver()来注册，这种广播需要应用启动才能注册并接收广播。
BroadcastReceiver的工作过程包括广播注册过程、广播发送和接收过程。
注册过程：静态注册的时候是由PackageManagerService来完成整个注册过程，下面是动态注册的过程
发送和接收过程：
广播的发送有几种类型：普通广播、有序广播和粘性广播，有序广播和粘性广播与普通广播相比具有不同的特性，但是发送和接收过程是类似的。
从Android 3.1开始，处于停止状态的应用无法接受到开机广播。一个应用处于停止状态分为两种情况：一是应用安装后未运行；二是应用被手动或者其他应用强停了。
3.1.4 ContentProvider的工作过程
ContentProvider是一种数据共享型组件，用于向其他组件乃至其他应用共享数据。ContentProvider中的insert、delete、update、query方法需要处理好线程同步，因为这几个方法是在Binder线程池中被调用的，另外ContentProvider组件也不需要手动停止。
ContentProvider的启动过程：
- 当一个应用启动时，入口方法是ActivityThread的main方法，其中创建ActivityThread的实例并创建主线程的消息队列；
- ActivityThread的attach方法中会远程调用AMS的attachApplication，并将ApplicationThread提供给AMS，ApplicationThread主要用于ActivityThread和AMS之间的通信；
- AMS的attachApplication会调用ApplicationThread的bindApplication方法，这个方法会通过H切换到ActivityThread中去执行，即调用handleBindApplication方法；
- handleBindApplication方法会创建Application对象并加载ContentProvider，注意是先加载ContentProvider，然后调用Application的onCreate方法。
需要注意的是：
- 当ContentProvider所在的进程启动的时候，它会同时被启动并被发布到AMS中，这个时候它的onCreate要先去Application的onCreate执行。
- ContentProvider的android:multiprocess属性决定它是否是单实例，默认值是false，也就是默认是单实例。当设置为true时，每个调用者的进程中都存在一个ContentProvider对象。
- 当调用ContentProvider的insert、delete、update、query方法中的任何一个时，如果ContentProvider所在的进程没有启动的话，那么就会触发ContentProvider的创建，并伴随着ContentProvider所在进程的启动。
下图是ContentProvider的query操作的大致过程：
