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

一、前言

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);
    }

这上面的ApplicationContentResolverContentResolver的子类:

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
  • 把第二步中获得的qCursorCursorWrapperInner包裹起来,这里需要注意的是第二个参数,如果是通过unstableProvider查询得到的qCursor,那么将需要调用acquireProvider,并将返回值传入。

那么,我们接下来就要分析通过acquireUnstableProvideracquireProvider获取IContentProvider的过程。

2.3 IContentProvider 获取过程

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


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

可以看到,这里调用了mMainThreadacquireProvider方法,它实际上是一个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) 安装过程

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


我们上面的有两个Provider

  • localProvider,类型为ContentProvider
  • provider,类型为Transport

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


接下来,还会去调用localProviderattachInfo方法,这里面会初始化权限相关的信息,最终会执行ContentProvideronCreate()方法:

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

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

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

关于ContentProviderHolderProviderClientRecord,其继承族谱如下图所示:


(b-2) 发布过程

发布过程,其实就是调用了ActivityManagerServicepublishContentProviders方法,将在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进程的三方调用。


更多文章,欢迎访问我的 Android 知识梳理系列:

推荐阅读更多精彩内容