赞
踩
ContentProvider是一种数据共享型组件,主要用于向其他组件乃至其他应用之间共享数据,并且提供数据的增删改查功能。无法被用户所感知。
ContentProvider的底层是用Binder实现的,是系统为我们封装的,使得我们无须关心底层细节即可轻松实现IPC。当跨进程访问ContentProvider的时候,CRUD运行在Binder线程池中,不是线程安全的,需要做好线程同步。而如果在同一个进程访问ContentProvider,根据Binder的原理,同进程的Binder调用就是直接的对象调用,这个时候CRUD运行在调用者的线程中。另外,ContentProvider的内部存储不一定是sqlite,它可以是任意数据(文件、Sp、xml等)。
(1)进程间进行数据交互&共享,即跨进程通信,示意图如下:
(2)ContentProvider的底层原理 = Android中的Binder机制
参考链接:本人另一篇博客:Android系统分析之进程间消息通信机制
参考链接:图文详解 Android Binder跨进程通信的原理
(1)作用
唯一标识ContentProvider & 其中的数据,也就是:外界进程通过URI找到对应的ContentProvider & 其中的数据,再进行数据操作。URI分为:系统预置 & 自定义。
(2)详细分析
Uri uri = Uri.parse("content://com.seniorlibs.binder.BookProvider/user/1")
// 自定义URI名为 `com.seniorlibs.binder.BookProvider`的`ContentProvider` 中表名为`user` 中的 `id`为1的数据
<provider
android:name=".provider.BookProvider"
android:authorities="${applicationId}.BookProvider"
android:exported="false"
android:grantUriPermissions="true">
<meta-data
android:name="android.support.FILE_PROVIDER_PATHS"
android:resource="@xml/file_paths" />
</provider>
(3)特别注意:URI模式存在匹配通配符* & #
// *:匹配任意长度的任何有效字符的字符串
// 以下的URI 表示 匹配provider的任何内容
content://com.example.app.provider/*
// #:匹配任意长度的数字字符的字符串
// 以下的URI 表示 匹配provider中的table表的所有行
content://com.example.app.provider/table/#
(1)作用
指定某个扩展名的文件用某种应用程序来打开,如指定.html文件采用text应用程序打开、指定.pdf文件采用flash应用程序打开。
(2)详细分析
ContentProvider根据URI返回MIME类型
@Override
public String getType(Uri uri) {
return null;
}
每种MIME类型由2部分组成 = 类型 + 子类型
text / html
// 类型 = text、子类型 = html
text/css
text/xml
application/pdf
ContentProvider是内容提供者, 主要作用是对外共享数据,通过内容提供者把应用中的数据共享给其他应用访问,其他应用可以通过内容提供者对本应用中的数据进行添删改查。
ContentProvider主要以“表格的形式”组织数据,同时也支持文件数据;每个表格中包含多张表,每张表包含行 & 列,分别对应记录 & 字段。
进程间共享数据的本质是:添加、删除、获取 & 更新数据。Android为常见的数据(如通讯录、日程表等)提供了内置了默认的ContentProvider,但也可根据需求自定义ContentProvider,但以下6个方法必须重写。
<-- 4个核心方法:注意CRUD运行在Binder线程池中,不是线程安全的,需要做好线程同步 --> // 外部进程向 ContentProvider 中添加数据 @Override public Uri insert(Uri uri, ContentValues values) { } // 外部进程删除 ContentProvider 中的数据 public int delete(Uri uri, String selection, String[] selectionArgs) // 外部进程更新 ContentProvider 中的数据 public int update(Uri uri, ContentValues values, String selection, String[] selectionArgs) // 外部进程获取 ContentProvider 中的数据 public Cursor query(Uri uri, String[] projection, String selection, String[] selectionArgs, String sortOrder) <-- 2个其他方法 --> // ContentProvider创建后或打开系统后,其它进程第一次访问该ContentProvider时,由系统进行调用 // 注:运行在ContentProvider进程的主线程,故不能做耗时操作 public boolean onCreate() // 得到数据类型,即返回当前 Url 所代表数据的MIME类型 public String getType(Uri uri)
ContentProvider类并不会直接与外部进程交互,而是通过ContentResolver类
ContentResolver是内容解析者, 主要作用是让外部进程通过URI统一管理操作不同的ContentProvider的操作,(其实就是调用内容提供者的接口来操作它的数据)。
(1)一般来说,一款应用要使用多个ContentProvider,若需要知道每个ContentProvider的不同实现从而再完成数据交互,操作成本高 & 难度大;
(2)所以在ContentProvider类上加多了一个ContentResolver类对所有的ContentProvider进行统一管理。
(1)ContentResolver类提供了与ContentProvider类相同名字 & 作用的4个方法
// 外部进程向 ContentProvider 中添加数据
public Uri insert(Uri uri, ContentValues values)
// 外部进程删除 ContentProvider 中的数据
public int delete(Uri uri, String selection, String[] selectionArgs)
// 外部进程更新 ContentProvider 中的数据
public int update(Uri uri, ContentValues values, String selection, String[] selectionArgs)
// 外部应用获取 ContentProvider 中的数据
public Cursor query(Uri uri, String[] projection, String selection, String[] selectionArgs, String sortOrder)
(2)实例说明
// 使用ContentResolver前,需要先获取ContentResolver
ContentResolver resolver = getContentResolver();
// 设置ContentProvider的URI
Uri uri = Uri.parse("content://com.seniorlibs.binder.BookProvider/user");
// 根据URI操作ContentProvider中的数据,此处是获取ContentProvider中user表的所有记录
Cursor cursor = resolver.query(uri, null, null, null, "userid desc");
ContentObserver是内容观察者,目的是观察Uri引起内容提供者中的数据变化,继而做一些相应的处理。当内容提供者中的数据发生变化(增、删 & 改)时,就会触发该ContentObserver类。
// 步骤1:通过ContentResolver类注册内容观察者ContentObserver,并指定需要观察的URI getContentResolver().registerContentObserver(uri, false, new SensorsActivityStateObserver(mAppEndHandler)); private class SensorsActivityStateObserver extends ContentObserver { SensorsActivityStateObserver(Handler mAppEndHandler) { super(mAppEndHandler); } @Override public void onChange(boolean selfChange, Uri uri) { super.onChange(selfChange, uri); // 获取变化的uri和数据 } } // 步骤2:当该URI的ContentProvider数据发生变化时,通知外界(即访问该ContentProvider数据的访问者) public class BookProvider extends ContentProvider { public Uri insert(Uri uri, ContentValues values) { db.insert("user", "userid", values); // 通知访问者 getContext().getContentResolver().notifyChange(uri, null); } } // 步骤3:通过ContentResolver类解除观察者 getContentResolver().unregisterContentObserver(uri);
在ContentProvider中注册URI,根据URI匹配ContentProvider中对应的数据
// 步骤1:初始化UriMatcher对象,常量UriMatcher.NO_MATCH = 不匹配任何路径的返回码 private static final UriMatcher sUriMatcher = new UriMatcher(UriMatcher.NO_MATCH); // 步骤2:在ContentProvider 中注册URI(addURI()) public static final int BOOK_URI_CODE = 0; public static final int USER_URI_CODE = 1; // 若URI资源路径 = content:/com.seniorlibs.binder.BookProvider/user ,则返回注册码USER_URI_CODE static { sUriMatcher.addURI(“com.seniorlibs.binder.BookProvider”, "book", BOOK_URI_CODE); sUriMatcher.addURI(“com.seniorlibs.binder.BookProvider”, "user", USER_URI_CODE); } // 步骤3:根据URI匹配URI_CODE,从而匹配ContentProvider中相应的资源(match()) private String getTableName(Uri uri) { String tableName = ""; switch (sUriMatcher.match(uri)) { // 根据URI匹配的返回码是BOOK_URI_CODE,即matcher.match(uri) == BOOK_URI_CODE case BOOK_URI_CODE: // 根据URI匹配的返回码是OOK_URI_CODE,则返回ContentProvider中的名为"book"的表 tableName = "book"; break; case USER_URI_CODE: tableName = "user"; break; default: break; } return tableName; }
(1)创建数据库类;
(2)自定义ContentProvider类;
(3)注册创建的ContentProvider类;
(4)在进程内通过ContentResolver访问ContentProvider的数据;
进程A
(1)创建数据库类;
(2)自定义ContentProvider类;
(3)注册创建的ContentProvider类;
进程B
(1)在进程内通过ContentResolver访问ContentProvider的数据;
(1)主要看ActivityThread类-handleBindApplication(AppBindData data)
if (!data.restrictedBackupMode) { if (!ArrayUtils.isEmpty(data.providers)) { installContentProviders(app, data.providers); // 继续跟踪这个做了哪些事情 // For process that contains content providers, we want to // ensure that the JIT is enabled "at some point". mH.sendEmptyMessageDelayed(H.ENABLE_JIT, 10*1000); } } // Do this after providers, since instrumentation tests generally start their // test thread at this point, and we don't want that racing. try { mInstrumentation.onCreate(data.instrumentationArgs); } catch (Exception e) { throw new RuntimeException( "Exception thrown in onCreate() of " + data.instrumentationName + ": " + e.toString(), e); } try { mInstrumentation.callApplicationOnCreate(app); // 执行Application.onCreate() }
(2)跟踪 installContentProviders(app, providers)
private void installContentProviders( Context context, List<ProviderInfo> providers) { final ArrayList<ContentProviderHolder> results = new ArrayList<>(); for (ProviderInfo cpi : providers) { if (DEBUG_PROVIDER) { StringBuilder buf = new StringBuilder(128); buf.append("Pub "); buf.append(cpi.authority); buf.append(": "); buf.append(cpi.name); Log.i(TAG, buf.toString()); } ContentProviderHolder cph = installProvider(context, null, cpi, false /*noisy*/, true /*noReleaseNeeded*/, true /*stable*/); // 继续跟踪这里 if (cph != null) { cph.noReleaseNeeded = true; results.add(cph); } } try { ActivityManager.getService().publishContentProviders( getApplicationThread(), results); } catch (RemoteException ex) { throw ex.rethrowFromSystemServer(); } }
(3)跟踪 installProvider(context, null, cpi…);
private ContentProviderHolder installProvider(Context context, ContentProviderHolder holder, ProviderInfo info, boolean noisy, boolean noReleaseNeeded, boolean stable) { try { if (DEBUG_PROVIDER) Slog.v( TAG, "Instantiating local provider " + info.name); // XXX Need to create the correct context for this provider. localProvider.attachInfo(c, info); // 继续跟踪这里 } catch (java.lang.Exception e) { if (!mInstrumentation.onException(null, e)) { throw new RuntimeException( "Unable to get provider " + info.name + ": " + e.toString(), e); } return null; } }
(4)跟踪localProvider.attachInfo(c, info)
private void attachInfo(Context context, ProviderInfo info, boolean testing) { mNoPerms = testing; if (mContext == null) { mContext = context; if (context != null) { mTransport.mAppOpsManager = (AppOpsManager) context.getSystemService( Context.APP_OPS_SERVICE); } mMyUid = Process.myUid(); if (info != null) { setReadPermission(info.readPermission); setWritePermission(info.writePermission); setPathPermissions(info.pathPermissions); mExported = info.exported; mSingleUser = (info.flags & ProviderInfo.FLAG_SINGLE_USER) != 0; setAuthorities(info.authority); } ContentProvider.this.onCreate(); // 调用ContentProvider onCreate() } }
(5)结论:通过查看源码的方式验证ContentProvider的onCreate()比Application的onCreate()优先执行,以及:
Application -> attachBaseContext ==>ContentProvider->onCreate ==>Application->onCreate ==>Activity->onCreate
(6)参考链接:Android ContentProvider onCreate()在Application onCreate()之前执行
由以上6.1的源码分析可知,onCreate代表ContentProvider的创建,由系统回调并运行在主线程中;其他五个方法均由外界回调并运行在Binder线程池中,不是线程安全的,需要做好线程同步。
参考链接:ContentProvider总结
(1)ContentProvider是内容提供者, 主要作用是对外共享数据,通过内容提供者把应用中的数据共享给其他应用访问,其他应用可以通过内容提供者对本应用中的数据进行添删改查;
(2)ContentResolver是内容解析者, 主要作用是让外部进程通过URI统一管理操作不同的ContentProvider的操作,(其实就是调用内容提供者的接口来操作它的数据);
(3)ContentObserver是内容观察者,目的是观察Uri引起内容提供者中的数据变化,继而做一些相应的处理。当内容提供者中的数据发生变化(增、删 & 改)时,就会触发该ContentObserver类。
(1)Android提供了ContentProvider,应用A可以通过实现一个ContentProvider的抽象接口以类似数据库中表的方式将自己的数据完全暴露出去,也就是说ContentProvider就像一个“数据库”。
(2)不管应用A是否启动,应用B通过ContentResolver根据Uri去访问并操作ContentProvider暴露的数据。
ContentProvider具备以下2大特性:
(1)安全
ContentProvider为应用间的数据交互提供了一个安全的环境:允许把自己的应用数据根据需求开放给其他应用进行 增、删、改、查,而不用担心因为直接开放数据库权限而带来的安全问题;
(2)访问简单 & 高效:
采用文件方式对外共享数据,需要进行文件操作读写数据;采用Sharedpreferences共享数据,需要使用sharedpreferences API读写数据。这使得访问数据变得复杂 & 难度大。而采用ContentProvider方式,其解耦了底层数据的存储方式,使得无论底层数据存储采用何种方式,外界对数据的访问方式都是统一的,这使得访问简单 & 高效。
Android开发-API指南-grant-uri-permission
ContentProvider在AndroidManifest.xml中注册以及权限设置
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。