ContentProvider学习笔记
2016-06-30 14:09
417 查看
一、什么ContentProvider
。。。
二、如何使用ContentProvider
。。。
三、沙场练兵-实例操练
。。。
四、深入理解ContentProvider原理
为什么使用ContentProvider可以实现跨进程的通讯,第一反应肯定是这货和binder有关,因为android中只有稍微跟跨进程搭上边的,必定想到binder。
下面就来分析ContentProvider是怎么一步一步利用binder实现跨进程通信的:
1、首先你得创建一个ContentProvider运行在进程A,如上篇博客
AndroidManifest.xml中定义provider:
<provider
android:name=".MyContentProvider"
android:authorities="telefk"//这个很重要,Uri中的主机名,查询数据就靠它
android:enabled="true"
android:exported="true">
</provider>
2、进程B中通过如下接口来访问进程A的数据:
getContentResolver().query(uri,columns,null,null,null);
getContentResolver()实际调用的ContextImpl.java的方法返回mContentResolver对象
此对象在ContextImpl的构造方法中实例化
mContentResolver = new ApplicationContentResolver(this, mainThread, user);
现在来看query方法,其在ContentResolver.java中定义:
接下来看acquireUnstableProvider()函数:
百转千回,最终走到了刚刚返回的ApplicationContentResolver.java中
+
View Code
这里又调用了ActivityThread.java 的acquireProvider()方法,我们继续往下跟:
我们继续来看ActivityManagerService.java 的getContentProvider()方法:
肾呐~还没到头!又继续往下走,大家坚持:
// First check if this content provider has been published...
cpr = mProviderMap.getProviderByName(name, userId);
......
如果发现对应的provider 已经运行,这个我们之后再分析,先分析没有运行的情况:
客户端(应用B)获得cotentprovider 客户端的代理ContentProviderProxy对象,然后调用它的query方法,切记此时还是运行在自己进程中!
经过query方法,终于走到了应用A进程
cursor从进程A传到进程B,BulkCursorDescriptor肯定是Parcelable类型
大体流程是这样,难点是中间的细节,特别是获得provider这个过程非常繁琐,设计到很多数据结构和其他模块的内容,这块需要慢慢啃。
一.Android四大组件
Android四大组件是Activity, Service, Content Provider, Broadcast Receiver。
Activity作为程序界面,直接与用户交互
Service运行在后台,没有界面,完成特定的功能
ContentProvider维护应用数据,方便应用本身或其它应用访问
Broadcast Receiver提供异步广播消息接收机制,便于各应用/组件进行交互
通过AndroidManifest.xml, 可以看到一个应用使用了哪些组件:
attribute的定义可以参考http://developer.android.com/guide/topics/manifest/manifest-intro.html
下面重点探讨Content Provider的实现和使用。
二. 什么是ContentProvider
Content Provider维护特定的应用数据,并可以让其它应用轻松访问该数据。对数据使
用者来说它是数据提供者。它提供统一的接口对数据进行操作,使用者不用关心数据到底是如何存储的以及数据类型到底是什么。也就是说,Content Provider作为数据提供者,提供了对外共享本地数据一种机制,使Android应用能方便地基于该机制进行数据访问。
为了便于管理和访问,每个Content Provider必须有唯一标示,用Uri表示。Uri类似http url, 构成如下:
content://authority/path
所有Content Provider的Uri必须以content://开头,这是Android规定的。
authority是个字符串,它由开发者自己定义,用于来唯一标示一个ContentProvider。系统会根据这个标示查找ContentProvider。
path也是字符串,表示要操作的数据。可根据自己的实现逻辑来指定:
content://contacts/people表示要操作ContentProvider为contacts下的people表
content://com.android.contacts/people/#表示要操作表people中特定id的行(记录)。
content://downloads/download/10/name表示要操作id为10的行的name字段。
content://downloads/download/*表示操作download表中的所有字段。
总之,#匹配一个数字字符串,*匹配一个文本字符串。
三.ContentProvider 的实现和使用
可以看出 , 实现一个自定义的Content Provider,要基于系统提供的基类ContentProvider,需要实现6个接口。大部分接口就是类似数据库的数据操作接口,实际上Content Provider是需要创建数据库并对数据库进行操作的。完成实现之后,在Androidmanifest.xml中声明自己的Content Provider以及与Provider相关的permission声明(可以没有permission定义)。例如:
最后整个应用被编译成apk。安装之后,该应用里的contentProvider就可以被其它应用访问了。对于Provider使用者来说, 如果特定Provider有permission要求,则要在自己的Androidmanifest.xml中添加指定Permission引用, 如:
使用非常简单,Android提供了Context级别的ContentResolver对象来对Content Provider进行操作。正是因为有了ContentResolver, 使用者才不用关心Provider到底是哪个应用或哪个类实现的。只要知道它的uri就能访问。ContentResolver对象存在于每个Context中。几乎所有对象都有自己的Context。
有些情况下,Content Provider使用者想监听数据的变化,可以注册一个Observer:
四. ContentProvider内部机制
1.ContentProvider接口调用过程
ContentProvider依赖ContentResolver/ActivityThread/ActivityManagerService对外提供
服务。虽然ContentProvider的用法以及表现形式不是一个Service,实际上它可以看作是ActivityManagerService提供的一种服务, 它实现了IBinder接口。
首先调用者通过特定uri调用特定ContentProvider的接口函数,比如insert(), 此时ContentResolver会通过uri获取特定ContentProvider的实例,ActivityThread检查本地Cache,如果发现此ContentProvider已经被引用过,则直接直接取出ContentProvider返回给调用者。如果没有发现,由于 ContentProvider可能已经被load了,可能还没有load;可能要创建Process,可能要检查permission,所以ActivityThread调用到ActivityManagerService来进行相关处理/检查。如果该Provider是Single
Process,ActivityManagerService会为ContentProvider创建一个独立Process;如果是MultiProcess,说明每个调用者可以拥有独立的ContentProvider实例,于是ActivityManagerService只是返回ContentProvider的相关信息给ActivityThread,由ActivityThread负责ContentProvider的实例化,此时ContentProvider运行在调用者Process中。实例化后,IConentProvider会返回给调用者,通过该接口可以调用所需功能。
ActivityThread本地维护一个mProviderMap <ProviderName, ProviderRecord >,记录已被引用的ContentProvider, 同时使用引用计数mProviderRefCountMap <IBinder, ProviderRefCount>记录特定ContentProvider的引用情况。
2.ContentProvider实例创建过程
ContentProvider实例的创建与multiprocess属性有关系(Androidmanifest.xml里指定),个人认为理解成多进程并不准确。应该理解为ContentProvider的多实例,不会存在多个ContentProvider进程的情况,ContentProvider 可能存在多个实例。
1) 对于android:multiprocess=true的ContentProvider,意味着可以多实例,那么由调用者在自己的进程空间实例化一个ContentProvider对象,此时定义ContentProvider的App可能并没有启动
注意:ContentProvider是否多实例,还得看contentProvider的uid与调用者的uid是否相同或contentProvider的uid是System user。具体逻辑是:
public boolean canRunHere(ProcessRecord app) {
return (info.multiprocess || info.processName.equals(app.processName))
&& (uid == Process.SYSTEM_UID || uid == app.info.uid);
}
2)对于android:multiprocess=false(默认值)的ContentProvider,由系统把定义该ContentProvider的App启动起来(一个独立的Process)并实例化ContentProvider,这种ContentProvider只有一个实例,运行在自己App的Process中。所有调用者共享该ContentProvider实例,调用者与ContentProvider实例位于两个不同的Process
其中Process.start()->zygoteSendArgsAndGetPid()->ZygoteInit.runSelectLoopMode()
-> ZygoteConnection.runOnce() -> Zygote.forkAndSpecialize()->RuntimeInit.zygoteInit()
-> invokeStaticMain()->MethodAndArgsCaller.run()->Method.invokeNative
->ActivityThread.main(),这是通用的APK启动流程。
3)ContentProvider的加载/发布过程
ContentProvider不能单独发布,总是被打包到某个Android应用(apk)里。APK被安装之后,实例化之后每个Android应用都有一个Application实例,每个Activity或Service有一个ApplicationContext实例。
Android应用程序的入口函数是ActivityThread.main(), 该函数不仅创建了ActivityThread实例以及消息循环机构,而且创建了ApplicationThread实例,通过此实例向Activity Manager Service(AMS)提供IApplicationThread接口,AMS正是通过该接口调度和管理Activity。
ActivityThread通过attachApplication()把自己的ApplicationThread实例告知AMS。
AMS根据thread信息更新进程记录(ProcessRecord)并调用thread的bindApplication()进行初始化工作并创建ApplicationContext和Application实例,然后安装package里声明的所有contentProvider。 主要过程如下:
AMS维护了很多信息,其中比较重要的有:
mProcessNames: 包名(processName)和进程信息(ProcessRecord)映射表
mProvidersByName: Provider发布名和Provider信息(ContentProviderRecord)映射表
mProvidersByClass: Provider类名和Provider信息(ContentProviderRecord)映射表
conProviders:属于ProcessRecord信息,特定Process正在使用的ContentProvider及其个数映射表
pubProviders:属于ProcessRecord信息,特定Process已经Published的Provider类名和Provider信息
(ContentProviderRecord)映射表
ActivityThread维护了3个与ContentProvider相关的Map:
mProviderMap: 记录本应用已使用的Provider信息:<Provider发布名, ProviderRecord>
mProviderRefCountMap: 记录本应用已使用的Provider引用计数信息:<IBinder, ProviderRefCount>
mLocalProviders: 记录本地加载的Provider信息:<IBinder, ProviderRecord>
4)ContentProvider通知机制
注意:这个通知机制需要ContentProvider的实现者在实现insert/delete/query/update接口时调用ContentResolver的notifyChange(), 否则没法实现数据变化的通知。
。。。
二、如何使用ContentProvider
。。。
三、沙场练兵-实例操练
。。。
四、深入理解ContentProvider原理
为什么使用ContentProvider可以实现跨进程的通讯,第一反应肯定是这货和binder有关,因为android中只有稍微跟跨进程搭上边的,必定想到binder。
下面就来分析ContentProvider是怎么一步一步利用binder实现跨进程通信的:
1、首先你得创建一个ContentProvider运行在进程A,如上篇博客
AndroidManifest.xml中定义provider:
<provider
android:name=".MyContentProvider"
android:authorities="telefk"//这个很重要,Uri中的主机名,查询数据就靠它
android:enabled="true"
android:exported="true">
</provider>
2、进程B中通过如下接口来访问进程A的数据:
getContentResolver().query(uri,columns,null,null,null);
getContentResolver()实际调用的ContextImpl.java的方法返回mContentResolver对象
此对象在ContextImpl的构造方法中实例化
mContentResolver = new ApplicationContentResolver(this, mainThread, user);
现在来看query方法,其在ContentResolver.java中定义:
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"); IContentProvider unstableProvider = acquireUnstableProvider(uri);//这个函数很关键,通过指定的Uri找到我们刚刚定义的provider if (unstableProvider == null) { return null; } IContentProvider stableProvider = null; ......
接下来看acquireUnstableProvider()函数:
百转千回,最终走到了刚刚返回的ApplicationContentResolver.java中
+
View Code
这里又调用了ActivityThread.java 的acquireProvider()方法,我们继续往下跟:
@Override public final ContentProviderHolder getContentProvider( IApplicationThread caller, String name, int userId, boolean stable) { enforceNotIsolatedCaller("getContentProvider"); if (caller == null) { String msg = "null IApplicationThread when getting content provider " + name; Slog.w(TAG, msg); throw new SecurityException(msg); } // The incoming user check is now handled in checkContentProviderPermissionLocked() to deal // with cross-user grant. return getContentProviderImpl(caller, name, null, stable, userId); }
肾呐~还没到头!又继续往下走,大家坚持:
//这个方法很长,我们挑选重点的分析,方法第二个参数name就是我们刚刚query传进来的uir的authority private final ContentProviderHolder getContentProviderImpl(IApplicationThread caller, String name, IBinder token, boolean stable, int userId) { ContentProviderRecord cpr;//AMS中用来记录provider的,还有其他三大组件AcitityRecord、ServiceRecord、BroadcastRecord ContentProviderConnection conn = null; ProviderInfo cpi = null;//这个应该是PMS解析应用的AndroidManifest得来的信息 ......
// First check if this content provider has been published...
cpr = mProviderMap.getProviderByName(name, userId);
......
如果发现对应的provider 已经运行,这个我们之后再分析,先分析没有运行的情况:
大体流程是这样,难点是中间的细节,特别是获得provider这个过程非常繁琐,设计到很多数据结构和其他模块的内容,这块需要慢慢啃。
一.Android四大组件
Android四大组件是Activity, Service, Content Provider, Broadcast Receiver。
Activity作为程序界面,直接与用户交互
Service运行在后台,没有界面,完成特定的功能
ContentProvider维护应用数据,方便应用本身或其它应用访问
Broadcast Receiver提供异步广播消息接收机制,便于各应用/组件进行交互
通过AndroidManifest.xml, 可以看到一个应用使用了哪些组件:
attribute的定义可以参考http://developer.android.com/guide/topics/manifest/manifest-intro.html
下面重点探讨Content Provider的实现和使用。
二. 什么是ContentProvider
Content Provider维护特定的应用数据,并可以让其它应用轻松访问该数据。对数据使
用者来说它是数据提供者。它提供统一的接口对数据进行操作,使用者不用关心数据到底是如何存储的以及数据类型到底是什么。也就是说,Content Provider作为数据提供者,提供了对外共享本地数据一种机制,使Android应用能方便地基于该机制进行数据访问。
为了便于管理和访问,每个Content Provider必须有唯一标示,用Uri表示。Uri类似http url, 构成如下:
content://authority/path
所有Content Provider的Uri必须以content://开头,这是Android规定的。
authority是个字符串,它由开发者自己定义,用于来唯一标示一个ContentProvider。系统会根据这个标示查找ContentProvider。
path也是字符串,表示要操作的数据。可根据自己的实现逻辑来指定:
content://contacts/people表示要操作ContentProvider为contacts下的people表
content://com.android.contacts/people/#表示要操作表people中特定id的行(记录)。
content://downloads/download/10/name表示要操作id为10的行的name字段。
content://downloads/download/*表示操作download表中的所有字段。
总之,#匹配一个数字字符串,*匹配一个文本字符串。
三.ContentProvider 的实现和使用
可以看出 , 实现一个自定义的Content Provider,要基于系统提供的基类ContentProvider,需要实现6个接口。大部分接口就是类似数据库的数据操作接口,实际上Content Provider是需要创建数据库并对数据库进行操作的。完成实现之后,在Androidmanifest.xml中声明自己的Content Provider以及与Provider相关的permission声明(可以没有permission定义)。例如:
最后整个应用被编译成apk。安装之后,该应用里的contentProvider就可以被其它应用访问了。对于Provider使用者来说, 如果特定Provider有permission要求,则要在自己的Androidmanifest.xml中添加指定Permission引用, 如:
使用非常简单,Android提供了Context级别的ContentResolver对象来对Content Provider进行操作。正是因为有了ContentResolver, 使用者才不用关心Provider到底是哪个应用或哪个类实现的。只要知道它的uri就能访问。ContentResolver对象存在于每个Context中。几乎所有对象都有自己的Context。
有些情况下,Content Provider使用者想监听数据的变化,可以注册一个Observer:
四. ContentProvider内部机制
1.ContentProvider接口调用过程
ContentProvider依赖ContentResolver/ActivityThread/ActivityManagerService对外提供
服务。虽然ContentProvider的用法以及表现形式不是一个Service,实际上它可以看作是ActivityManagerService提供的一种服务, 它实现了IBinder接口。
首先调用者通过特定uri调用特定ContentProvider的接口函数,比如insert(), 此时ContentResolver会通过uri获取特定ContentProvider的实例,ActivityThread检查本地Cache,如果发现此ContentProvider已经被引用过,则直接直接取出ContentProvider返回给调用者。如果没有发现,由于 ContentProvider可能已经被load了,可能还没有load;可能要创建Process,可能要检查permission,所以ActivityThread调用到ActivityManagerService来进行相关处理/检查。如果该Provider是Single
Process,ActivityManagerService会为ContentProvider创建一个独立Process;如果是MultiProcess,说明每个调用者可以拥有独立的ContentProvider实例,于是ActivityManagerService只是返回ContentProvider的相关信息给ActivityThread,由ActivityThread负责ContentProvider的实例化,此时ContentProvider运行在调用者Process中。实例化后,IConentProvider会返回给调用者,通过该接口可以调用所需功能。
ActivityThread本地维护一个mProviderMap <ProviderName, ProviderRecord >,记录已被引用的ContentProvider, 同时使用引用计数mProviderRefCountMap <IBinder, ProviderRefCount>记录特定ContentProvider的引用情况。
2.ContentProvider实例创建过程
ContentProvider实例的创建与multiprocess属性有关系(Androidmanifest.xml里指定),个人认为理解成多进程并不准确。应该理解为ContentProvider的多实例,不会存在多个ContentProvider进程的情况,ContentProvider 可能存在多个实例。
1) 对于android:multiprocess=true的ContentProvider,意味着可以多实例,那么由调用者在自己的进程空间实例化一个ContentProvider对象,此时定义ContentProvider的App可能并没有启动
注意:ContentProvider是否多实例,还得看contentProvider的uid与调用者的uid是否相同或contentProvider的uid是System user。具体逻辑是:
public boolean canRunHere(ProcessRecord app) {
return (info.multiprocess || info.processName.equals(app.processName))
&& (uid == Process.SYSTEM_UID || uid == app.info.uid);
}
2)对于android:multiprocess=false(默认值)的ContentProvider,由系统把定义该ContentProvider的App启动起来(一个独立的Process)并实例化ContentProvider,这种ContentProvider只有一个实例,运行在自己App的Process中。所有调用者共享该ContentProvider实例,调用者与ContentProvider实例位于两个不同的Process
其中Process.start()->zygoteSendArgsAndGetPid()->ZygoteInit.runSelectLoopMode()
-> ZygoteConnection.runOnce() -> Zygote.forkAndSpecialize()->RuntimeInit.zygoteInit()
-> invokeStaticMain()->MethodAndArgsCaller.run()->Method.invokeNative
->ActivityThread.main(),这是通用的APK启动流程。
3)ContentProvider的加载/发布过程
ContentProvider不能单独发布,总是被打包到某个Android应用(apk)里。APK被安装之后,实例化之后每个Android应用都有一个Application实例,每个Activity或Service有一个ApplicationContext实例。
Android应用程序的入口函数是ActivityThread.main(), 该函数不仅创建了ActivityThread实例以及消息循环机构,而且创建了ApplicationThread实例,通过此实例向Activity Manager Service(AMS)提供IApplicationThread接口,AMS正是通过该接口调度和管理Activity。
ActivityThread通过attachApplication()把自己的ApplicationThread实例告知AMS。
AMS根据thread信息更新进程记录(ProcessRecord)并调用thread的bindApplication()进行初始化工作并创建ApplicationContext和Application实例,然后安装package里声明的所有contentProvider。 主要过程如下:
AMS维护了很多信息,其中比较重要的有:
mProcessNames: 包名(processName)和进程信息(ProcessRecord)映射表
mProvidersByName: Provider发布名和Provider信息(ContentProviderRecord)映射表
mProvidersByClass: Provider类名和Provider信息(ContentProviderRecord)映射表
conProviders:属于ProcessRecord信息,特定Process正在使用的ContentProvider及其个数映射表
pubProviders:属于ProcessRecord信息,特定Process已经Published的Provider类名和Provider信息
(ContentProviderRecord)映射表
ActivityThread维护了3个与ContentProvider相关的Map:
mProviderMap: 记录本应用已使用的Provider信息:<Provider发布名, ProviderRecord>
mProviderRefCountMap: 记录本应用已使用的Provider引用计数信息:<IBinder, ProviderRefCount>
mLocalProviders: 记录本地加载的Provider信息:<IBinder, ProviderRecord>
4)ContentProvider通知机制
注意:这个通知机制需要ContentProvider的实现者在实现insert/delete/query/update接口时调用ContentResolver的notifyChange(), 否则没法实现数据变化的通知。
相关文章推荐
- thinkphp里面执行原生的sql语句
- Thinkphp 控制器
- ThinkPHP 框架执行流程分析
- php中print_r 和var_dump 打印变量的区别。
- Laravel 5 中的配置
- php
- server2008服务器IIS7 +PHP5.3出现500错误的排错方法
- [分享]面向中大型应用的PHPWeb开发框架Ice
- php将json格式的数据直接存入mysql数据库
- wampserver 多个PHP版本配置后,无法启动
- PHP页面上输出空白隐形字符65279解决办法
- 理解php-cli环境
- PHPMailer发送邮件出现Permission denied的解决办法
- 理解php中的yield
- curl php
- 那些最好的轮子 - PHP篇
- Windows2003下php5.4安装配置教程(IIS)
- php判断检测一个数组里有没有重复的值
- 【php】利用php的构造函数与析构函数编写Mysql数据库查询类 (转)
- php -> =>的问题