当前位置:   article > 正文

深入分析ContentProvider

contentprovider的apk

  ContentProvider是Android四大组件之一,承担着跨进程数据访问的重要职责。本文就从一次ContentProvider访问入手,分析下它是怎么完成跨进程数据访问的。

  既然是跨进程,那就必须有一个客户端进程和一个ContentProvider进程,我们先从客户端进程分析,看它如何访问ContentProvider进程。以Query操作为例,一般情况下,当我们需要访问ContentProvider的时候一般都会执行这么一句:

getContentResolver().query(uri, projection, selection, selectionArgs, sortOrder);

  ContentResolver是什么?Google的解释是“This class provides applications access to the content model”。实际上我们正是通过ContentResolver来获取一个IContentProvider对象,通过IContentProvider对象我们尽可以进行IPC通讯了。getContentResolver()方法定义Context类中,实际上Context是一个抽象类,在客户端应用程序中getContext()实际上返回的是一个ContextImp对象,getContentResolver()方法就定义在ContextImp.java中,并且最终返回ContextImp的内部类ApplicationContentResolver,从名字上看这是一个Application级别的对象。

  ApplicationContentResolver我们稍后再说,先看下query方法都干了什么:

public final Cursor query(final Uri uri, String[] projection,
            String selection, String[] selectionArgs, String sortOrder,
            CancellationSignal cancellationSignal) {
        IContentProvider unstableProvider = acquireUnstableProvider(uri);
        if (unstableProvider == null) {
            return null;
        }
        IContentProvider stableProvider = null;
        try {
            long startTime = SystemClock.uptimeMillis();

            ICancellationSignal remoteCancellationSignal = null;
            if (cancellationSignal != null) {
                cancellationSignal.throwIfCanceled();
                remoteCancellationSignal = unstableProvider.createCancellationSignal();
                cancellationSignal.setRemote(remoteCancellationSignal);
            }
            Cursor qCursor;
            try {
                qCursor = unstableProvider.query(uri, projection,
                        selection, selectionArgs, sortOrder, remoteCancellationSignal);
            } catch (DeadObjectException e) {
                // The remote process has died...  but we only hold an unstable
                // reference though, so we might recover!!!  Let's try!!!!
                // This is exciting!!1!!1!!!!1
                unstableProviderDied(unstableProvider);
                stableProvider = acquireProvider(uri);
                if (stableProvider == null) {
                    return null;
                }
                qCursor = stableProvider.query(uri, projection,
                        selection, selectionArgs, sortOrder, remoteCancellationSignal);
            }
            if (qCursor == null) {
                return null;
            }
            // force query execution
            qCursor.getCount();
            long durationMillis = SystemClock.uptimeMillis() - startTime;
            maybeLogQueryToEventLog(durationMillis, uri, projection, selection, sortOrder);
            // Wrap the cursor object into CursorWrapperInner object
            CursorWrapperInner wrapper = new CursorWrapperInner(qCursor,
                    stableProvider != null ? stableProvider : acquireProvider(uri));
            stableProvider = null;
            return wrapper;
        } catch (RemoteException e) {
            // Arbitrary and not worth documenting, as Activity
            // Manager will kill this process shortly anyway.
            return null;
        } finally {
            if (unstableProvider != null) {
                releaseUnstableProvider(unstableProvider);
            }
            if (stableProvider != null) {
                releaseProvider(stableProvider);
            }
        }
    }

  上面的代码有四个关键步骤:

  1. acquireUnstableProvider

  2. unstableProvider.query(......)

  3. qCursor.getCount();

  4. return new CursorWrapperInner(......)

  接下来我们一步一步分析这四个关键步骤。

  第一步:acquireUnstableProvider

  乍看上去感觉怪怪的,好端端的为什么加上了一个Unstable的标签?难道还有stable的不成?事实确实如此,我们知道此时的ContentResolver实际上是一个ApplicationContentResovler对象,来看下ApplicationContentResovler

private static final class ApplicationContentResolver extends ContentResolver {
        private final ActivityThread mMainThread;
        private final UserHandle mUser;

        public ApplicationContentResolver(
                Context context, ActivityThread mainThread, UserHandle user) {
            super(context);
            mMainThread = Preconditions.checkNotNull(mainThread);
            mUser = Preconditions.checkNotNull(user);
        }

        @Override
        protected IContentProvider acquireProvider(Context context, String auth) {
            return mMainThread.acquireProvider(context, auth, mUser.getIdentifier(), true);
        }

        @Override
        protected IContentProvider acquireExistingProvider(Context context, String auth) {
            return mMainThread.acquireExistingProvider(context, auth, mUser.getIdentifier(), true);
        }

        @Override
        public boolean releaseProvider(IContentProvider provider) {
            return mMainThread.releaseProvider(provider, true);
        }

        @Override
        protected IContentProvider acquireUnstableProvider(Context c, String auth) {
            return mMainThread.acquireProvider(c, auth, mUser.getIdentifier(), false);
        }

        @Override
        public boolean releaseUnstableProvider(IContentProvider icp) {
            return mMainThread.releaseProvider(icp, false);
        }

        @Override
        public void unstableProviderDied(IContentProvider icp) {
            mMainThread.handleUnstableProviderDied(icp.asBinder(), true);
        }
    }

  实际上,是否是stable的,都将调用ActivityThread的acquireProvider方法,区别就是最后的一个参数boolean stable。这个机制是API 16引入的,文章的最后会对此进行说明。现在我们只要知道它最终走到了ActivityThread的acquireProvider就可以了。在ActivityThread的acquireProvider方法中,我们首先会去acquireExistingProvider,从字面上就可以看出这是从一个类缓存的地方读取已经保存的ContentProvider对象,如果不存在,就会调用ActivityManagerNative.getDefault().getContentProvider(getApplicationThread(), auth, userId, stable);从这儿开始,ActivityManagerService就要登场了,上面的代码最终会通过binder通信调用ActivityManagerService的getContentProviderImpl,这块的逻辑比较复杂,涉及到了Android组件启动的过程,我们只需知道客户端调用会阻塞在ActivityManagerNative.getDefault().getContentProvider,ActivityManagerService启动目标ContentProvider进程后(如果ContentProvider进程已经存在则不必重启),返回一个目标ContentProvider的实例。在这儿需要说明的是,ContentProvider可以再Manifest中配置一个叫做android:multiprocess的属性,默认值是false,表示ContentProvider是单例的,无论哪个客户端应用的访问都将是一个ContentProvider对象(当然,必须是同一个ContentProvider,即Uri或者Authority name是一个),如果设为true,系统会为每一个访问该ContentProvider的进程创建一个实例。因为android:multiprocess的默认值是false,所以我们在写自己的ContentProvider的时候还是要注意并发的情况。

  扯得有点远了,回到我们之前步骤,我们已经得到了ContentProvider的实例,这个时候第一步就完成了,接下来看第二步。

  第二步:unstableProvider.query(......)

  unstableProvider实际上是IContentProvider实例,IContentProvider是进行IPC通讯的接口,这个query实际上调用的是目标ContentProvider中的query方法,当然,在真正调用目标ContentProvider的query方法之前,还需要经过enforceReadPermission方法,这一步主要是看下该ContentProvier有没有export,读写权限等等(enforceReadPermission方法只判断读权限)。随后执行query方法,并且返回一个cursor对象。

  以上就是第二步的大致逻辑,不过不要以为这么简单就结束了。IContentProvider的query可是跨进程的,我们知道ContentProvider的query方法可是五花八门,有访问数据库返回SQLiteCursor的,有返回MatrixCursor的等等,那么IContentProvider返回的那个cursor到底是什么呢?我们来看下IContentProvider的这个IPC通信到底是怎么回事

  IPC通信需要两端,对于我们的例子,这两段分别是ContentProviderProxy和ContentProviderNative,首先会执行ContentProviderProxy的query方法,然后通过binder通信执行ContentProviderNative的onTransact方法。ContentProviderProxy的query方法有一下五个主要步骤:

  1. new一个BulkCursorToCursorAdaptor对象——adaptor

  2. 填充data用于binder通信

  3. 调用mRemote.transact,这是一个阻塞的过程,直到ContentProviderNative的onTransact方法返回

  4. 读取reply数据,new一个BulkCursorDescriptor并以此初始化adaptor

  5. return adaptor

  ContentProviderNative的onTransact会调用ContentProvider的query方法,并根据query返回的cursor初始化一个CursorToBulkCursorAdaptor对象,最终将BulkCursorDescriptor对象写入reply中。

  至此我们知道了,不管我们的ContentProvider query方法返回的到底是什么样的cursor,最终在客户端进程都将会被封装在一个BulkCursorToCursorAdaptor对象中,那么这个BulkCursorToCursorAdaptor对象是不是就是我们在客户端调用query返回的最终类型呢?别急,往下看。

  第三步:qCursor.getCount();

  这一步看似鸡肋,实际上涉及到了SQLiteCursor的一个设计要点,那就是SQLiteCursor的内存共享。getCount会调用SQLiteCursor的fillWindow,在以后的文章中我会在讲到SQLiteCursor,在此我们只要知道它是强制执行数据库query就可以了。

  第四步:return new CursorWrapperInner(......)

  哈,看到了吧,我们在客户端调用query最终返回的是一个CursorWrapperInner类型,它是ContentResolver的一个内部类。实际上我们常用的getCount,onMove等一些列方法都是通过BulkCursorToCursorAdaptor和CursorToBulkCursorAdaptor的交互实现的。

 

  到此,ContentProvider的访问流程就结束了,下面说一下开头买的坑:unstable和stable的ContentProvider。

  

  在4.1之前,我们都可能会遇到过这样的场景,我们的应用程序访问了ContentProvider,但是这个ContentProvider意外挂了,这个时候我们的应用程序也将被连带杀死!这是Android处于对数据安全的考虑而做的决定,不过貌似Google也感觉这样的方式不太友好,所以在4.1以后提出了stable和unstable的概念。对于ContentResolver的query方法,我们将默认使用unstable的ContentProvider。看看下面的代码

       Cursor qCursor;
            try {
                qCursor = unstableProvider.query(uri, projection,
                        selection, selectionArgs, sortOrder, remoteCancellationSignal);
            } catch (DeadObjectException e) {
                // The remote process has died...  but we only hold an unstable
                // reference though, so we might recover!!!  Let's try!!!!
                // This is exciting!!1!!1!!!!1
                unstableProviderDied(unstableProvider);
                stableProvider = acquireProvider(uri);
                if (stableProvider == null) {
                    return null;
                }
                qCursor = stableProvider.query(uri, projection,
                        selection, selectionArgs, sortOrder, remoteCancellationSignal);
            }

  上面是ContentResolver query中的一部分,可以看出unstable ContentProvider在query过程中如果发生了DeadObjectExeption则会被捕获,进而重新获取一个stable的ContentProvider。其实深入分析stable和unstable的ContentProvider还会有很多内容,以后有时间再说。

转载于:https://www.cnblogs.com/zhainanJohnny/articles/3275908.html

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/我家自动化/article/detail/874079
推荐阅读
相关标签
  

闽ICP备14008679号