前面阅读了BroadcastReceiver的源码。
这篇文章也应该是继续看VirtualApk中关于插件ContentProvider的处理的。不过由于处理逻辑类似于Activity、Service,所以到最后再看。本文的目的是了解系统对于ContentProvider的整个处理的过程。

ContentProvider是一个可以跨进程的组件,比如我们可以使用通讯录的ContentProvider来获取手机中的通信录信息。ContentResolver封装了ContentProvider跨进程通信的逻辑，使我们在使用ContentProvider时不需要关心这些细节。
那我们在使用context.getContentResolver().query(uri)时发生了什么呢？我们的进程是如何使用其他进程的ContentProvider的呢？
接下来我们就来分析Android系统源码对于ContentProvider的处理，来弄明白这些问题。
ContentProvider的实例化过程 我们从ContextImp.getContentResolver().query()开始看:

public final Cursor query(...) { IContentProvider unstableProvider = acquireUnstableProvider(uri); }

即首先要获得一个IContentProvider。它是ContentProvider可以跨进交互的一个aidl接口。其实这里拿到的就是一个Binder。所以接下来就看这个IContentProvider(Binder)是如果获取的。
我们在调用ContextImp.getContentResolver()获得的其实是ApplicationContentResolver。因此来看一下它的acquireUnstableProvider():

protected IContentProvider acquireProvider(Context context, String auth) { return mMainThread.acquireProvider(context, ContentProvider.getAuthorityWithoutUserId(auth), resolveUserIdFromAuthority(auth), true); }

继续看源码, 切换到主线程ActivityThread.java:

public final IContentProvider acquireProvider(Context c, String auth, int userId, boolean stable) { // 如果已经缓存过这个 auth对应的IContentProvider，则直接返回 final IContentProvider provider = acquireExistingProvider(c, auth, userId, stable); if (provider != null) return provider; ContentProviderHolder holder = null; holder = ActivityManager.getService().getContentProvider( getApplicationThread(), auth, userId, stable); //获取失败 if (holder == null) return null; //在向服务端获取holder，服务端如果发现ContentProvider的进程和当前客户端进程是同一个进程就会让客户端进程来实例化ContentProvider，具体细节可以在下面分析中看到 holder = installProvider(c, holder, holder.info, true /*noisy*/, holder.noReleaseNeeded, stable); return holder.provider; }

即在本地没有获得过IContentProvider时，直接向ActivityManagerService发起getContentProvider的请求,最终调用ActivityManagerService.getContentProviderImpl(), 这个方法就是ContentProvider实例化逻辑的核心了:
首先来看一下这个方法的声明:
ContentProviderHolder getContentProviderImpl(IApplicationThread caller,String name, IBinder token, boolean stable, int userId)
即最终是返回一个ContentProviderHolder,它是什么呢？它其实是一个可以在进程间传递的数据对象(aidl)，看一下它的定义:

public class ContentProviderHolder implements Parcelable { public final ProviderInfo info; public IContentProvider provider; public IBinder connection; ...

继续看getContentProviderImpl(),这个方法比较长，所以接下来我们分段来看这个方法, 顺序是(1)、(2)、(3)... 这种 :

ActivityManagerService.getContentProviderImpl()(1)

//三个关键对象 ContentProviderRecord cpr; ContentProviderConnection conn = null; ProviderInfo cpi = null; ... cpr = mProviderMap.getProviderByName(name, userId); // 看看系统是否已经缓存了这个ContentProvider

先来解释一下ContentProviderRecord、ContentProviderConnection、ProviderInfo、mProviderMap它们大概是什么:
ContentProviderRecord: 它是系统(ActivityManagerService)用来记录一个ContentProvider相关信息的对象。
ContentProviderConnection: 它是一个Binder。连接服务端(ActivityManagerService)和客户端(我们的app)。里面记录着一个ContentProvider的状态，比如是否已经死掉了等。
ProviderInfo: 用来保存一个ContentProvider的信息(manifest中的), 比如authority、readPermission等。
mProviderMap: 它的类型是ProviderMap。它里面存在几个map，这些map都是保存ContentProvider的信息的。
ok我们继续来看源码:

ActivityManagerService.getContentProviderImpl()(2)

cpr = mProviderMap.getProviderByName(name, userId); // 看看系统是否已经缓存了这个ContentProvider boolean providerRunning = cpr != null && cpr.proc != null && !cpr.proc.killed; if (providerRunning) { ... }if (!providerRunning) { ... }

即根据ContentProvider所在的进程是否是活跃、这个ContentProvider是否被启动过(缓存下来)两个状态来进行不同的处理 :
ContentProvider已被加载并且所在的进程正在运行 即: if(providerRunning){ ... }中的代码

ActivityManagerService.getContentProviderImpl()(3)

ProcessRecord r = getRecordForAppLocked(caller); //获取客户端(获得content provider的发起者)的进程信息 if (r != null && cpr.canRunHere(r)) { //如果请求的ContentProvider和客户端位于同一个进程 ContentProviderHolder holder = cpr.newHolder(null); //ContentProviderConnection参数传null holder.provider = null; //注意，这里置空是让客户端自己去实例化！！ return holder; }//客户端进程正在运行，但是和ContentProvider并不在同一个进程 conn = incProviderCountLocked(r, cpr, token, stable); // 直接根据 ContentProviderRecord和ProcessRecord 构造一个 ContentProviderConnection...

即如果请求的是同进程的ContentProvider则直接回到进程的主线程去实例化ContentProvider。否则使用ContentProviderRecord和ProcessRecord构造一个ContentProviderConnection
ContentProvider所在的进程没有运行并且服务端(ActivityManagerService)没有加载过它 即: if(!providerRunning){ ... }中的代码

ActivityManagerService.getContentProviderImpl()(4)

//先解析出来一个ProviderInfo cpi = AppGlobals.getPackageManager().resolveContentProvider(name, STOCK_PM_FLAGS | PackageManager.GET_URI_PERMISSION_PATTERNS, userId); ... ComponentName comp = new ComponentName(cpi.packageName, cpi.name); cpr = mProviderMap.getProviderByClass(comp, userId); //这个content provider 没有被加载过final boolean firstClass = cpr == null; if (firstClass) { ... cpr = new ContentProviderRecord(this, cpi, ai, comp, singleton); // 构造一个 ContentProviderRecord }...final int N = mLaunchingProviders.size(); //mLaunchingProviders它是用来缓存正在启动的 ContentProvider的集合的 int i; for (i = 0; i < N; i++) { if (mLaunchingProviders.get(i) == cpr) {// 已经请求过一次了，provider正在启动，不重复走下面的逻辑 break; } }//这个 ContentProvider 不是在启动状态，也就是还没启动 if (i >= N) { ProcessRecord proc = getProcessRecordLocked(cpi.processName, cpr.appInfo.uid, false); ...if (proc != null && proc.thread != null && !proc.killed) { //content provider所在的进程已经启动 proc.thread.scheduleInstallProvider(cpi); //安装这个 Provider , 即客户端实例化它 } else { //启动content provider 所在的进程, 并且唤起 content provider proc = startProcessLocked(cpi.processName,cpr.appInfo, false, 0, "content provider",new ComponentName(cpi.applicationInfo.packageName,cpi.name)...); }cpr.launchingApp = proc; mLaunchingProviders.add(cpr); //添加到正在启动的队列 }//缓存 ContentProvider信息 if (firstClass) { mProviderMap.putProviderByClass(comp, cpr); } mProviderMap.putProviderByName(name, cpr); //构造一个 ContentProviderConnection conn = incProviderCountLocked(r, cpr, token, stable); if (conn != null) { conn.waiting = true; //设置这个connection }

等待客户端实例化 ContentProvider

ActivityManagerService.getContentProviderImpl()(5)

// Wait for the provider to be published... synchronized (cpr) { while (cpr.provider == null) { .... if (conn != null) { conn.waiting = true; } cpr.wait(); } }return cpr != null ? cpr.newHolder(conn) : null; //返回给请求这个客户端的进程

根据前面的分析，ContentProvider所在的进程没有运行或者不是和获取者同一个进程，就创建了一个ContentProviderConnection,那么服务端就会挂起，启动ContentProvider所在的进程，并等待它实例化ContentProvider :
在继续看客户端实例化ContentProvider之前，我们先用一张图来总结一下客户端进程请求服务端(ActivityManagerService)启动一个ContentProvider的逻辑 :

文章图片
ActivityManagerService对于ContentProvider启动请求的处理.png 客户端实例化ContentProvider 【ContentProvider启动过程分析】ok，通过前面的分析我们知道ContentProvider最终是在它所在的进程实例化的。接下来就看一下客户端相关代码,
同一个进程中的ContentProvider实例化过程
前面分析我们知道，如果客户端进程和请求的ContentProvider位于同一个进程，则ActivityManager.getService().getContentProvider(...); ,会返回一个内容为空的ContentProviderHolder,
我们再拿刚开始客户端向服务端请求ContentProvider的代码看一下:

holder = ActivityManager.getService().getContentProvider( getApplicationThread(), auth, userId, stable); //在向服务端获取holder，服务端如果发现ContentProvider的进程和当前客户端进程是同一个进程就会让客户端进程来实例化ContentProvider，具体细节可以在下面分析中看到 holder = installProvider(c, holder, holder.info, true /*noisy*/, holder.noReleaseNeeded, stable);

我们继续看ActivityThread.installProvider, 这个方法其实有两个逻辑, 下面我只截取一些关键的逻辑,我们现在只看同一个进程中的ContentProvider实例化过程, 即会初始化localProvider的逻辑:

private ContentProviderHolder installProvider(...) { ContentProvider localProvider = null; IContentProvider provider; if (holder == null || holder.provider == null) { //服务端没有缓存过这个provider，客户端需要初始化 final java.lang.ClassLoader cl = c.getClassLoader(); LoadedApk packageInfo = peekPackageInfo(ai.packageName, true); localProvider = packageInfo.getAppFactory().instantiateProvider(cl, info.name); //实例化ContentProvider provider = localProvider.getIContentProvider(); ... localProvider.attachInfo(c, info); }else { provider = holder.provider; }ContentProviderHolder retHolder; IBinder jBinder = provider.asBinder(); if (localProvider != null) { //同一个进程的ContentProvider ProviderClientRecord pr = mLocalProvidersByName.get(cname); pr = installProviderAuthoritiesLocked(provider, localProvider, holder); //把Provider缓存起来 retHolder = pr.mHolder; }else{ ProviderRefCount prc = mProviderRefCountMap.get(jBinder); //其他进程的ContentProvider ... if(prc == null){ prc = new ProviderRefCount(holder, client, 1000, 1000); //也缓存起来 ProviderClientRecord client = installProviderAuthoritiesLocked(provider, localProvider, holder); mProviderRefCountMap.put(jBinder, prc); ... } retHolder = prc.holder; } return retHolder; }

对于这个方法我们暂且知道在客户端进程和请求的ContentProvider位于同一个进程时它会: 实例化ContentProvider,缓存起来
不在同一个进程中的ContentProvider实例化过程
如果客户端进程和请求的ContentProvider不在同一个进程，根据前面我们分析ActivityManagerService的逻辑可以知道, ActivityManagerService会调用ContentProvider所在进程的proc.thread.scheduleInstallProvider(cpi),
其实最终调用到installContentProviders()

private void installContentProviders(Context context, List providers) { final ArrayList results = new ArrayList<>(); //ActivityManagerService 让客户端启动的是一个ContentProvider列表 for (ProviderInfo cpi : providers) { ContentProviderHolder cph = installProvider(context, null, cpi,false, true ,true); if (cph != null) { cph.noReleaseNeeded = true; results.add(cph); } }ActivityManager.getService().publishContentProviders(getApplicationThread(), results); //通知服务端，content provider ok啦 }

即它会调用installProvider来实例化ContentProvider，并通知服务端ContentProviderok了，可以给其他进程使用了。
那installProvider具体做了什么呢？ 前面已经分析过了，其实就是 缓存下其他进程的IContentProvider(Binder)。你可以去看一下上面
installProvider方法的localProvider == null的那个逻辑。
到这里，客户端其实就拿到了IContentProvider(Binder)。 即ContextImp.getContentResolver().query()拿到了IContentProvider。可执行query了。
是不是有点云里雾里的，我们看一下下面这张图，来理一下思路吧:

文章图片
客户端安装ContentProvider.png 到这里我们算理解了ContentProvider的工作原理, 我们以一个ContentProvider第一次启动为例来总结一下:

1. 进程在启动ContentProvider时会向ActivityManagerService要，ActivityManagerService如果没有就会让客户端启动这个ContentProvider
2. 客户端进程启动ContentProvider后就会缓存起来, 方便后续获取
3. ActivityManagerService只会缓存那些可能跨进程访问的ContentProvider
4. 和不同进程的ContentProvider通信是通过Binder实现的

VirtualApk关于ContentProvider的处理 VirtualApk它是一个插件化框架，它所需要支持的特性是: 插件中的ContentProvider如何跑起来？ 它又没有在manifest中注册。
其实很简单，类似于它对插件Service的支持:

1. 定义一个占坑的ContentProvider（运行在一个独立的进程）
2. hook掉插件Activity的Context,并返回自定义的PluginContentResolver
3. PluginContentResolver在获取ContentProvider时，先把个占坑的ContentProvider唤醒。即让它在ActivityManagerService中跑起来
4. 返回给插件一个IContentProvider的动态代理。
5. 插件通过这个IContentProvider动态代理来对ContentProvider做增删改查
6. 在动态代理中把插件的增删改查的Uri,重新拼接定位到占坑的ContentProvider
7. 在占坑的ContentProvider实例化插件请求的ContentProvider，并做对应的增删该查。

所以:

1. 插件的ContentProvider是运行在占坑的ContentProvider进程中的。
2. 插件的ContentProvider是不会运行在自己自定的进程中的，即没有多进程ContentProvider的概念。

欢迎Star我的Android进阶计划,看更多干货

推荐阅读

• 

  治疗股骨干骨折该选择哪种方法 治疗股骨干骨折该选择哪种方法最好
• 

  只狼boss种类有哪些 只狼boss种类介绍
• 

  PromQL之label_replace/label_join
• 

  安卓计算器开发ppt，制作简单安卓专业计算器各位专业的大神我现在需要一个专业的
• 

  糖尿病的人可以吃西红柿炒鸡蛋吗
• 

  犯了爆炸罪应怎样处罚 爆炸罪怎么判
• 

  为何别人利息是你一半？教你拿到低息贷款！
• 

  华硕主板怎么关闭过热保护 华硕主板怎么关闭过热保护提示
• 

  博观而约取厚积而薄发这句意思 怎么理解博观而约取厚积而薄发
• 

  机关事业单位年度调薪相关规定 事业编薪级工资对照表管理
• 

  关于linux下备份postgresql的信息
• 

  小米note顶配为何称为安卓机皇,2020年的手机操作系统
• 

  UG四轴怎样编程教程，ug 4轴 钻孔程序怎么编程 急急急
• 

  山药补肾阴还是肾阳
• 

  辩护意见审查起诉阶段能写吗？
• 

  杨玉环怎么死的 杨玉环死因始末是什么
• 

  mongodb 查询条件 mongodb查询点区域
• 

  每日分享当日所学育儿知识第三天
• 

  娱乐圈里身高超过185CM的男明星都有谁？
• 

  称的多音字组词和拼音 多音字称怎么组词

• Hive常见问题汇总
• 全过程工程咨询——时间管理（12）
• 注册分销商的骄傲
• 如何启动改变
• 普通人进阶的三个过程-很多人都知道，但却本末倒置
• spring|spring boot项目启动websocket
• Android系统启动之init.rc文件解析过程
• 会玩才有未来
• 十月的故事（三）
• MySQL|MySQL 存储过程语法及实例