阿狗工具
一、Activity启动过程
首先我们要知道Activity有冷启动和热启动之分，通俗来说冷启动就是应用进程尚未创建，热启动则已经创建完成。
在点击桌面应用图标时，即将要启动的App将和Launcher、AMS、Zygote这三者多次通信，才会启动一个App,然后再启动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，直接分析源码，可以得到以下时序图：
注：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来发送消息切换到主线程。
总结下来就是
下面接着分析下bindService，它的流程会相对startService复杂一丢丢，照例直接分析源码，可以得到以下时序图：
大致总结一下就是应用进程这边调用一系列方法最终与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。
可以说，在这个方法执行完毕之后，系统就已经启动完成了。