Android应用程序组件Content Provider在应用程序之间共享数据的原理分析.docx
《Android应用程序组件Content Provider在应用程序之间共享数据的原理分析.docx》由会员分享，可在线阅读，更多相关《Android应用程序组件Content Provider在应用程序之间共享数据的原理分析.docx（43页珍藏版）》请在冰豆网上搜索。
Android应用程序组件ContentProvider在应用程序之间共享数据的原理分析
Android应用程序组件ContentProvider在应用程序之间共享数据的原理分析
在Android系统中，不同的应用程序是不能直接读写对方的数据文件的，如果它们想共享数据的话，只能通过ContentProvider组件来实现。
那么，ContentProvider组件又是如何突破应用程序边界权限控制来实现在不同的应用程序之间共享数据的呢？
在前面的文章中，我们已经简要介绍过它是通过Binder进程间通信机制以及匿名共享内存机制来实现的，在本文中，我们将详细分析它的数据共享原理。
Android应用程序之间不能直接访问对方的数据文件的障碍在于每一个应用程序都有自己的用户ID，而每一个应用程序所创建的文件的读写权限都是只赋予给自己所属的用户，因此，就限制了应用程序之间相互读写数据的操作，关于Android应用程序的权限问题，具体可以参考前面一篇文章。
通过前面等一系列文章的学习，我们知道，Binder进程间通信机制可以突破了以应用程序为边界的权限控制来实现在不同应用程序之间传输数据，而ContentProvider组件在不同应用程序之间共享数据正是基于Binder进程间通信机制来实现的。
虽然Binder进程间通信机制突破了以应用程序为边界的权限控制，但是它是安全可控的，因为数据的访问接口是由数据的所有者来提供的，换句话来说，就是数据提供方可以在接口层来实现安全控制，决定哪些数据是可以读，哪些数据可以写。
虽然ContentProvider组件本身也提供了读写权限控制，但是它的控制粒度是比较粗的，如果有需要，我们还是可以在接口访问层做更细粒度的权限控制以达到数据安全的目的。
Binder进程间通信机制虽然打通了应用程序之间共享数据的通道，但是还有一个问题需要解决，那就是数据要以什么来作来媒介来传输。
我们知道，应用程序采用Binder进程间通信机制进行通信时，要传输的数据都是采用函数参数的形式进行的，对于一般的进程间调来来说，这是没有问题的，然而，对于应用程序之间的共享数据来说，它们的数据量可能是非常大的，如果还是简单的用函数参数的形式来传递，效率就会比较低下。
通过前面等一系列文章的学习，我们知道，在应用程序进程之间以匿名共享内存的方式来传输数据效率是非常高的，因为它们之间只需要传递一个文件描述符就可以了。
因此，ContentProvider组件在不同应用程序之间传输数据正是基于匿名共享内存机制来实现的。
在继续分析ContentProvider组件在不同应用程序之间共享数据的原理之前，我们假设应用程序之间需要共享的数据是保存在数据库（SQLite）中的，因此，接下来的分析都是基于SQLite数据库游标（SQLiteCursor）来进行的。
SQLiteCursor在共享数据的传输过程中发挥着重要的作用，因此，我们先来它和其它相关的类的关系图，如下所示：
首先在第三方应用程序这一侧，当它需要访问ContentProvider中的数据时，它会在本进程中创建一个CursorWindow对象，它在内部创建了一块匿名共享内存，同时，它实现了Parcel接口，因此它可以在进程间传输。
接下来第三方应用程序把这个CursorWindow对象（连同它内部的匿名共享内存文件描述符）通过Binder进程间调用传输到ContentProvider这一侧。
这个匿名共享内存文件描述符传输到Binder驱动程序的时候，Binder驱动程序就会在目标进程（即ContentProvider所在的进程）中创建另一个匿名共享文件描述符，指向前面已经创建好的匿名共享内存，因此，就实现了在两个进程中共享同一块匿名内存，这个过程具体可以参考一文。
在ContentProvider这一侧，利用在Binder驱动程序为它创建好的这个匿名共享内存文件描述符，在本进程中创建了一个CursorWindow对象。
现在，ContentProvider开始要从本地中从数据库中查询第三方应用程序想要获取的数据了。
ContentProvider首先会创建一个SQLiteCursor对象，即SQLite数据库游标对象，它继承了AbstractWindowedCursor类，后者又继承了AbstractCursor类，而AbstractCursor类又实现了CrossProcessCursor和Cursor接口。
其中，最重要的是在AbstractWindowedCursor类中，有一个成员变量mWindow，它的类型为CursorWindow，这个成员变量是通过AbstractWindowedCursor的子类SQLiteCursor的setWindow成员函数来设置的。
这个SQLiteCursor对象设置好了父类AbstractWindowedCursor类的mWindow成员变量之后，它就具有传输数据的能力了，因为这个mWindow对象内部包含一块匿名共享内存。
此外，这个SQLiteCursor对象的内部有两个成员变量，一个是SQLite数据库对象mDatabase，另外一个是SQLite数据库查询对象mQuery。
SQLite数据库查询对象mQuery的类型为SQLiteQuery，它继承了SQLiteProgram类，后者又继承了SQLiteClosable类。
SQLiteProgram类代表一个数据库存查询计划，它的成员变量mCompiledSql包含了一个已经编译好的SQL查询语句，SQLiteCursor对象就是利用这个编译好的SQL查询语句来获得数据的，但是它并不是马上就去获取数据的，而是等到需要时才去获取。
那么，要等到什么时候才会需要获取数据呢？
一般来说，如果第三方应用程序在请求ContentProvider返回数据时，如果指定了要返回关于这些数据的元信息时，例如数据条目的数量，那么ContentProvider在把这个SQLiteCursor对象返回给第三方应用程序之前，就会去获取数据，因为只有获取了数据之后，才知道数据条目的数量是多少。
SQLiteCursor对象通过调用成员变量mQuery的fillWindow成员函数来把从SQLite数据库中查询得到的数据保存其父类AbstractWindowedCursor的成员变量mWindow中去，即保存到第三方应用程序创建的这块匿名共享内存中去。
如果第三方应用程序在请求ContentProvider返回数据时，没有指定要返回关于这些数据的元信息，那么，就要等到第三方应用程序首次调用这个从ContentProvider处返回的SQLiteCursor对象的数据获取方法时，才会真正执行从数据库存中查询数据的操作，例如调用了SQLiteCursor对象的getCount或者moveToFirst成员函数时。
这是一种数据懒加载机制，需要的时候才去加载，这样就提高了数据传输过程中的效率。
上面说到，ContentProvider向第三方应用程序返回的数据实际上是一个SQLiteCursor对象，那么，这个SQLiteCursor对象是如何传输到第三方应用程序的呢？
因为它本身并不是一个Binder对象，我们需要对它进行适配一下。
首先，ContentProvider会根据这个SQLiteCursor对象来创建一个CursorToBulkCursorAdaptor适配器对象，这个适配器对象是一个Binder对象，因此，它可以在进程间传输，同时，它实现了IBulkCursor接口。
ContentProvider接着就通过Binder进程间通信机制把这个CursorToBulkCursorAdaptor对象返回给第三方应用程序，第三方应用程序得到了这个CursorToBulkCursorAdaptor之后，再在本地创建一个BulkCursorToCursorAdaptor对象，这个BulkCursorToCursorAdaptor对象的继承结构和SQLiteCursor对象是一样的，不过，它没有设置父类AbstractWindowedCursor的mWindow成员变量，因此，它只可以通过它内部的CursorToBulkCursorAdaptor对象引用来访问匿名共享内存中的数据，即通过访问ContentProvider这一侧的SQLiteCursor对象来访问共享数据。
上面描述的数据共享模型还是比较复杂的，一下子理解不了也不要紧，下面我们还会结合第三方应用程序和ContentProvider传输共享数据的完整过程来进一步分析ContentProvider的数据共享原理，到时候再回过头来看这个数据共享模型就会清晰很多了。
在接下来的内容中，我们就继续以一文的例子来分析ContentProvider在不同应用程序之间共享数据的原理。
在这篇文章介绍的应用程序Article中，它的主窗口MainActivity是通过调用它的内部ArticlesAdapter对象的getArticleByPos成员函数来把ArticlesProvider中的文章信息条目一条一条地取回来显示在ListView中的，在这篇文章中，我们就从ArticlesAdapter类的getArticleByPos函数开始，一步一步地分析第三方应用程序Article从ArticlesProvider这个ContentProvider中获取数据的过程。
同样，我们先来看看这个过程的序列图，然后再详细分析每一个步骤：
这个函数定义在前面一篇文章介绍的应用程序Artilce源代码工程目录下，在文件为packages/experimental/Article/src/shy/luo/article/ArticlesAdapter.Java中：
[java]viewplaincopy在CODE上查看代码片派生到我的代码片
publicclassArticlesAdapter{
......
privateContentResolverresolver=null;
publicArticlesAdapter（Contextcontext）{
resolver=context.getContentResolver（）;
}
......
publicArticlegetArticleByPos（intpos）{
Uriuri=ContentUris.withAppendedId（Articles.CONTENT_POS_URI,pos）;
String[]projection=newString[]{
Articles.ID,
Articles.TITLE,
Articles.ABSTRACT,
Articles.URL
};
Cursorcursor=resolver.query（uri,projection,null,null,Articles.DEFAULT_SORT_ORDER）;
if（!
cursor.moveToFirst（））{
returnnull;
}
intid=cursor.getInt（0）;
Stringtitle=cursor.getString
（1）;
Stringabs=cursor.getString
（2）;
Stringurl=cursor.getString（3）;
returnnewArticle（id,title,abs,url）;
}
}
这个函数通过应用程序上下文的ContentResolver接口resolver的query函数来获得与Articles.CONTENT_POS_URI这个URI对应的文章信息条目。
常量Articles.CONTENT_POS_URI是在应用程序ArticlesProvider中定义的，它的值为“content:
//shy.luo.providers.articles/pos”，通过调用ContentUris.withAppendedId函数来在后面添加了一个整数，表示要获取指定位置的文章信息条目。
这个位置是指ArticlesProvider这个ContentProvider中的所有文章信息条目按照Articles.DEFAULT_SORT_ORDER来排序后得到的位置的，常量Articles.DEFAULT_SORT_ORDER也是在应用程序ArticlesProvider中定义的，它的值为“_idasc”，即按照文章信息的ID值从小到大来排列。
Step2.ContentResolver.query
这个函数定义在frameworks/base/core/java/android/content/ContentResolver.java文件中：
[java]viewplaincopy在CODE上查看代码片派生到我的代码片
publicabstractclassContentResolver{
......
publicfinalCursorquery（Uriuri,String[]projection,
Stringselection,String[]selectionArgs,StringsortOrder）{
IContentProviderprovider=acquireProvider（uri）;
if（provider==null）{
returnnull;
}
try{
......
CursorqCursor=provider.query（uri,projection,selection,selectionArgs,sortOrder）;
......
returnnewCursorWrapperInner（qCursor,provider）;
}catch（RemoteExceptione）{
......
}catch（RuntimeExceptione）{
......
}
}
......
}
这个函数首先通过调用acquireProvider函数来获得与参数uri对应的ContentProvider接口，然后再通过这个接口的query函数来获得相应的数据。
我们先来看看acquireProvider函数的实现，再回过头来分析这个ContentProvider接口的query函数的实现。
Step3.ContentResolver.acquireProvider
Step4.ApplicationContentResolver.acquireProvider
Step5.ActivityThread.acquireProvider
Step6.ActivityThread.getProvider
从Step3到Step6是获取与上面Step2中传进来的参数uri对应的ContentProvider接口的过程。
在前面一篇文章中，我们已经详细介绍过这个过程了，这里不再详述。
不过这里我们假设，这个ContentProvider接口之前已经创建好了，因此，在Step6的ActivityThread.getProvider函数中，通过getExistingProvider函数就把之前已经好的ContentProvider接口返回来了。
回到Step2中的ContentResolver.query函数中，它继续调用这个返回来的ContentProvider接口来获取数据。
从这篇文章中，我们知道，这个ContentProvider接口实际上是一个在ContentProvider类的内部所创建的一个Transport对象的远程接口。
这个Transport类继承了ContentProviderNative类，是一个Binder对象的Stub类，因此，接下来就会进入到这个Binder对象的Proxy类ContentProviderProxy中执行query函数。
Step7.ContentProviderProxy.query
这个函数定义在frameworks/base/core/java/android/content/ContentProviderNative.java文件中：
[java]viewplaincopy在CODE上查看代码片派生到我的代码片
finalclassContentProviderProxyimplementsIContentProvider{
......
publicCursorquery（Uriurl,String[]projection,Stringselection,
String[]selectionArgs,StringsortOrder）throwsRemoteException{
//TODOmakeapoolofwindowssowecanreusememorydealers
CursorWindowwindow=newCursorWindow（false/*windowwillbeusedremotely*/）;
BulkCursorToCursorAdaptoradaptor=newBulkCursorToCursorAdaptor（）;
IBulkCursorbulkCursor=bulkQueryInternal（
url,projection,selection,selectionArgs,sortOrder,
adaptor.getObserver（）,window,
adaptor）;
if（bulkCursor==null）{
returnnull;
}
returnadaptor;
}
......
}
这个函数首先会创建一个CursorWindow对象，前面已经说过，这个CursorWindow对象包含了一块匿名共享内存，它的作用是把这块匿名共享内存通过Binder进程间通信机制传给ContentProivder，好让ContentProivder在里面返回所请求的数据。
下面我们就先看看这个CursorWindow对象的创建过程，重点关注它是如何在内部创建匿名共享内存的，然后再回过头来看看它调用bulkQueryInternal函数来做了些什么事情。
CursorWindow类定义在frameworks/base/core/java/android/database/CursorWindow.java文件中，我们来看看它的构造函数的实现：
[java]viewplaincopy在CODE上查看代码片派生到我的代码片
publicclassCursorWindowextendsSQLiteClosableimplementsParcelable{
......
privateintnWindow;
......
publicCursorWindow（booleanlocalWindow）{
......
native_init（localWindow）;
}
......
}
它主要调用本地方法native_init来执行初始化的工作，主要就是创建匿名共享内存了，传进来的参数localWindow为false，表示这个匿名共享内存只能通过远程调用来访问，即前面我们所说的，通过ContentProivder返回来的Cursor接口来访问这块匿名共享内存里面的数据。
Step8.CursorWindow.native_init
这是一个JNI方法，它对应定义在frameworks/base/core/jni/android_database_CursorWindow.cpp文件中的native_init_empty函数：
[cpp]viewplaincopy在CODE上查看代码片派生到我的代码片
staticJNINativeMethodsMethods[]=
{
/*name,signature,funcPtr*/
{"native_init","（Z）V",（void*）native_init_empty},
......
};
函数native_init_empty的定义如下所示：
[cpp]viewplaincopy在CODE上查看代码片派生到我的代码片
staticvoidnative_init_empty（JNIEnv*env,jobjectobject,jbooleanlocalOnly）
{
......
CursorWindow*window;
window=newCursorWindow（MAX_WINDOW_SIZE）;
......
if（!
window->initBuffer（localOnly））{
......
}
......
SET_WINDOW（env,object,window）;
}
这个函数在C++层创建了一个CursorWindow对象，然后通过调用SET_WINDOW宏来把这个C++层的CursorWindow对象与Java层的CursorWindow对象关系起来：
[cpp]viewplaincopy在CODE上查看代码片派生到我的代码片
#defineSET_WINDOW（env,object,window）（env->SetIntField（object,gWindowField,（int）window））
这里的gWindowField即定义为Java层的CursorWindow对象中的nWindow成员变量：
[cpp]viewplaincopy在CODE上查看代码片派生到我的代码片
staticjfieldIDgWindowField;
......
intregister_android_database_CursorWindow（JNIEnv*env）
{
jclassclazz;
clazz=env->FindClass（"android/database/CursorWindow"）;
......
gWindowField=env->GetFieldID（clazz,"nWindow","I"）;
......
}
这种用法在Android应用程序框架层中非常普遍。
下面我们重点关注C++层的CursorWindow对象的initBuffer函数的实现。
Step9.CursorWindow.initBuffer
C++层的CursorWindow类定义在frameworks/base/core/jni/C
升级会员 