一、前言

在 Framework 源码解析知识梳理(5) - startService 源码分析中，我们分析了Service启动的内部实现原理，今天，我们趁热打铁，看一下Android中的四大组件中另一个组件ContentProvider。

二、源码解析

在分析之前，先上一张整个的流程图，大家在后面绕晕了以后，可以参考这张图进行对照：

2.1 ContentResolver 获取过程

在使用ContentProvider来进行数据的增删改查时，第一步就是要通过getContentResolver()，获得一个ContentResolver对象，该方法实际上调用了基类中的mBase变量，也就是ContextImpl中的getContentResolver()方法，并返回它其中的mContentResolver变量。

    //ContextImpl.java

    @Override
    public ContentResolver getContentResolver() {
        return mContentResolver;
    }

而该mContentResolver是在ContextImpl的构造函数中初始化的，这其实和我们之前在插件化知识梳理(9) - 资源的动态加载示例及源码分析中所分析的getResources()方法返回一个Resources对象的过程类似。

    private ContextImpl(ContextImpl container, ActivityThread mainThread,
            LoadedApk packageInfo, IBinder activityToken, UserHandle user, boolean restricted,
            Display display, Configuration overrideConfiguration, int createDisplayWithId) {
        //...
        mContentResolver = new ApplicationContentResolver(this, mainThread, user);
    }

这上面的ApplicationContentResolver是ContentResolver的子类：

2.2 简单的查询过程

现在，我们以ContentResolver所提供的query方法为例，对ContentProvider的调用过程进行一次简单的走读：

    public final @Nullable Cursor query(final @NonNull Uri uri, @Nullable String[] projection,
            @Nullable String selection, @Nullable String[] selectionArgs,
            @Nullable String sortOrder, @Nullable CancellationSignal cancellationSignal) {
        Preconditions.checkNotNull(uri, "uri");
        //1.获取ContentProvider接口。
        IContentProvider unstableProvider = acquireUnstableProvider(uri);
        if (unstableProvider == null) {
            return null;
        }
        IContentProvider stableProvider = null;
        Cursor qCursor = null;
        try {
            long startTime = SystemClock.uptimeMillis();

            ICancellationSignal remoteCancellationSignal = null;
            if (cancellationSignal != null) {
                cancellationSignal.throwIfCanceled();
                //2.创建取消信号量。
                remoteCancellationSignal = unstableProvider.createCancellationSignal();
                cancellationSignal.setRemote(remoteCancellationSignal);
            }
            try {
                //3.调用IContentProvider的query方法。
                qCursor = unstableProvider.query(mPackageName, uri, projection,
                        selection, selectionArgs, sortOrder, remoteCancellationSignal);
            } catch (DeadObjectException e) {
                //如果发生了异常，那么销毁unstableProvider对象，重新获取一个stableProvider对象。
                unstableProviderDied(unstableProvider);
                stableProvider = acquireProvider(uri);
                //如果stableProvider对象还是为空，那么直接返回空。
                if (stableProvider == null) {
                    return null;
                }
                //调用stableProvider进行查询。
                qCursor = stableProvider.query(mPackageName, uri, projection,
                        selection, selectionArgs, sortOrder, remoteCancellationSignal);
            }
            if (qCursor == null) {
                return null;
            }

            // Force query execution.  Might fail and throw a runtime exception here.
            qCursor.getCount();
            long durationMillis = SystemClock.uptimeMillis() - startTime;
            maybeLogQueryToEventLog(durationMillis, uri, projection, selection, sortOrder);

            //用CursorWrapperInner把qCursor包裹起来。
            CursorWrapperInner wrapper = new CursorWrapperInner(qCursor,
                    stableProvider != null ? stableProvider : acquireProvider(uri));
            stableProvider = null;
            qCursor = null;
            return wrapper;
        } catch (RemoteException e) {
            // Arbitrary and not worth documenting, as Activity
            // Manager will kill this process shortly anyway.
            return null;
        } finally {
            if (qCursor != null) {
                qCursor.close();
            }
            if (cancellationSignal != null) {
                cancellationSignal.setRemote(null);
            }
            if (unstableProvider != null) {
                releaseUnstableProvider(unstableProvider);
            }
            if (stableProvider != null) {
                releaseProvider(stableProvider);
            }
        }
    }

我们对上面的流程进行一个简单的梳理：

通过acquireUnstableProvider获取一个unstableProvider实例，按字面上的翻译它是一个不稳定的ContentProvider。
通过第一步中获取的unstableProvider实例进行查询，如果查询成功，那么得到qCursor对象；如果ContentProvider所对应的进程已经死亡，那么将会释放unstableProvider对象，再通过调用acquireProvider方法重新得到一个stableProvider，它和unstableProvider相同，都是实现了IContentProvider接口，之后在通过它来查询得到qCursor。
把第二步中获得的qCursor用CursorWrapperInner包裹起来，这里需要注意的是第二个参数，如果是通过unstableProvider查询得到的qCursor，那么将需要调用acquireProvider，并将返回值传入。

那么，我们接下来就要分析通过acquireUnstableProvider、acquireProvider获取IContentProvider的过程。

2.3 IContentProvider 获取过程

首先，通过acquireUnstableProvider方法根据Uri中的authority字段，调用acquireUnstableProvider(Context c, String auth)方法：

该方法是由我们前面看到的ApplicationContentResolver所实现的：

可以看到，这里调用了mMainThread的acquireProvider方法，它实际上是一个ActivityThread实例，其实现为：

       public final IContentProvider acquireProvider(
            Context c, String auth, int userId, boolean stable) {
        //首先从缓存中获取，如果获取到就直接返回。
        final IContentProvider provider = acquireExistingProvider(c, auth, userId, stable);
        if (provider != null) {
            return provider;
        }

        IActivityManager.ContentProviderHolder holder = null;
        try {
            //如果缓存当中没有，那么首先通过AMS进行获取。
            holder = ActivityManagerNative.getDefault().getContentProvider(
                    getApplicationThread(), auth, userId, stable);
        } catch (RemoteException ex) {
        }
        if (holder == null) {
            Slog.e(TAG, "Failed to find provider info for " + auth);
            return null;
        }

        //根据返回的holder信息进行安装。
        holder = installProvider(c, holder, holder.info,
                true /*noisy*/, holder.noReleaseNeeded, stable);
        return holder.provider;
    }

这里，首先会去缓存中查找IContentProvider，如果没有找到，那么在调用AMS的方法去查找，获取一个ContentProviderHolder对象。

2.3.1 调用者进程不存在缓存的情况

在这种情况下面，会执行两步操作：

第一步：通过ActivityManagerService获取ContentProviderHolder
第二步：通过返回的ContentProviderHolder中的信息进行安装

第一步，通过 ActivityManagerService 获取 ContentProviderHolder

这里我们先假设没有缓存的情况，通过 Framework 源码解析知识梳理(1) - 应用进程与 AMS 的通信实现中学到的知识，我们知道它最终会调用到ActivityManagerService的下面这个方法：

接下来最终会调用到getContentProviderImpl方法返回一个ContentProviderHolder对象，这个方法比较长，就不贴代码了，直接说结论，这里会分为以下几种情况：

(a) ContentProvider 所在进程已经启动，并且已经该 ContentProvider 已经被安装

这种情况下，直接返回该ContentProviderHolder即可：

(b) ContentProvider 所在进程已经启动，但是该 ContentProvider 没有被安装

此时，就需要通过ApplicationThread对象，再和ContentProvider所在的进程进行交互，以返回一个ContentProviderHolder实例：

经过Binder通信，那么最终会调用到ContentProvider所在进程的下面这个方法：

这里面调用有调用了内部的installContentProviders方法：

这里的操作分为两步：

安装：根据传过来的List<ProviderInfo>对象，通过installProvider方法进行安装，并将结果存放在List<ContentProviderHolder>列表中。
发布：将安装的结果，再通过一次消息传递，返回给ActivityManagerService。

(b-1) 安装过程

在这一步当中，传入的第二个参数holder为null，因此会根据Provider的名字，动态地加载该类，并调用它的attachInfo方法：

我们上面的有两个Provider：

localProvider，类型为ContentProvider
provider，类型为Transport

provider是通过localProvider的getIContentProvider方法获得的，它是ContentProvider的一个内部类，它的作用就是作为ContentProvider在远程调用者中的一个代理对象，也就是说，ContentProvider的使用者是通过获取ContentProvider所在进程的一个代理类Transport，再通过这个Transport对象调用到ContentProvider进行查询的：

接下来，还会去调用localProvider的attachInfo方法，这里面会初始化权限相关的信息，最终会执行ContentProvider的onCreate()方法：

假设上面我们获得的localProvider不为空，那么会执行下面的逻辑：

这里面，我们会生成一个ProviderClientRecord对象，其内部包含了下面几个变量：

mNames：ContentProvider对象的authority
mProvider：远程代理对象
mLocalProvider：本地对象
mHolder：返回给AMS的数据结构，AMS再会把它返回给ContentProvider的调用者，mHolder的类型为IActivityManager.ContentProviderHolder，其内部包含的数据结构为：

关于ContentProviderHolder和ProviderClientRecord，其继承族谱如下图所示：

(b-2) 发布过程

发布过程，其实就是调用了ActivityManagerService的publishContentProviders方法，将在ContentProvider拥有者所创建的List<ContentProviderHolder>保存起来：

(c) ContentProvider 所在进程没有启动

在这种情况下，就需要先通过startProcessLocked启动ContentProvider所在进程，等待进程启动完毕之后，再进行安装。

第二步，利用返回的 ContentProviderHolder 中的信息，进行安装

在第一步中，通过ActivityManagerService，我们最终获得了ContentProviderHolder对象，接下来就是调用installProvider方法，这里和我们之前在第一步中的(b-1)中所看到的installProvider其实是同一个方法，区别在于，之前我们分析的installProvider传入的holder参数为空，下面，我们就来看一下当holder参数不为空时最终会走到下面的逻辑：

在installProviderAuthoritiesLocked方法中，会将它缓存在mProviderMap当中。

2.3.2 调用者进程存在缓存的情况

当调用者进程存在缓存时，会调用acquireExistingProvider方法，这里面就会通过我们前面所看到的mProviderMap进行查找：

三、小结

这篇文章拖了一个星期，总算是完成了，源码看的真的头晕，其实最终看下来，发现整个调用过程，和我们之前分析过的 Framework 源码解析知识梳理(5) - startService 源码分析很类似，究其根本，就是调用者进程、所有者进程和ActivityManagerService进程的三方调用。

Framework 源码解析知识梳理(6) ContentProvider 源码解析