前言
- 作为
Android的四大组件之一,ContentProvider可以说是无处不在了。 - 但是对于我而言,开发过程中看似
ContentProvider用得很娴熟,却一直没能形成一个完整的体系。 - 也许大家也有着和我类似的烦恼,于是我特地花了几天的时间,总结了我所知道的知识点,以及面试中可能遇到的问题。将本文分享给大家,希望能帮助大家重新梳理下我们的这个老朋友
ContentProvider。
最后,希望大家阅读愉快!
方便大家学习,我在 GitHub 上建立个 仓库
- 仓库内容与博客同步更新。由于我在
稀土掘金简书CSDN博客园等站点,都有新内容发布。所以大家可以直接关注该仓库,以免错过精彩内容! - 仓库地址: 超级干货!精心归纳 Android 、JVM 、算法等,各位帅气的老铁支持一下!给个 Star !
1.1 Android 为什么要设计 ContentProvider 这个组件?
- 很多做
Android开发的人都不怎么使用它,觉得直接读取数据库会更简单方便。 - 那么
Android搞一个内容提供者在数据和应用之间,只是为了装高大上,故弄玄虚?我认为其设计用意在于:
- 封装。对数据进行封装,提供统一的接口,使用者完全不必关心这些数据是在
DB,XML、Preferences或者网络请求来的。当项目需求要改变数据来源时,使用我们的地方完全不需要修改。 - 提供一种跨进程数据共享的方式。
- 应用程序间的数据共享还有另外的一个重要话题,就是数据更新通知机制了。因为数据是在多个应用程序中共享的,当其中一个应用程序改变了这些共享数据的时候,它有责任通知其它应用程序,让它们知道共享数据被修改了,这样它们就可以作相应的处理。
1.2 如何访问自定义 ContentProvider
ContentResolver接口的notifyChange函数来通知那些注册了监控特定 URI的ContentObserver 对象,使得它们可以相应地执行一些处理。- ContentObserver 可以通过 registerContentObserver 进行注册。
- 通过
ContentProvider的Uri访问开放的数据。
ContenResolver对象通过Context提供的方法getContenResolver()来获得。ContenResolver提供了以下方法来操作:insertdeleteupdatequery这些方法分别会调用ContenProvider中与之对应的方法并得到返回的结果。
1.3 通过 ContentResolver 获取 ContentProvider 内容的基本步骤
- 得到
ContentResolver类对象:ContentResolver cr = getContentResolver ( )。 - 定义要查询的字段
String数组。 - 使用
cr.query(); 返回一个Cursor对象。 - 使用
while循环得到Cursor里面的内容。
1.4 ContentProvider 是如何实现数据共享的:
- 在
Android中如果想将自己应用的数据 ( 一般多为数据库中的数据 ) 提供给第三发应用, 那么我们只能通过ContentProvider来实现了。ContentProvider是应用程序之间共享数据的接口。 - 使用的时候首先自定义 一个类继承
ContentProvider, 然后覆写query、insert、update、delete等 方法。 - 因为其是四大组件之一因此必须在
AndroidManifest文件中进行注册。 - 把自己的数据通过
uri的形式共享出去android系统下 不同程序 数据默认是不能共享访问 需要去实现一个类去继承ContentProvider。
public class PersonContentProvider extends ContentProvider{ public boolean onCreate(){ } query(Url, String[], String, String[], String); insert(Uri,ContentValues); update(Uri,ContentValues,String[]); delete(Uri,String,String[]); }
1.5 为什么要用 ContentProvider ?它和 sql 的实现上有什么差别?
ContentProvider屏蔽了数据存储的细节 , 内部实现对用户完全透明 , 用户只需要关心操作数据的uri就可以了,ContentProvider可以实现不同app之间 共享。Sql也有增删改查的方法, 但是sql只能查询本应用下的数据库。- 而
ContentProvider还可以去增删改查本地文件.xml文件的读取等。
1.6 Uri 介绍
- 为系统的每一个资源给其一个名字,比方说通话记录。
- 每一个
ContentProvider都拥有一个公共的URI,这个URI用于表示这个ContentProvider所提供的数据。 Android所提供的ContentProvider都存放在android.provider包中。
- 将其分为
A,B,C,D4个部分: A:标准前缀,用来说明一个Content Provider控制这些数据,无法改变的;"content://";B:URI的标识,用于唯一标识这个ContentProvider,外部调用者可以根据这个标识来找到它。它定义了是哪个ContentProvider提供这些数据。对于第三方应用程序,为了保证URI标识的唯一性,它必须是一个完整的、小写的类名。这个标识在元素的authorities属性中说明:一般是定义该ContentProvider的包类的名称;C:路径(path),通俗的讲就是你要操作的数据库中表的名字,或者你也可以自己定义,记得在使用的时候保持一致就可以了;"content://com.bing.provider.myprovider/tablename"。D:如果URI中包含表示需要获取的记录的ID;则就返回该id对应的数据,如果没有ID,就表示返回全部;"content://com.bing.provider.myprovider/tablename/#"#表示数据id。
1.7 如何访问 asserts 资源目录下的数据库?
- 把数据库
db复制到/data/data/packagename/databases/目录下, 然后直接就能访问了。
1.8 多个进程同时调用一个 ContentProvider 的 query 获取数据,ContentPrvoider 是如何反应的呢?
- 一个
ContentProvider可以接受来自另外一个进程的数据请求。 - 尽管
ContentResolver与ContentProvider类隐藏了实现细节,但是ContentProvider所提供的query(),insert(),delete(),update()都是在ContentProvider进程的线程池中被调用执行的,而不是进程的主线程中。 - 这个线程池是有
Binder创建和维护的,其实使用的就是每个应用进程中的Binder线程池。
1.9 Android 设计 ContentProvider 的目的是什么呢?
- 隐藏数据的实现方式,对外提供统一的数据访问接口;
- 更好的数据访问权限管理。
ContentProvider可以对开发的数据进行权限设置,不同的URI可以对应不同的权限,只有符合权限要求的组件才能访问到ContentProvider的具体操作。 ContentProvider封装了跨进程共享的逻辑,我们只需要Uri即可访问数据。由系统来管理ContentProvider的创建、生命周期及访问的线程分配,简化我们在应用间共享数据( 进程间通信 )的方式。我们只管通过ContentResolver访问ContentProvider所提示的数据接口,而不需要担心它所在进程是启动还是未启动。
1.10 运行在主线程的 ContentProvider 为什么不会影响主线程的UI操作?
ContentProvider的onCreate()是运行在UI线程的,而query(),insert(),delete(),update()是运行在线程池中的工作线程的- 所以调用这向个方法并不会阻塞
ContentProvider所在进程的主线程,但可能会阻塞调用者所在的进程的UI线程! - 所以,调用
ContentProvider的操作仍然要放在子线程中去做。 - 虽然直接的
CRUD的操作是在工作线程的,但系统会让你的调用线程等待这个异步的操作完成,你才可以继续线程之前的工作。
1.11 外提供数据共享,那么如何限制对方的使用呢?
android:exported属性非常重要。这个属性用于指示该服务是否能够被其他应用程序组件调用或跟它交互。- 如果设置为
true,则能够被调用或交互,否则不能。 - 设置为
false时,只有同一个应用程序的组件或带有相同用户ID的应用程序才能启动或绑定该服务。 - 对于需要开放的组件应设置合理的权限,如果只需要对同一个签名的其它应用开放
ContentProvider,则可以设置signature级别的权限。 - 大家可以参考一下系统自带应用的代码,自定义了
signature级别的permission:
<permission android:name="com.android.gallery3d.filtershow.permission.READ" android:protectionLevel="signature" /> <permission android:name="com.android.gallery3d.filtershow.permission.WRITE" android:protectionLevel="signature" /> <provider android:name="com.android.gallery3d.filtershow.provider.SharedImageProvider" android:authorities="com.android.gallery3d.filtershow.provider.SharedImageProvider" android:grantUriPermissions="true" android:readPermission="com.android.gallery3d.filtershow.permission.READ" android:writePermission="com.android.gallery3d.filtershow.permission.WRITE" />
1.11.1 如果我们只需要开放部份的 URI 给其他的应用访问呢?
- 可以参考
Provider的URI权限设置,只允许访问部份URI,可以参考原生ContactsProvider2的相关代码( 注意path-permission这个选项 ):
<provider android:name="ContactsProvider2" android:authorities="contacts;com.android.contacts" android:label="@string/provider_label" android:multiprocess="false" android:exported="true" android:grantUriPermissions="true" android:readPermission="android.permission.READ_CONTACTS" android:writePermission="android.permission.WRITE_CONTACTS"> <path-permission android:pathPrefix="/search_suggest_query" android:readPermission="android.permission.GLOBAL_SEARCH" /> <path-permission android:pathPrefix="/search_suggest_shortcut" android:readPermission="android.permission.GLOBAL_SEARCH" /> <path-permission android:pathPattern="/contacts/.*/photo" android:readPermission="android.permission.GLOBAL_SEARCH" /> <grant-uri-permission android:pathPattern=".*" /> </provider>
1.12 ContentProvider 接口方法运行在哪个线程中呢?
ContentProvider可以在AndroidManifest.xml中配置一个叫做android:multiprocess的属性,默认值是 false ,表示 ContentProvider 是单例的- 无论哪个客户端应用的访问都将是同一个
ContentProvider对象,如果设为true,系统会为每一个访问该ContentProvider的进程创建一个实例。
1.12.1 这点还是比较好理解的,那如果我要问每个 ContentProvider 的操作是在哪个线程中运行的呢?( 其实我们关心的是 UI 线程和工作线程 )
- 比如我们在UI线程调用getContentResolver().query查询数据,而当数据量很大时(或者需要进行较长时间的计算)会不会阻塞UI线程呢?
- 要分两种情况回答这个问题:
ContentProvider和调用者在同一个进程,ContentProvider的方法(query/insert/update/delete等 )和调用者在同一线程中;ContentProvider和调用者在不同的进程,ContentProvider的方法会运行在它自身所在进程的一个 Binder 线程中。
但是,注意这两种方式在ContentProvider的方法没有执行完成前都会blocked调用者。所以你应该知道这个上面这个问题的答案了吧。- 也可以看看
CursorLoader这个类的源码,看Google自己是怎么使用getContentResolver().query的。
1.13 ContentProvider 是如何在不同应用程序之间传输数据的?
- 一个应用进程有
16个Binder线程去和远程服务进行交互,而每个线程可占用的缓存空间是128KB这样,超过会报异常。 ContentResolver虽然是通过Binder进程间通信机制打通了应用程序之间共享数据的通道,但ContentProvider组件在不同应用程序之间传输数据是基于匿名共享内存机制来实现的。- 有兴趣的可以查看一下老罗的文章Android系统匿名共享内存Ashmem(Anonymous Shared Memory)简要介绍和学习计划。
总结
- 在这篇文章中,我对我所知道的
BroadcastReceiver知识总进行了详细的总结,希望大家通过本次阅读都能有所收获。 重点:学Android有一段时间了,我打算好好的梳理一下所学知识,到现在为止,我才总结完Activity、Service、BroadcastRecevier等,有关 事件分发、滑动冲突、新能优化等重要模块,我后面也将详尽的总结,欢迎大家关注 _yuanhao 的 博客园 ,方便及时接收更新- 如果有可以补充的知识点,欢迎大家在评论区指出。