tip：ContentProvider的onCreate要先于Application的onCreate来执行
当我们启动一个Activity时候，首先会从ActivityThread的main方法开始，这是一个静态方法，在这个方法里面会创建IApplicationThread对象（Binder），并把它传给AMS，通过这个Binder，AMS就能调用ApplicaitonThread中的方法。根据启动流程AMS首先会调用ApplicationThread中的bindApplication方法，这个方法里面主要发了一个消息：
接着这个消息会被ActivityThread的handler类H所拦截，拦截到消息后调用handleBindApplication方法，在这个方法里面会调用
这是一个ContentProvider的粗略启动过程，后面再详解
我们在使用ContentProvider首先需要获得ContentResolver对象，一般是通过getContentResolver这个方法来获得，这个方法的具体实现在ContextImpl中，代码如下：
返回了mContentResolver，这个的类型从它的定义中可以看出：
其实它就是一个ApplicationContentResolver对象，这个ApplicationContextResolver是ContextImpl的内部类
首先，contentProvider的创建源自于我们对它的访问，一般就是通过它的四个方法来访问它，这里从query展开，其他方法类似。当我们调用getContentResolver.query方法时候，其实就是调用ApplicationContentResolver的query方法，这个方法的实现在它的父类ContentResolver中，代码路径如下：frameworks/base/core/java/android/content/ContentResolver.java
其实无论是调用acquireProvider还是acquireUnstableProvider本质上最后都是调用acquireProvider，在ApplicationContentResolver中可以看到acquireProvider方法实现如下：
可以看到直接调用了ActivityThread的acquireProvider这个方法，代码如下：
AMS启动ContentProvider所在进程后，众所周知：进程的入口方法是ActivityThread的main方法，在ActivityThread的main方法中，有以下两行代码：
接下来进入到ActivityThread的attach方法中
接下来来到AMS的attachApplication，代码如下：
在AMS的attachApplicationLocked中，会调用ApplicationThread的bindApplication方法：代码如下
bindApplication只是发送了一个消息，这个消息被H接收后会调用ActivityThread的handleBindApplication方法，handleBindApplication中会调用以下代码：
代码实现如下：
接下来看看contentProvider对象的创建，进入installProvider方法，代码如下：
首先通过类加载器创建出contentprovider对象，然后调用其attachInfo方法，attachInfo这个方法的实现在ContentProvider.java中，代码如下：
可以看到contentProvider的初始化方法已经被调用