一、Activity启动过程

    首先我们要知道Activity有冷启动和热启动之分，通俗来说冷启动就是应用进程尚未创建，热启动则已经创建完成。

    在点击桌面应用图标时，即将要启动的App将和Launcher、AMS、Zygote这三者多次通信，才会启动一个App,然后再启动Activity。

追踪源码，我们可以得到以下整体的时序图：

Activity启动时序图

简单的梳理下整体流程，我们可以直接得到以下流程：

Activity启动总体流程图

Launcher进程通过Binder机制通知AMS

AMS则判断应用进程是否已经存在（冷启动），不存在则通过Socket通讯通知Zygote进程fork应用进程，已经启动（热启动）则无需再次创建App进程。

应用进程创建完成之后则会通过Binder机制通知AMS 创建完成。

AMS通过Binder机制请求ApplicationThread创建并启动根Activity。

ApplicationThread通过Handle机制通知主线程ActivityThread，最终调用到根Activity的onCreate、onStart、onResume等方法完成创建。

二、Service的启动过程

    Service的启动还是和Activity有很多相似处的，都需要和AMS打招呼。

    众所周知，Service的启动有两种方式一种StartService，一种bindService，那它们的启动过程是否一样呢？带着疑惑我们往下看。

    首先我们看StartService，直接分析源码，可以得到以下时序图：

startService时序图1

startService时序图2

    注：1.bringUpServiceLocked方法调用时，其中启动Service时会判断app==null，app的类型是ProcessRecord，用来描述运行的应用程序进程的信息，在其中将Service运行的进程名和uid传递给ActivityManagerService的getProcessRecordLocked方法，从而获取运行Service的应用程序进程信息ProcessRecord，如果用来运行Service的应用程序进程不存在，就会调用ActivityManagerService的startProcessLocked方法来创建对应的应用程序进程；如果用来运行Service的应用程序进程存在，会调用realStartServiceLocked方法。

    2.H是ActivityThread的内部类并继承自Handler，AMS通过IApplicationThread向应用程序进程发送消息，接受消息的操作是在应用程序进程的Binder线程池中进行，因此需要Handler来发送消息切换到主线程。

    总结下来就是

startService总流程

    下面接着分析下bindService，它的流程会相对startService复杂一丢丢，照例直接分析源码，可以得到以下时序图：

bindService时序图1

bindService时序图2

    大致总结一下就是应用进程这边调用一系列方法最终与AMS通信bindService，然后AMS中调用activeService类中的方法，然后又通过ApplicationThread与应用进程这边通信handleBindService，然后通知AMS去publishService，调用的activeService的publishServiceLocked方法，其中调用了ServiceDispatcher.InnerConnection的connected方法，再调用ServiceDispatcher的connected方法，ServiceDispatcher是LoadedApk的内部类，并调用Handler类型的对象mActivityThread的post方法，mActivityThread实际指向的是ActivityThread的内部类H，最终通过H类的post方法将RunConnection对象的内容运行在主线程中，RunConnections是LoadedApk的内部类，最后调用mConnection的onServiceConnected，mConnection的类型是ServiceConnection，这样客户端实现ServiceConnection接口类的onServiceConnected方法就会被调用。

三、BroadcastReceiver的注册、发送和接收

   广播注册分为动态注册和静态注册，首先我们分析动态注册。

    动态注册的过程是从ContextWrapper#registerReceiver()开始的. 和Activity或者Service一样. ContextWrapper并没有做实际的工作, 而是将注册的过程直接交给了ContextImpl来完成。

    ContextImpl#registerReceiver()方法调用了本类的registerReceiverInternal()方法。

    系统首先从mPackageInfo获取到IIntentReceiver对象, 然后再采用跨进程的方式向AMS发送广播注册的请求. 之所以采用IIntentReceiver而不是直接采用BroadcastReceiver, 这是因为上述注册过程中是一个进程间通信的过程. 而BroadcastReceiver作为Android中的一个组件是不能直接跨进程传递的. 所以需要通过IIntentReceiver来实现通信。

    IIntentReceiver作为一个Binder接口, 它的具体实现是LoadedApk.ReceiverDispatcher.InnerReceiver, ReceiverDispatcher的内部同时保存了BroadcastReceiver和InnerReceiver, 这样当接收到广播的时候, ReceiverDispatcher可以很方便的调用BroadcastReceiver#onReceive()方法. 这里和Service很像有同样的类, 并且内部类中同样也是一个Binder接口。

    由于注册广播真正实现过程是在AMS中, 因此跟进AMS中, 首先看registerReceiver()方法, 这里只关心里面的核心部分. 这段代码最终会把远程的InnerReceiver对象以及IntentFilter对象存储起来, 这样整个广播的注册就完成了。

静态注册的过程就比较简单

1.AndroidManifest.xml中的receiver解析成ParsedActivity, 存放在PackageImpl的receivers(PackageImpl父类是ParsingPackageImpl而且实现了AndroidPackage接口)

2.receivers最终会存放在mComponentResolver(PMS)的mReceivers中，mReceivers包含了所有安装应用的receiver，通过ComponentName就可以获得相应的ParsedActivity，如：

3.mReceivers.mActivities.get(new ComponentName(“com.example.myapplication”, “com.example.myapplication.MyReceive”))，既可以获得MyReceiver的ParsedActivity

4.receiver中的一个IntentFilter(intent-filter)对应一个ParsedIntentInfo，一个Pair<ParsedActivity, ParsedIntentInfo>

5.Pair<ParsedActivity, ParsedIntentInfo>被放入mComponentResolver的mFilters

6.mActions被放入mComponentResolver的mActionToFilter

    部分静态广播注册需要权限，不是注册了就能收到。其实要接收广播还：涉及权限、进程优先级、flag标签等各类无法接收到广播的情况。总而言之静态广播注册是在包安装解析的时候就开始注册，并将广播信息存储在PMS（PackageManagerService）中了。

    广播的发送主要有几种：普通广播、有序广播。

    前面都一样都是通过ContextImpl去与AMS打交道，然后AMS这边方法中会根据intent-filter查找出匹配的广播接收者并经过一系列的条件过滤. 最终会将满足条件的广播接收者添加到BroadcastQueue中, 接着BroadcastQueue就会将广播发送给相应广播接收者。应用接收到广播, 同时onReceive()方法是在广播接收者的主线程中被调用的。

普通广播发送

补充小知识

1：所有静态广播Receiver 都是串行处理，（静态广播接收者属于在发送此广播时属于有序广播范畴）

2：动态广播 Receiver按照发送此广播时指定的方式 进行 串行或者并行分发

其中：如果是普通广播：那么通过 并行方式分发

        如果是 有序广播（sendOrderxxxx）：那么通过 串行方式分发

3：Android系统在处理广播时：动态广播接收者 优先于 静态广播接收者 收到

4：广播分发处理关键类：BroadcastQueue/ BroadcastRecord

5.本地广播:为了解决全局广播的安全性问题，Android引进了本地广播机制。本地广播发出后只能够在应用程序内部传递，也只有应用程序内部的接收器能接收到本地广播，这样广播的安全性问题就能得到解决了。本地广播和全局广播不同的地方在于本地广播主要使用LocalBroadcastManager对广播的发送、注册、注销进行管理。

四、ContentProvider的启动过程

    ContentProvider的启动过程和其他3大组件基本类似，都是通过AMS实现进程间的数据共享。

    在activity中如果想通过provider来实现增删查改，首先需要获取contentprovider，大致过程为在context中获取contentResolver，然后通过contentResolver去ActivityManagerService中查询对应的provider，如果没有则进入PackageManagerService中查找：

    1)首先每个context类都会内部包含了一个ContentResolver的子对象ApplicationContentResolver。

    2)通过调用ApplicationContentResolver的主要方法query来获取CP的数据库数据。

    3)调用的过程首先会调用ContentResolver的核心方法acquireProvider()。而acquireProvider()方法是一个抽象方法，其实现是交由子类实现。

    4)通过子类的acquireProvider()方法实现了解到主要的实现是交由ActivityThread类来完成。

    5)ActivityThread类会做出一个判断，如果本地保存一个需要获取的CP对象实例，就会直接返回这个对象实例，如果没有保存，则会访问AMS对象去查找获取一个对象的CP对象实例，当找到这个对象实例后会保存到本地以便日后快速获取。

    6)如果在AMS里面没有找到，就会继续深入到PMS里去从全部的provider中查找。

    7)获取到CP对象实例后会通过层层返回，最后再调用该CP对象的query方法获取相应的数据。

首先在应用的的manifest中需要进行读写权限申明,这个申明的定义跟之前provider定义中读写所需权限属性值是一样的：

    在activity中获取ContentResolver调用其中的操作方法时，需要传入相对应的参数：

    contentResolver.query(Uri uri, String[] projection,String selection, String[] selectionArgs,String orderBy);

    uri：传入对应uri是为了查找到对应的provider，跟provider在manifest中定义的authorities值是一样

    projection：选择需要返回的对象属性值，有时候不需要将对象的值全部返回。

    selection/selectionArgs：查询条件

    orderBy： 返回的对象排序方式

    类似其他的delete、insert和update操作。最主要的是传入正确的Uri才能找到对应的provider。

    此处加个小知识点：ContentProvider onCreate()优先执行于 Application onCreate()方法，感兴趣的小伙伴可以通过查看源码的方式验证。

浅谈一个小知识点—AMS的启动：

    AMS，即ActivityManagerService，是安卓java framework的一个服务，运行在system_server进程。

    在系统开机启动之后，system_server会执行三大服务启动

    startBootstrapServices() ：启动引导服务，在这里实际上已经new了AMS，在new方法里，已经初始化了AMS的大部分重要的属性。AMS的Looper和各种handler也是在这里准备好的。

    startCoreServices():核心服务。

    在创建完AMS之后，system_server的run方法会执行到startOtherServices()，在启动“其他服务”完毕之后，会调入到AMS的systemReady()方法，在这里会启动launcher。

    可以说，在这个方法执行完毕之后，系统就已经启动完成了。