展开说说：Android之ContentProvider源码浅析

上一篇总结了ContentProvider、ContentResolver、ContentObserver的简单应用，本篇记录一下梳理他们工作时的源码的执行流程。

概述：

1. ContentResolver也有自己的生命周期，那么它的onCreate和Application的onCreate哪个先执行呢？
2. ContentResolver、ContentObserver都是为ContentProvider服务的，不同之处在于前者是必须的，而后者是锦上添花，对外传输的纽带是URI。
3. 分析ContentResolver调用增删改查时的执行流程，以query为例。

目录

一、ContentResolver也有自己的生命周期，但是它的onCreate和Application的onCreate哪个先执行呢？

1、生命周期和重要方法

2、它的onCreate和Application的onCreate哪个先执行，为什么？

二、ContentResolver、ContentObserver都是为ContentProvider服务的

三、分析ContentResolver调用增删改查时的执行流程，以query为例。

3.1 内部先通过acquireUnstableProvider()获取IContentProvider代理对象。

3.2 获取ContentProvider对象

3.2.1 利用ActivityManagerService跨进程创建ContentProvider

3.2.1.1 新进程的执行过程

3.3 ContentProvider配合工作

---

 

下面按着上面提到的三点论述和疑问，我们顺着源码去捋一捋。

一、ContentResolver也有自己的生命周期，但是它的onCreate和Application的onCreate哪个先执行呢？

ContentProvider的数据存储形式可以像数据库那样以表格的形式存储，也可以存储文件，比如我们手机里的图片和视频，他甚至还可以操作内存中的一个对象或者集合。

1、生命周期和重要方法

onCreate

和Activity的类似，在刚创建的时候执行，用来做一些初始化工作。

Query

和名字一样正好对应着数据表的查询操作。

Insert

和名字一样正好对应着数据表的数据插入操作。

Delete

对应着数据表的数据删除操作。

Update

对应着数据表的数据更新操作。

getType

返回值是URI，代表媒体类型，比如图片或视频。一般可以不关注这个选项可以直接返回null或“*/*”。

2、它的onCreate和Application的onCreate哪个先执行，为什么？

ContentProvider的onCreate比Application的onCreate方法先执行，是的，你没看错。

之前分析Activity和BroadcastReceiver源码是，入口都是从ActivityThread类开始的，因为它的main方法是一个应用启动时的入口方法。这里会创建主线程并执行Application和四大组件的初始化生命周期。

该类的handleBindApplication方法会创建Application对象和安装ContentProvider其实就是初始化。

上面的installContentProvider方法会初始化ContentProvider并调用它的onCreate方法，而下面的mInstrumentation.callApplicationOnCreate(app);会调用Application的onCreate方法，因此可以证明ContentProvider的onCreate比Application的onCreate方法先执行。

二、ContentResolver、ContentObserver都是为ContentProvider服务的

第一、Query、Insert、Delete、Update增删改查四个方法，都必须是通过ContentResolver来调用执行的，所以它是为ContentProvider服务并且是必须的，没它不行。通过Binder机制实现跨进程通信

第二、开头都先调用getContext().getContentResolver()这个方法获取ContentResolver对象，但是他返回的不是ContentResolver而是它的子类ApplicationContentResolver对象。但ApplicationContentResolver比较神秘不好找，你需要到sdk的源码中自己去查看，路径是sources\android-30\android\app文件夹下ContextImpl文件的内部类（而这个ContextImpl不难看出是Context的子类）：

ContentResolver通过URI来匹配ContentProvider，调用它对应的增删改查方法并返回结果。

三、分析ContentResolver调用增删改查时的执行流程，以query为例。

ContentResolver中query() 方法

3.1 内部先通过acquireUnstableProvider()获取IContentProvider代理对象。

上图中的acquireUnstableProvider方法最终会调用到一个同名的acquireUnstableProvider抽象方法，而他的具体实现就在上面提到的比较神秘的ApplicationContentResolver中，上面有截图，此处贴小段代码：

private final ActivityThread mMainThread;

@Override

        protected IContentProvider acquireUnstableProvider(Context c, String auth) {

            return mMainThread.acquireProvider(c,

                    ContentProvider.getAuthorityWithoutUserId(auth),

                    resolveUserIdFromAuthority(auth), false);

        }

上面看到mMainThread就是ActivityThread，因此再看：

3.2 获取ContentProvider对象

acquireExistingProvider方法先查找是否已经存在ContentPovider了，如果存在匹配成功的直接return回去，如果不存在就自己开始创建：

3.2.1 利用ActivityManagerService跨进程创建ContentProvider

synchronized (getGetProviderLock(auth, userId)) {

                holder = ActivityManager.getService().getContentProvider(

                        getApplicationThread(), c.getOpPackageName(), auth, userId, stable);

            }

向ActivityManagerService（以下简称AMS）发送一个进程间的请求让它启动URI匹配成功的ContentProvider，然后通过installProvider方法来修改引用计数。

ContentProvider被启动跨进程通信，如果对方进程已启动就省去了启动流程直接启动ContentProvider，否则就先帮它启动进程再启动ContentProvider。

进程是通过AMS的startProcessLocked方法启动的，它的核心代码是内部调用了Process的start方法，下面是完整链路：

ActivityManagerService中的startProcessLocked方法

根据final ProcessList mProcessList;看到类型是ProcessList，而它没有

Import导包，因此它和ActivityManagerService在同一目录，此时看ProcessList中的startProcessLocked方法：

他会调用本类的startProcess方法，这个方法篇幅较长，直接贴出关键部分：

此时就分析完了AMS启动一个进程的过程。

3.2.1.1 新进程的执行过程

继续新进程启动后的流程，首先执行的就是我们开篇提到的ActivityThread中的main方法。

这个方法很厉害因为就是他创建了主线程Looper.prepareMainLooper();之前分析Activity的时候有截图，此处就贴关键代码：

ActivityThread thread = new ActivityThread();

        thread.attach(false, startSeq);

实例化自己照亮他人，调用自己的attach方法完成一系列初始化。

将ApplicationThread跨进程传递给AMS来完成ContentProvider的创建。

先创建ContextImpl；再创建Application；然后再创建ContentProvider并调用它的onCreate生命周期；再然后才是调用Application的onCreate。此时该ContentProvider所在的进程被启动了，而他自身也被激活了，可以配合AMS尽心工作了。

3.3 ContentProvider配合工作

不过AMS要真正的操作ContentProvider还需要多几个步骤，要从IContentProvider接口到它的实现类ContentProviderNative

，但最终实现类是ContentProviderNative的子类，ContentProvider的内部类Transport。

因为它是内部类，mInterface就是直接调用了ContentProvider的query方法，而上篇写过咱们自定义了一个ContentProvider重写了query，这不就到了你的地界了嘛。想查什么查什么。

仔细瞧Transport中除了query还有insert、delete、update、getType五个熟悉的面孔，其他的增删改流程也是一样的。

个人总结记录，才疏学浅，如有错误，欢迎指正，多谢。