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的初始化方法已经被调用