Android ContentProvider启动流程源码解析(8.0)

一，写在前面

       在文章 Android 如何自定义一个ContentProvider中，介绍了如何使用以及自定义一个ContentProvider，本篇不再介绍如何使用ContentProvider访问其他应用的数据。在阅读本篇文章前，建议先了解Activity的启动流程，可参考文章 Android Activity的启动流程源码解析(8.0) ，将不再对重复的代码细节进行分析。

二，启动ContentProvider的入口

       如何启动一个ContentProvider呢？在一个Activity类中，可以调用getContentResolver().query(...)查询指定uri对应的数据，在这个过程中若ContentProvider没有启动，则会启动ContentProvider。当然，相应的insert，delete，update方法也可以启动ContentProvider，本篇文章以query方法为例进行分析。

       获取ContentResolver的对象，实际上调用的是ContextWrapper$getContentResolver方法，ContextWrapper是抽象类Context的一个子类。 

       查看ContextWrapper$getContentResolver方法源码：

    @Override    public ContentResolver getContentResolver() {        return mBase.getContentResolver();    }

       第3行，变量mBase对应的是ContextImpl对象，分析见Android Activity的启动流程源码解析(8.0) ，这里不再重复阐述。

       

      查看ContextImpl$getContentResolver方法源码：

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

       第3行，变量mContentResolver的初始化在ContextImpl的构造函数中完成，mContentResolver = new ApplicationContentResolver(this, mainThread, user)，也就是返回的是ApplicationContentResolver的实例。值得一提的是，ContextImpl对象的创建是在启动Activity的流程中完成，具体分析见 Android Activity的启动流程源码解析(8.0) ，这里不再重复阐述。

       ApplicationContentResolver是ContextImpl的一个内部类，且继承类ContentResolver。调用getContentResolver().query(...)方法，是从父类ContentResolver继承的query方法。

       查看ContentResolver$query方法源码：

public final @Nullable Cursor query(final @RequiresPermission.Read @NonNull Uri uri,            @Nullable String[] projection, @Nullable String selection,            @Nullable String[] selectionArgs, @Nullable String sortOrder,            @Nullable CancellationSignal cancellationSignal) {        //...    IContentProvider unstableProvider = acquireUnstableProvider(uri);    if (unstableProvider == null) {                 return null;            }        //...    qCursor = unstableProvider.query(mPackageName, uri, projection,                        selection, selectionArgs, sortOrder, remoteCancellationSignal);        //...}

       第8行，获取一个IContentProvider类型的对象unstableProvider。启动ContentProvider从这里开始分析，后面会详细分析。

       第9行，对变量unstableProvider进行判空检查；

       第15行，根据指定uri，执行查询数据操作，文章的最后会详细分析。

       查看ContentResolver$acquireUnstableProvider方法(一个参数)源码：

public final IContentProvider acquireUnstableProvider(Uri uri) {        if (!SCHEME_CONTENT.equals(uri.getScheme())) {            return null;        }        String auth = uri.getAuthority();        if (auth != null) {            return acquireUnstableProvider(mContext, uri.getAuthority());        }        return null;}

       第2行，对uri的scheme进行检查；

       第7行，逻辑跳到ApplicationContentResolver$acquireUnstableProvider方法(两个参数)；

       查看ApplicationContentResolver$acquireUnstableProvider方法源码：

@Overrideprotected IContentProvider acquireUnstableProvider(Context c, String auth) {    return mMainThread.acquireProvider(c,    ContentProvider.getAuthorityWithoutUserId(auth),    resolveUserIdFromAuthority(auth), false);}

       第3行，变量mMainThread是一个ActivityThread类型的对象，该变量的初始化也是在ContextImpl的构造函数中完成。

       查看ActivityThread$acquireProvider方法源码：

    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;        }        ContentProviderHolder holder = null;        //...        holder = ActivityManager.getService().getContentProvider(                    getApplicationThread(), auth, userId, stable);        //...        holder = installProvider(c, holder, holder.info,                true /*noisy*/, holder.noReleaseNeeded, stable);        return holder.provider;    }

       第3行，调用ActivityThread$acquireExistingProvider方法，查询Map集合中是否包含该IContextProvider对象，下面会具体分析。

       第4行，若provider不为null，表示该IContextProvider对象已经存在，无需再创建。

       第11行，若provider为null，那么需要创建一个IContextProvider对象。这里就是启动ContentProvider流程的入口，后面会重点具体分析。

       第16行，将11行创建的IContextProvider对象存储在一个Map集合中，起到一个缓存的作用，不用每次创建IContextProvider对象。

       分析ActivityThread$acquireProvider方法的第3行，查看ActivityThread$acquireExistingProvider方法源码：

public final IContentProvider acquireExistingProvider(            Context c, String auth, int userId, boolean stable) {    synchronized (mProviderMap) {        final ProviderKey key = new ProviderKey(auth, userId);        final ProviderClientRecord pr = mProviderMap.get(key);        if (pr == null) {    return null;        }            IContentProvider provider = pr.mProvider;//...return provider;    }      }

       第4行，将参数auth封装在ProviderKey对象中，并作为Map集合的key；
       第5行，变量mProviderMap的初始化：final ArrayMap<ProviderKey, ProviderClientRecord> mProviderMap = new ArrayMap<ProviderKey, ProviderClientRecord>();当Map集合中不存在该key时，就会返回null。

三，启动ContentProvider，交给AMS处理

       前面已经提到，ActivityThread$acquireProvider方法的第11行是启动ContentProvider的入口。

       第11行代码：holder = ActivityManager.getService().getContentProvider(getApplicationThread(), auth, userId, stable)。ActivityManager.getService()这个已经再熟悉不过了，基于Binder机制，最终会调用系统服务ActivityManagerService$getContentProvider方法。具体分析见文章 Android Activity的启动流程源码解析(8.0) ，这里不再重复阐述。

        查看ActivityManagerService$getContentProvider方法源码：

    @Override    public final ContentProviderHolder getContentProvider(            IApplicationThread caller, String name, int userId, boolean stable) {        //...        return getContentProviderImpl(caller, name, null, stable, userId);    }    //继续查看...    private ContentProviderHolder getContentProviderImpl(IApplicationThread caller,            String name, IBinder token, boolean stable, int userId) {        //...ProcessRecord proc = getProcessRecordLocked(cpi.processName, cpr.appInfo.uid, false);if (proc != null && proc.thread != null && !proc.killed) {    if (!proc.pubProviders.containsKey(cpi.name)) {//...proc.thread.scheduleInstallProvider(cpi);//...    }} else {             //...    proc = startProcessLocked(cpi.processName,    cpr.appInfo, false, 0, "content provider",    new ComponentName(cpi.applicationInfo.packageName,    cpi.name), false, false, false);        //...}           //...code            }

       第17行，ProcessRecord封装了ContentProvider所在应用程序进程的相关信息；

       第25行，若应用程序进程已经启动，则调用scheduleInstallProvider方法，启动ContentProvider；

       第33行，若应用程序进程没有启动，则调用AMS$startProcessLocked方法启动进程。本篇文章假设应用程序进程没有启动，来研究ContentProvider的启动流程，下面会重点分析这里。

四，入口ActivityThread$main的分析

       为什么要分析应用程序进程的启动呢？因为应用程序进程启动后，接着启动ContentProvider。进程启动是交给ActivityManagerService$startProcessLocked方法来处理，最终会调用ActivityThread$main方法(ActivityThread是代表主线程的实例)。这里推荐一篇博客 Android应用程序进程启动过程 ，文章详细讲解了进程的启动流程。

       

       下面继续分析ActivityThread$main方法，这个方法很重要。想要完全理解Handler机制，了解main方法也是必须的，下面会讲述一些篇外话。

       ActivityThread$main方法查看源码：

public static void main(String[] args) {        //...        Looper.prepareMainLooper();        ActivityThread thread = new ActivityThread();        thread.attach(false);        if (sMainThreadHandler == null) {            sMainThreadHandler = thread.getHandler();        }//...        Looper.loop();        throw new RuntimeException("Main thread loop unexpectedly exited");}

       第5行，创建Looper对象，并将该对象放入ThreadLocal中。

       简单介绍下ThreadLocal：可以使某一个变量在不同线程代表不同的值。在这里用于存放主线程ActivityThread中创建的Looper，当然子线程也可以创建自己的Looper，但不同线程的Looper并不是一个对象。

       值得一提的：调用Looper.prepareMainLooper()方法专门用于创建主线程的Looper对象，在子线程中创建Looper对象也比较熟悉了，一般调用Looper.prepare()方法。当然这两种方式创建Looper是有区别，区别在于主线程的Looper不被允许停掉，具体代码细节分析留给感兴趣哥们验证~

       第7行，创建ActivityThread的实例；

       第8行，调用ActivityThread$attach方法，内部完成ContentProvider的启动过程，后面会重点分析。

       第16行，进行消息循环的操作，内部有一个无限for循环，不断的获取Message对象且处理消息。

       第18行，该行代码被执行的前提是：Looper$loop方法跳出无限for循环。因此需要调用Looper$quit方法停掉Looper，前面已经讲到主线程的Looper不会被停掉。由于不是本篇重点，具体的代码细节不做阐述，这里直接给出结论。也就是说，抛出RuntimeException这个异常还是比较少见的，Android系统也不支持这样做。

       回到ActivityThread$attach方法的调用，它会启动ContentProvider，下面继续分析。

       查看ActivityThread$attach方法源码：

private void attach(boolean system) {//...final IActivityManager mgr = ActivityManager.getService();//...mgr.attachApplication(mAppThread);//...}

       第5行，返回一个IActivityManager接口的代理对象，这个应该比较熟悉了，具体分析可以参考文章 Android Activity的启动流程源码解析(8.0) ；

       第9行，向系统服务AMS发起请求，基于Binder机制，回调用ActivityManagerService$attachApplication方法；变量mAppThread是一个ApplicationThread类型的变量，这个也比较熟悉了，具体分析可以参考文章 Android Activity的启动流程源码解析(8.0) ；

       查看ActivityManagerService相关方法的源码：

public final void attachApplication(IApplicationThread thread) {        synchronized (this) {            //...            attachApplicationLocked(thread, callingPid);                //...        }}//继续查看...private final boolean attachApplicationLocked(IApplicationThread thread,            int pid) {//...thread.bindApplication(processName, appInfo, providers,                        app.instr.mClass,                        profilerInfo, app.instr.mArguments,                        app.instr.mWatcher,                        app.instr.mUiAutomationConnection, testMode,                        mBinderTransactionTrackingEnabled, enableTrackAllocation,                        isRestrictedBackupMode || !normalMode, app.persistent,                        new Configuration(getGlobalConfiguration()), app.compat,                        getCommonServicesLocked(app.isolated),                        mCoreSettingsObserver.getCoreSettingsLocked(),                        buildSerial);//...}

       第17行，变量thread是一个ApplicationThread的对象，调用bindApplication方法完成一次IPC的调用，代码逻辑切换到ApplicationThread中去执行。这个应该比较熟悉了，具体分析可以参考文章 Android Activity的启动流程源码解析(8.0) ，这里不再重复阐述。

       查看ActivityThread$ApplicationThread$bindApplication方法源码：

public final void bindApplication(String processName, ApplicationInfo appInfo,                List<ProviderInfo> providers, ComponentName instrumentationName,                ProfilerInfo profilerInfo, Bundle instrumentationArgs,                IInstrumentationWatcher instrumentationWatcher,                IUiAutomationConnection instrumentationUiConnection, int debugMode,                boolean enableBinderTracking, boolean trackAllocation,                boolean isRestrictedBackupMode, boolean persistent, Configuration config,                CompatibilityInfo compatInfo, Map services, Bundle coreSettings,                String buildSerial) {    //...    AppBindData data = new AppBindData();            data.processName = processName;            data.appInfo = appInfo;            data.providers = providers;            data.instrumentationName = instrumentationName;            data.instrumentationArgs = instrumentationArgs;            data.instrumentationWatcher = instrumentationWatcher;            data.instrumentationUiAutomationConnection = instrumentationUiConnection;            data.debugMode = debugMode;            data.enableBinderTracking = enableBinderTracking;            data.trackAllocation = trackAllocation;            data.restrictedBackupMode = isRestrictedBackupMode;            data.persistent = persistent;            data.config = config;            data.compatInfo = compatInfo;            data.initProfilerInfo = profilerInfo;            data.buildSerial = buildSerial;            sendMessage(H.BIND_APPLICATION, data);}

       第13行，创建AppBindData对象，用于封装一些数据。
       第30行，ActivityThread$sendMessage方法的内部代码不再展示。具体来说，使用Handler发送了一个消息，基于Handler的消息机制，将任务切换到Handler所在的线程中执行，于是任务切换到ActivityThread中执行。

       我们会发现，Android四大组件的启动，代码逻辑由系统服务AMS切换到ApplicationThread，然后基于Handler的消息机制，最终切换到主线程ActivityThread中执行。

    

       继续分析消息的处理过程，查看ActivityThread$H$handleMessage方法源码：

public void handleMessage(Message msg) {    switch (msg.what) {//...case BIND_APPLICATION:    Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "bindApplication");    AppBindData data = (AppBindData)msg.obj;    handleBindApplication(data);    Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);    break;   //...    }}

       第9行，调用ActivityThread$handleBindApplication方法；

       查看ActivityThread$handleBindApplication方法源码：

private void handleBindApplication(AppBindData data) {//...final ContextImpl instrContext = ContextImpl.createAppContext(this, pi);//..final ClassLoader cl = instrContext.getClassLoader();        mInstrumentation = instantiate(cl, data.instrumentationName.getClassName(),                instrContext, Application::instantiateInstrumentation);//..Application app = data.info.makeApplication(data.restrictedBackupMode, null);//...installContentProviders(app, data.providers);//...mInstrumentation.callApplicationOnCreate(app);//...}

       handleBindApplication做的事情，有些跟启动Activity的流程比较类似，类似的代码细节就不再重复分析了。

       第5行，创建上下文环境，具体来说是创建ContextImpl对象；

       第10行，获取Instrumentation类型的对象；

       第15行，创建Application对象，由于第2个参数为null，不会调用Application$onCreate方法；

       第19行，调用ctivityThread$installContentProviders方法，启动ContentProvider，后面会重点分析；

       第23行，Instrumentation$callApplicationOnCreate方法内部，会调用Application$onCreate方法，意味着应用程序进程启动完毕。

       

       查看ActivityThread$installContentProviders方法源码：

    private void installContentProviders(            Context context, List<ProviderInfo> providers) {        final ArrayList<ContentProviderHolder> results = new ArrayList<>();        for (ProviderInfo cpi : providers) {            if (DEBUG_PROVIDER) {                StringBuilder buf = new StringBuilder(128);                buf.append("Pub ");                buf.append(cpi.authority);                buf.append(": ");                buf.append(cpi.name);                Log.i(TAG, buf.toString());            }            ContentProviderHolder cph = installProvider(context, null, cpi,                    false /*noisy*/, true /*noReleaseNeeded*/, true /*stable*/);                //...        }//...    }

       第2行，集合providers中存储了应用程序进程中所有的ProviderInfo对象，ProviderInfo封装了ContentProvider相关的信息。

       第5行，遍历集合providers；

       第14行，调用ActivityThread$installProvider方法，ProviderInfo对象作为方法的参数，启动ContentProvider；

       查看ActivityThread$installProvider方法源码：

private ContentProviderHolder installProvider(Context context,            ContentProviderHolder holder, ProviderInfo info,            boolean noisy, boolean noReleaseNeeded, boolean stable) {ContentProvider localProvider = null;        IContentProvider provider;//..final java.lang.ClassLoader cl = c.getClassLoader();localProvider = instantiate(cl, info.name, context,Application::instantiateProvider);//...localProvider.attachInfo(c, info);//...    }

       第10行，通过ClassLoader创建ContentProvider的实例；

       第15行，调用ContentProvider$attachInfo方法启动ContentProvider；

       

       查看ContentProvider$attachInfo方法源码：

public void attachInfo(Context context, ProviderInfo info) {        attachInfo(context, info, false);}//继续查看...private void attachInfo(Context context, ProviderInfo info, boolean testing) {        //...        if (mContext == null) {                // ...            ContentProvider.this.onCreate();        }}

       第15行，哇，调用了ContentProvider$onCreate方法，意味着ContentProvider已经启动了。

五，ContentProvider启动后，分析query的流程

       前面分析了ContentProvider的启动流程，下面继续分析query的流程。回到ContentResolver$query方法，该方法内部调用了IContentProvider$query方法。

       查看IContentProvider源码：

public interface IContentProvider extends IInterface {    //...    public Cursor query(String callingPkg, Uri url, @Nullable String[] projection,             @Nullable Bundle queryArgs, @Nullable ICancellationSignal cancellationSignal)             throws RemoteException;    public String getType(Uri url) throws RemoteException;    public Uri insert(String callingPkg, Uri url, ContentValues initialValues)            throws RemoteException;    public int bulkInsert(String callingPkg, Uri url, ContentValues[] initialValues)            throws RemoteException;    public int delete(String callingPkg, Uri url, String selection, String[] selectionArgs)            throws RemoteException;    public int update(String callingPkg, Uri url, ContentValues values, String selection,            String[] selectionArgs) throws RemoteException;    //...}

       原来，IContentProvider是一个接口，还继承了IInterface接口。有意思的是，在AIDL文件自动生成的java文件中，可以找到一样的结构。但这里并没有类似于Stub的类，在源码中search "extends Binder implements IContentProvider"，这个相当于Stub的类就是ContentProviderNative。

       查看ContentProviderNative源码：

abstract public class ContentProviderNative extends Binder implements IContentProvider {    public ContentProviderNative()    {        attachInterface(this, descriptor);    }    static public IContentProvider asInterface(IBinder obj)    {        if (obj == null) {            return null;        }        IContentProvider in =            (IContentProvider)obj.queryLocalInterface(descriptor);        if (in != null) {            return in;        }        return new ContentProviderProxy(obj);    }    @Override    public boolean onTransact(int code, Parcel data, Parcel reply, int flags)            throws RemoteException {        try {            switch (code) {                case QUERY_TRANSACTION:                {                    //...                    Cursor cursor = query(callingPkg, url, projection, queryArgs, cancellationSignal);                        //...code                }return super.onTransact(code, data, reply, flags);    }    //...code    @Override    public IBinder asBinder()    {        return this;    }    final class ContentProviderProxy implements IContentProvider    {    public ContentProviderProxy(IBinder remote)            {                 mRemote = remote;            }    @Override    public IBinder asBinder()    {        return mRemote;    }    @Override    public Cursor query(String callingPkg, Uri url, @Nullable String[] projection,    @Nullable Bundle queryArgs, @Nullable ICancellationSignal cancellationSignal)    throws RemoteException {BulkCursorToCursorAdaptor adaptor = new BulkCursorToCursorAdaptor();Parcel data = Parcel.obtain();Parcel reply = Parcel.obtain();//...code    mRemote.transact(IContentProvider.QUERY_TRANSACTION, data, reply, 0);    //...code    }//...code        }    //...code    }

       哇~这个结构是不是似曾相识，类ContentProviderNative相当于Stub类。接下来，需要找到接口的实现类，源码中search "extends ContentProviderNative "，这个实现类就是ContentProvider的内部类Transport。

       查看ContentProvider$Transport$query源码：

class Transport extends ContentProviderNative {//...        @Override        public Cursor query(String callingPkg, Uri uri, @Nullable String[] projection,                @Nullable Bundle queryArgs, @Nullable ICancellationSignal cancellationSignal) {//...return ContentProvider.this.query(                        uri, projection, queryArgs,                        CancellationSignal.fromTransport(cancellationSignal));//...}        //...}

       第11行，哇，最终调用了ContentProvider的query方法，这个不就是我们想要的嘛。这也验证访问ContentProvider的数据，是基于Binder机制完成了一次进程间的通信。

       值得一提的是理解这个流程，需要对AIDL文件生成的java文件有比较好的认识，由于不是本篇重点，这里不进行阐述。

六，最后

       本篇文章分两部分进行，前面一部分，用大量篇幅分析ContentProvider的启动过程，这也是本篇文章的重点；后面一部分，以查询数据为例，分析其他应用是如何访问ContentProvider暴露的数据。相信通过上面的分析，应该对ContentProvider的工作流程有比较好的认识了。同时，本篇文章到这里就结束啦~        ^_^