前言
- 作为
Android
的四大组件之一,ContentProvider
可以说是无处不在了。 - 但是对于我而言,开发过程中看似
ContentProvider
用得很娴熟,却一直没能形成一个完整的体系。 - 也许大家也有着和我类似的烦恼,于是我特地花了几天的时间,总结了我所知道的知识点,以及面试中可能遇到的问题。将本文分享给大家,希望能帮助大家重新梳理下我们的这个老朋友
ContentProvider
。
最后,希望大家阅读愉快!
文章目录
ContentProvider
应用程序间非常通用的共享数据的一种方式,也是Android
官方推荐的方式。Android
中许多系统应用都使用该方式实现数据共享,比如通讯录、短信等。
方便大家学习,我在 GitHub 上建立个 仓库
-
仓库内容与博客同步更新。由于我在
稀土掘金
简书
CSDN
博客园
等站点,都有新内容发布。所以大家可以直接关注该仓库,以免错过精彩内容!
1.1 Android 为什么要设计 ContentProvider 这个组件?
- 很多做
Android
开发的人都不怎么使用它,觉得直接读取数据库会更简单方便。 - 那么
Android
搞一个内容提供者在数据和应用之间,只是为了装高大上,故弄玄虚?其设计用意在于:
- 封装。对数据进行封装,提供统一的接口,使用者完全不必关心这些数据是在
DB
,XML
、Preferences
或者网络请求来的。当项目需求要改变数据来源时,使用我们的地方完全不需要修改。 - 提供一种跨进程数据共享的方式。
- 应用程序间的数据共享还有另外的一个重要话题,就是数据更新通知机制了。因为数据是在多个应用程序中共享的,当其中一个应用程序改变了这些共享数据的时候,它有责任通知其它应用程序,让它们知道共享数据被修改了,这样它们就可以作相应的处理。
1.2 如何访问自定义 ContentProvider
ContentResolver
接口的notifyChange
函数来通知那些注册了监控特定 URI的ContentObserver 对象,使得它们可以相应地执行一些处理。- ContentObserver 可以通过 registerContentObserver 进行注册。
- 通过
ContentProvider
的Uri
访问开放的数据。
ContenResolver
对象通过Context
提供的方法getContenResolver()
来获得。ContenResolver
提供了以下方法来操作:insert
delete
update
query
这些方法分别会调用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,D
4个部分: 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
组件在不同应用程序之间传输数据是基于匿名共享内存机制来实现的。
总结
- 在这篇文章中,我对我所知道的
ContentProvider
知识总进行了详细的总结,希望大家通过本次阅读都能有所收获。 重点
:学Android
有一段时间了,我打算好好的梳理一下所学知识,到现在为止,我才总结完Activity
、Service
、BroadcastRecevier
等,有关 事件分发、滑动冲突、新能优化等重要模块,我后面也将详尽的总结,欢迎大家关注 _yuanhao 的 博客园 ,方便及时接收更新- 如果有可以补充的知识点,欢迎大家在评论区指出。
码字不易,你的点赞是我总结的最大动力!
-
由于我在「稀土掘金」「简书」「
CSDN
」「博客园」等站点,都有新内容发布。所以大家可以直接关注我的GitHub
仓库,以免错过精彩内容! -
一万多字长文,加上精美思维导图,记得点赞哦,欢迎关注 _yuanhao 的 博客园 ,我们下篇文章见!