Android ContentProvider数据共享全解析

     前两天处理了那个beam分享的问题单之后，回头来想想，蓝牙进程为什么能读取到文件并分享给另一个手机呢？Android手机本身是LInux系统，每个文件都有相应的读、写、执行权限的，如果权限不符合是无法访问该文件的，而在那个问题单的处理过程当中，我们可以看到，就是使用了Uri标识文件，然后给蓝牙进程赋予读权限，最终蓝牙进程肯定就是通过ContentProvider来实现文件的读取并共享的。问题单虽然处理完了，但是对于ContentProvider还是只了解面貌，底层到底是如何实现的，我们还是不清楚，也就是考虑到这个，所以本节课我们来深究一下ContentProvider的实现原理。

     之前也读过老罗关于ContentProvider的研究的博客了，写的非常好，非常细致，大家也可以学习一下，但是还是要说明一下，只是读别人的博客，自己不研究，不跟踪代码，那么学习还是非常肤浅的，基本上就非常模糊。好了，我们这节课呢实现很简单，就是通过访问图库中的图片，来学习一下ContentProvider的实现原理。客户端很简单，就一个方法，其他的调用界面我就不写了，大家可以自己写一下：

public static void queryAllImages(Context context) {
ArrayList names = new ArrayList();
ArrayList descs = new ArrayList();
ArrayList datas = new ArrayList();
Uri uri = Media.EXTERNAL_CONTENT_URI;
Cursor cursor = context.getContentResolver().query(uri, null, null, null, null);
Log.i(TAG, "query images, " + uri + ", " + uri.toString());
while (cursor.moveToNext()) {
String name = cursor.getString(cursor.getColumnIndex(Media.DISPLAY_NAME));
String desc = cursor.getString(cursor.getColumnIndex(Media.DESCRIPTION));
byte[] data = cursor.getBlob(cursor.getColumnIndex(Media.DATA));
names.add(name);
descs.add(desc);
datas.add(Arrays.toString(data));
mDatas.add(data);
}
Log.i(TAG, "names = " + names);
Log.i(TAG, "datas = " + datas);
}

     我在这个方法和系统层framework当中都加了一些日志打印，从输出的日志当中，我们可以看到最后获取回来的blob数据是一个byte[]数组，存储的全部是十进制的整数，这些数组中的内容代码什么呢？



     
     我们可以把这些十进制的数据先转换为十六进制，然后再将十六进制的数据转换成字符串，就可以看到它到底是什么内容了。





     从转换成的字符串结果当中，很清楚的可以看到，它正是我们当前取回来的图片文件在手机上的存储路径。 

     这个方法当中的目的也非常明确，就是通过Resolver来查询图库中Media.EXTERNAL_CONTENT_URI匹配的所有的图片，然后在返回的结果中把数据读出来，看一下返回来的数据是什么，这样就完成了。那么根据这样的目的，我们也就把这节课分为三个步骤来讲：1、context.getContentResolver().query(uri, null, null, null, null)调用完成，返回一个Cursor对象；2、cursor.moveToNext()到底干了什么？；3、cursor.getBlob(cursor.getColumnIndex(Media.DATA))是如何把数据取回来的。后面两个步骤大家可能有疑问，这两步也要单独拿出来分析？先不着急，大家细心看完就知道了，其实这两步是非常重要的，数据的获取就是通过这两步来完成的。
     1、context.getContentResolver().query(uri, null, null, null, null)返回Cursor对象

     context.getContentResolver()是由ContextImpl实现的，它返回的就是成员变量mContentResolver，而mContentResolver是一个ApplicationContentResolver对象，是在ContextImpl定义的一个内部类，而query方法是由父类ContentResolver来实现的，注意query方法的修饰符为final，即此方法不允许子类自己实现，那么我们就来看一下query方法的实现：

public final @Nullable Cursor query(@RequiresPermission.Read @NonNull Uri uri,
@Nullable String[] projection, @Nullable String selection,
@Nullable String[] selectionArgs, @Nullable String sortOrder) {
return query(uri, projection, selection, selectionArgs, sortOrder, null);
}

/**
* Query the given URI, returning a {@link Cursor} over the result set
* with optional support for cancellation.
*

* For best performance, the caller should follow these guidelines:
*

*
Provide an explicit projection, to prevent
* reading data from storage that aren't going to be used.
*
Use question mark parameter markers such as 'phone=?' instead of
* explicit values in the {@code selection} parameter, so that queries
* that differ only by those values will be recognized as the same
* for caching purposes.
*

*
*
* @param uri The URI, using the content:// scheme, for the content to
* retrieve.
* @param projection A list of which columns to return. Passing null will
* return all columns, which is inefficient.
* @param selection A filter declaring which rows to return, formatted as an
* SQL WHERE clause (excluding the WHERE itself). Passing null will
* return all rows for the given URI.
* @param selectionArgs You may include ?s in selection, which will be
* replaced by the values from selectionArgs, in the order that they
* appear in the selection. The values will be bound as Strings.
* @param sortOrder How to order the rows, formatted as an SQL ORDER BY
* clause (excluding the ORDER BY itself). Passing null will use the
* default sort order, which may be unordered.
* @param cancellationSignal A signal to cancel the operation in progress, or null if none.
* If the operation is canceled, then {@link OperationCanceledException} will be thrown
* when the query is executed.
* @return A Cursor object, which is positioned before the first entry, or null
* @see Cursor
*/
public final @Nullable Cursor query(final @RequiresPermission.Read @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);
if (unstableProvider == null) {
return null;
}
IContentProvider stableProvider = null;
Cursor qCursor = null;
try {
long startTime = SystemClock.uptimeMillis();

ICancellationSignal remoteCancellationSignal = null;
if (cancellationSignal != null) {
cancellationSignal.throwIfCanceled();
remoteCancellationSignal = unstableProvider.createCancellationSignal();
cancellationSignal.setRemote(remoteCancellationSignal);
}
try {
qCursor = unstableProvider.query(mPackageName, uri, projection,
selection, selectionArgs, sortOrder, remoteCancellationSignal);
} catch (DeadObjectException e) {
// The remote process has died... but we only hold an unstable
// reference though, so we might recover!!! Let's try!!!!
// This is exciting!!1!!1!!!!1
unstableProviderDied(unstableProvider);
stableProvider = acquireProvider(uri);
if (stableProvider == null) {
return null;
}
qCursor = stableProvider.query(mPackageName, uri, projection,
selection, selectionArgs, sortOrder, remoteCancellationSignal);
}
if (qCursor == null) {
return null;
}

// Force query execution. Might fail and throw a runtime exception here.
qCursor.getCount();
long durationMillis = SystemClock.uptimeMillis() - startTime;
maybeLogQueryToEventLog(durationMillis, uri, projection, selection, sortOrder);

// Wrap the cursor object into CursorWrapperInner object.
final IContentProvider provider = (stableProvider != null) ? stableProvider
: acquireProvider(uri);
final CursorWrapperInner wrapper = new CursorWrapperInner(qCursor, provider);
stableProvider = null;
qCursor = null;
return wrapper;
} catch (RemoteException e) {
// Arbitrary and not worth documenting, as Activity
// Manager will kill this process shortly anyway.
return null;
} finally {
if (qCursor != null) {
qCursor.close();
}
if (cancellationSignal != null) {
cancellationSignal.setRemote(null);
}
if (unstableProvider != null) {
releaseUnstableProvider(unstableProvider);
}
if (stableProvider != null) {
releaseProvider(stableProvider);
}
}
}
     1.1、acquireUnstableProvider(uri)获取一个IContentProvider对象

     调用acquireUnstableProvider(uri)来获取一个Provider实例，获取的时候会先检查uri.getScheme()，如果Scheme字段不是content，则直接返回空了，Scheme字段正确后，然后获取uri.getAuthority()，这也就是我们自己实现一个ContentProvider时定义的Authority了，注意，这个字段必须是唯一的，是在一个手机上唯一的，如果有定义了两个Authority相同的ContentProvider，那么，后面那个apk是无法安装到手机上的，大家可以试一下。acquireUnstableProvider方法最终也是根据Authority字段来查询我们的目标Provider的。这个过程我们就不展开了，大体的步骤就是先在ActivityThread当中调用acquireExistingProvider去缓存当中查，查到了就直接返回；如果缓存中没有查到，那么就继续去AMS当中查，AMS当中也是先在缓存中查，缓存有，则直接返回给当前调用进程；如果缓存也没有，那就说明提供目标ContentProvider的进程还未启动，那么就先启动目标进程，启动完成后，将目标进程提供的该ContentProvider缓存起来，同时返回给当前调用进程。这个过程，大家可以参考老罗的博客：

     Android应用程序组件Content Provider的启动过程源代码分析

     我们这里呢，从第一张图的日志输出看到，对应Media.EXTERNAL_CONTENT_URI的ContentProvider是com.android.providers.media/.MediaProvider对象，而在调用方拿到的只是一个代理对象，对应的服务端实际上就是定义在ContentProvider的内部类Transport了。

     1.2、unstableProvider.query执行查询
     unstableProvider是一个IContentProvider对象，它的query方法是由ContentProviderProxy来实现的，我们来看一下它的实现：

public Cursor query(String callingPkg, Uri url, String[] projection, String selection,
String[] selectionArgs, String sortOrder, ICancellationSignal cancellationSignal)
throws RemoteException {
BulkCursorToCursorAdaptor adaptor = new BulkCursorToCursorAdaptor();
Parcel data = Parcel.obtain();
Parcel reply = Parcel.obtain();
try {
data.writeInterfaceToken(IContentProvider.descriptor);

data.writeString(callingPkg);
url.writeToParcel(data, 0);
int length = 0;
if (projection != null) {
length = projection.length;
}
data.writeInt(length);
for (int i = 0; i < length; i++) {
data.writeString(projection[i]);
}
data.writeString(selection);
if (selectionArgs != null) {
length = selectionArgs.length;
} else {
length = 0;
}
data.writeInt(length);
for (int i = 0; i < length; i++) {
data.writeString(selectionArgs[i]);
}
data.writeString(sortOrder);
data.writeStrongBinder(adaptor.getObserver().asBinder());
data.writeStrongBinder(cancellationSignal != null ? cancellationSignal.asBinder() : null);

mRemote.transact(IContentProvider.QUERY_TRANSACTION, data, reply, 0);

DatabaseUtils.readExceptionFromParcel(reply);

if (reply.readInt() != 0) {
BulkCursorDescriptor d = BulkCursorDescriptor.CREATOR.createFromParcel(reply);
adaptor.initialize(d);
} else {
adaptor.close();
adaptor = null;
}
return adaptor;
} catch (RemoteException ex) {
adaptor.close();
throw ex;
} catch (RuntimeException ex) {
adaptor.close();
throw ex;
} finally {
data.recycle();
reply.recycle();
}
}

     这个方法当中先创建了一个BulkCursorToCursorAdaptor对象，这个adaptor也正是我们要返回给上层调用者的。binder通信在执行QUERY_TRANSACTION传信时，如果查询成功，则会调用reply.writeInt(1)写入1，如果失败则reply.writeInt(0)写入0，用这个int值来区分查询是否成功。这里我们假设查询是成功的，那么就会执行BulkCursorDescriptor d = BulkCursorDescriptor.CREATOR.createFromParcel(reply)、adaptor.initialize(d)，完成后，将adapter返回给调用层。关于这块的详细执行，大家也可以看老罗的博客：
   
Android应用程序组件Content Provider在应用程序之间共享数据的原理分析
     我们还是按照代码执行流程先来看一下mRemote.transact(IContentProvider.QUERY_TRANSACTION, data, reply, 0)的执行过程，然后再回来看一下query方法中后面的逻辑。mRemote.transact()调用之后，就通过binder进程间通信到ContentProviderNative类的onTransact方法当中了，当前的code就是QUERY_TRANSACTION，在这个分支当中，主要的事情就是：1、将调用方的参数通过binder传递过来的data中取出来，然后用这些参数调用query方法，完成后会得到一个Cursor
cursor对象；2、以这个cursor对象为参数，构造一个CursorToBulkCursorAdaptor，然后再调用BulkCursorDescriptor d = adaptor.getBulkCursorDescriptor()，将需要的数据都封装在d当中，最后通过binder把数据返回到调用方进程当中。这里需要提醒大家一下，执行到这里，已经是在ContentProvider的服务端了，相当于正在服务端查数据。我们先来看一下服务端query方法的实现，它的实现正是由我们1.1当中Transport来实现的，那我们就来看一下Transport类的query方法的实现：

@Override
public Cursor query(String callingPkg, Uri uri, String[] projection,
String selection, String[] selectionArgs, String sortOrder,
ICancellationSignal cancellationSignal) {
validateIncomingUri(uri);
Log.w(TAG, "execute query, " + callingPkg + ", " + uri);
uri = getUriWithoutUserId(uri);
if (enforceReadPermission(callingPkg, uri, null) != AppOpsManager.MODE_ALLOWED) {
// The caller has no access to the data, so return an empty cursor with
// the columns in the requested order. The caller may ask for an invalid
// column and we would not catch that but this is not a problem in practice.
// We do not call ContentProvider#query with a modified where clause since
// the implementation is not guaranteed to be backed by a SQL database, hence
// it may not handle properly the tautology where clause we would have created.
if (projection != null) {
return new MatrixCursor(projection, 0);
}

// Null projection means all columns but we have no idea which they are.
// However, the caller may be expecting to access them my index. Hence,
// we have to execute the query as if allowed to get a cursor with the
// columns. We then use the column names to return an empty cursor.
Cursor cursor = ContentProvider.this.query(uri, projection, selection,
selectionArgs, sortOrder, CancellationSignal.fromTransport(
cancellationSignal));
if (cursor == null) {
return null;
}

// Return an empty cursor for all columns.
return new MatrixCursor(cursor.getColumnNames(), 0);
}
final String original = setCallingPackage(callingPkg);
try {
return ContentProvider.this.query(
uri, projection, selection, selectionArgs, sortOrder,
CancellationSignal.fromTransport(cancellationSignal));
} finally {
setCallingPackage(original);
}
}

     在这里一般我们的调用方都是有read权限的，if (enforceReadPermission(callingPkg, uri, null) != AppOpsManager.MODE_ALLOWED)判断为false，那么就是直接调用最后的ContentProvider.this.query()，查询完成的结果就直接返回了，这里的this就是我们在1.1当中日志中看到的真正执行查询方法的MediaProvider了。那么接下来，我们就来看一下MediaProvider类的query方法是如何实现的。这个query方法非常长，我们这里只贴出关键代码，其他的就省略了：

public Cursor query(Uri uri, String[] projectionIn, String selection,
String[] selectionArgs, String sort) {

uri = safeUncanonicalize(uri);

int table = URI_MATCHER.match(uri);
List prependArgs = new ArrayList();

// MtkLog.v(TAG, "query: uri="+uri+", selection="+selection);
// handle MEDIA_SCANNER before calling getDatabaseForUri()
………………………………………………………………

String groupBy = null;
DatabaseHelper helper = getDatabaseForUri(uri);
if (helper == null) {
return null;
}
Log.i(TAG, "database name is " + helper.getDatabaseName());
helper.mNumQueries++;
SQLiteDatabase db = helper.getReadableDatabase();
if (db == null) return null;
SQLiteQueryBuilder qb = new SQLiteQueryBuilder();
String limit = uri.getQueryParameter("limit");
String filter = uri.getQueryParameter("filter");
String [] keywords = null;
if (filter != null) {
filter = Uri.decode(filter).trim();
if (!TextUtils.isEmpty(filter)) {
String [] searchWords = filter.split(" ");
keywords = new String[searchWords.length];
for (int i = 0; i < searchWords.length; i++) {
String key = MediaStore.Audio.keyFor(searchWords[i]);
key = key.replace("\\", "\\\\");
key = key.replace("%", "\\%");
key = key.replace("_", "\\_");
keywords[i] = key;
}
}
}
if (uri.getQueryParameter("distinct") != null) {
qb.setDistinct(true);
}

boolean hasThumbnailId = false;
boolean permitedAccessDrm = DrmHelper.isPermitedAccessDrm(getContext(), Binder.getCallingPid());
switch (table) {
case IMAGES_MEDIA:
qb.setTables("images");
if (uri.getQueryParameter("distinct") != null)
qb.setDistinct(true);
if (!permitedAccessDrm) {
qb.appendWhere(NO_DRM_CLAUSE);
}
// set the project map so that data dir is prepended to _data.
//qb.setProjectionMap(mImagesProjectionMap, true);
break;
…………………………………………………………
}

// MtkLog.v(TAG, "query = "+ qb.buildQuery(projectionIn, selection,
//        combine(prependArgs, selectionArgs), groupBy, null, sort, limit));
Cursor c = null;
try {
c = qb.query(db, projectionIn, selection,
combine(prependArgs, selectionArgs), groupBy, null, sort, limit);
} catch (IllegalStateException e) {
MtkLog.e(TAG, "query: IllegalStateException! uri=" + uri, e);
}
if (true) {
MtkLog.d(TAG, "query: uri = " + uri + ", projection = " + Arrays.toString(projectionIn)
+ ", selection = " + selection + ", selectionArgs = " + Arrays.toString(selectionArgs)
+ ", sort = " + sort + ", caller pid = " + Binder.getCallingPid());
}

if (c != null) {
String nonotify = uri.getQueryParameter("nonotify");
if (nonotify == null || !nonotify.equals("1")) {
c.setNotificationUri(getContext().getContentResolver(), uri);
}
}

return c;
}

     在这个方法当中，我们可以看到好多匹配，有图库、音频、版本等等各种信息，在MediaProvider类的开始，我们也可以看到，定义了两个数据库：private static final String INTERNAL_DATABASE_NAME = "internal.db"、private static final String EXTERNAL_DATABASE_NAME = "external.db"，我们的图片肯定就是保存在external.db数据库中了。不过保存的只是索引，可不是图片信息，一定要理解清楚哈。我们这里要查询的表就是images了，查询工作是调用SQLiteQueryBuilder类的query方法来完成的。SQLiteQueryBuilder类的query方法我们就不贴代码了，主要作了两件事：1、将外部传入的参数组合起来，构造好一条sql语句；2、调用SQLiteDatabase类的rawQueryWithFactory方法继续执行查询。SQLiteDatabase类的rawQueryWithFactory方法也是两件事：1、先构造一个SQLiteDirectCursorDriver对象；2、调用SQLiteDirectCursorDriver的query方法执行查询。SQLiteDirectCursorDriver类的整体代码如下：

public final class SQLiteDirectCursorDriver implements SQLiteCursorDriver {
private final SQLiteDatabase mDatabase;
private final String mEditTable;
private final String mSql;
private final CancellationSignal mCancellationSignal;
private SQLiteQuery mQuery;

public SQLiteDirectCursorDriver(SQLiteDatabase db, String sql, String editTable,
CancellationSignal cancellationSignal) {
mDatabase = db;
mEditTable = editTable;
mSql = sql;
mCancellationSignal = cancellationSignal;
}

public Cursor query(CursorFactory factory, String[] selectionArgs) {
final SQLiteQuery query = new SQLiteQuery(mDatabase, mSql, mCancellationSignal);
final Cursor cursor;
try {
query.bindAllArgsAsStrings(selectionArgs);

if (factory == null) {
cursor = new SQLiteCursor(this, mEditTable, query);
} else {
cursor = factory.newCursor(mDatabase, this, mEditTable, query);
}
} catch (RuntimeException ex) {
query.close();
throw ex;
}

mQuery = query;
return cursor;
}

public void cursorClosed() {
// Do nothing
}

public void setBindArguments(String[] bindArgs) {
mQuery.bindAllArgsAsStrings(bindArgs);
}

public void cursorDeactivated() {
// Do nothing
}

public void cursorRequeried(Cursor cursor) {
// Do nothing
}

@Override
public String toString() {
return "SQLiteDirectCursorDriver: " + mSql;
}
}

     可以看到它的构造方法中没有什么实质性的动作，只是给成员变量赋值，query方法中，构造了一个SQLiteQuery对象，然后以它为参数，构造一个SQLiteCursor，最终返回的就是这个SQLiteCursor了。注意这里的参数factory，它是SQLiteQueryBuilder类的成员变量，在整个过程中，我们没有指定factory，所以此处它为空。SQLiteCursor的构造函数中也没有什么实质性的工作，这里我们就不展开了。
     我们可以看到，系统中管理所有图片都是在MediaProvider当中，它的代码在packages/providers/MediaProvider目录下，查看manifest文件，我们就可以看到它的包名。



     有了包名，我们看一下它在手机当中的数据信息的位置，使用adb shell dumpsys package "com.android.providers.media"命令。



     这里会显示当前进程的好多信息，那么我们就是想看一下它用来存储数据的数据库到底是什么样的，我们进入它的data目录，把它的进程保存的数据全部pull出来看一下。



     这里呢，我把当前MediaProvider进程下位置data/data/com.android.providers.media目录下的所有文件夹全部pull出来了，可以看到它和我们普通进程的数据存储目录结构是相同的。



     好了，兴奋的时刻来了，我们使用SQLiteSpy来打开它的external.db数据库文件，我靠，无语了，数据库是加密的。



     从以上的代码分析，我们就可以得知，在调用Cursor cursor = context.getContentResolver().query(uri, null, null, null, null)返回的结果cursor中其实还没有任何数据，它只是准备好了一个Cursor对象，我们可以加上代码来验证一下我们猜想，比如我们先不调用cursor.moveToNext()，就直接取它当中的blob数据，能不能取出来呢？



     可以从我们的验证看到，当前只是返回的cursor对象，它的mPos才刚初始化，当前值为-1，所以我们这时候取值，就直接异常崩溃了。
     回到我们的主题，那么到这，只是在MediaProvider对象的query方法执行完了，返回到上一层Transport当中，这里也是直接返回了，那么再往回一层，回到ContentProviderNative类的onTransact方法的case QUERY_TRANSACTION分支，返回回来的cursor不为空，而且它是一个SQLiteCursor对象，在这个方法当中，就用这个cursor对象构造一个CursorToBulkCursorAdaptor对象，它当中就是给一些成员变量赋值，然后调用createAndRegisterObserverProxyLocked将我们要监听的Observer对象注册进来，这些过程我们就不深究了，其中的注册Observer会在数据变化时通知我们。创建好CursorToBulkCursorAdaptor对象之后，然后调用adaptor.getBulkCursorDescriptor()获取一个BulkCursorDescriptor对象，最后把这个对象写入的binder返回的数据当中，再写入1表示cursor创建成功，到这里Provider服务端的工作就完成了。那么再往上返回一层，就到了ContentProviderProxy类的query方法的mRemote.transact()调用，这里的(reply.readInt()
!= 0)就为true了，那么就利用reply中的数据构造一个BulkCursorDescriptor，然后调用adaptor.initialize(d)就完成了，最后把这个adapter返回给上一层。再往上一层就是ContentResolve类的query方法中的unstableProvider.query()调用了。到这里呢，大家可以看一下系统层所作的工作，整个query过程，只是根据我们传入的参数在服务端构造了一个SQLiteCursor，但是还没有进行任何实质性的查询工作，同时通过binder进程间通信的服务端返回给Provider客户端的是一个CursorToBulkCursorAdaptor对象，Provider客户端在收到binder通信的返回数据后，构造了一个BulkCursorToCursorAdaptor，这两个对象是通过BulkCursorDescriptor联系起来的，在服务端调用adaptor.getBulkCursorDescriptor()把数据准备好，然后写入到binder的返回数据reply中；客户端就直接从reply中调用BulkCursorDescriptor.CREATOR.createFromParcel(reply)把数据取回来，然后进一步封装，这些细节一定要搞清楚。

     1.3、qCursor.getCount()
     从这句代码的备注“Force query execution.  Might fail and throw a runtime exception here.”上，我们先来理解一下，也就是系统强制先执行一次查询，其实大家看一下它的实现就知道了，这里相当于只是进行一下数据检查，它的实现非常简单，就是检查mBulkCursor成员变量是否为空，在1.2步骤的最后，已经调用adaptor.initialize(d)把binder返回给我们的数据保存下来了，所以这里的mBulkCursor也就不为空了。
     1.4、以1.2的结果为参数调用new CursorWrapperInner()，最终返回给调用者
     通过了1.3的关口检查，那么最后就是把数据封装成一个CursorWrapperInner最终返回给我们客户端了，到这句执行完成后，相当于我们在应用层中调用getContentResolver().query()方法才完成，作了这么多工作，才只完成了一句代码的逻辑，大家从这里也可以看到，ContentProvider系统是多么的复杂！！好了，继续我们的流程，CursorWrapperInner的构造方法也比较简单，就是把传入的参数保存在成员变量当中，就完成了。
     2、cursor.moveToNext()到底干了什么？
     现在我们该执行第二步了，这里的cursor就是应用层拿到的cursor了，是一个CursorWrapperInner对象，moveToNext()是由它的父类CursorWrapper来实现的。它当中是直接调用mCursor.moveToNext()来处理的，这里的成员变量cursor也就是在1.4步骤时构造CursorWrapperInner传入的第一个参数了，实际就是binder通信完成，在客户端自己构造的一个BulkCursorToCursorAdaptor对象，它的moveToNext()也是调用父类AbstractCursor来实现的，这里的实现非常简单，就是调用moveToPosition(mPos
+ 1)，注意，mPos还进行任何赋值，所以此时它的值是-1，moveToPosition方法当中就作了两件事：1、计算mPos的位置，然后赋值；2、回调子类的onMove。这里的子类当然就是BulkCursorToCursorAdaptor了，我们来看一下它的onMove方法的实现：

@Override
public boolean onMove(int oldPosition, int newPosition) {
throwIfCursorIsClosed();

try {
// Make sure we have the proper window
if (mWindow == null
|| newPosition < mWindow.getStartPosition()
|| newPosition >= mWindow.getStartPosition() + mWindow.getNumRows()) {
setWindow(mBulkCursor.getWindow(newPosition));
} else if (mWantsAllOnMoveCalls) {
mBulkCursor.onMove(newPosition);
}
} catch (RemoteException ex) {
// We tried to get a window and failed
Log.e(TAG, "Unable to get window because the remote process is dead");
return false;
}

// Couldn't obtain a window, something is wrong
if (mWindow == null) {
return false;
}

return true;
}

     mWindow是从父类AbstractWindowedCursor继承下来的，它是一个重量级的对象，大家从后边的分析中就可以感觉到。在前面的query过程当中，因为还没有执行任何实质性的查询，所以此时第一次执行时，mWindow是为空的，那么就执行if分支，调用mBulkCursor.getWindow(newPosition)获取服务端的window对象，然后调用setWindow赋值给它的成员变量。mBulkCursor是从binder通信的服务端返回过来的一个CursorToBulkCursorAdaptor对象。在中间的查询过程，涉及到的各种对象太多了，大家如果没有自己分析源码，这时候肯定都已经乱了。
     在这里我们重点说一下，在Provider通信过程中，binder通信直接对应的两端的对象：客户端是BulkCursorToCursorAdaptor，服务端是CursorToBulkCursorAdaptor。
     往外退一层，应用层访问的Cursor实质是封装的一个CursorWrapperInner对象，服务端实际构造好的是一个SQLiteCursor对象。
     好了，稍微理一下，我们继续，那么就通过调用CursorToBulkCursorAdaptor对象的getWindow方法去获取一个Window，我们来看一下这个方法的实现：

@Override
public CursorWindow getWindow(int position) {
synchronized (mLock) {
throwIfCursorIsClosed();

if (!mCursor.moveToPosition(position)) {
closeFilledWindowLocked();
return null;
}

CursorWindow window = mCursor.getWindow();
if (window != null) {
closeFilledWindowLocked();
} else {
window = mFilledWindow;
if (window == null) {
mFilledWindow = new CursorWindow(mProviderName);
window = mFilledWindow;
} else if (position < window.getStartPosition()
|| position >= window.getStartPosition() + window.getNumRows()) {
window.clear();
}
mCursor.fillWindow(position, window);
}

if (window != null) {
// Acquire a reference to the window because its reference count will be
// decremented when it is returned as part of the binder call reply parcel.
window.acquireReference();
}
return window;
}
}

     这个方法当中的mCursor定义为CrossProcessCursor，是一个接口，本质就是我们上面说的服务端往外退一层的SQLiteCursor了，那么第一次调用时，获取到的window肯定是空的了，就构造一个CursorWindow对象，然后赋值给成员变量。在这个方法当中，非常重要的两步：1、调用mFilledWindow = new CursorWindow(mProviderName)构造一个window；2、mCursor.fillWindow(position,
window)。
     我们先来看一下CursorWindow对象的构造过程。它的构造方法中，给mStartPos赋值为0，表示起始位置，然后调用nativeCreate方法在native层创建一个CursorWindow，它是和Java层对应的，最后调用recordNewWindow将window在native层的对象缓存起来。在调用nativeCreate(mName, sCursorWindowSize)时，传入的第二个参数sCursorWindowSize就是指的我们要创建的匿名共享内存的大小了，它是定义如下：

public class CursorWindow extends SQLiteClosable implements Parcelable {
private static final String STATS_TAG = "CursorWindowStats";

/** The cursor window size. resource xml file specifies the value in kB.
* convert it to bytes here by multiplying with 1024.
*/
private static final int sCursorWindowSize =
Resources.getSystem().getInteger(
com.android.internal.R.integer.config_cursorWindowSize) * 1024;

     config_cursorWindowSize的定义是在frameworks/base/core/res/res/values/config.xml当中：

2048

     2048*1024，也就是说我们能创建的匿名共享内存的上限就是2M。我们来看一下native层的CursorWindow的构造方法：

status_t CursorWindow::create(const String8& name, size_t size, CursorWindow** outCursorWindow) {
String8 ashmemName("CursorWindow: ");
ashmemName.append(name);

status_t result;
int ashmemFd = ashmem_create_region(ashmemName.string(), size);
if (ashmemFd < 0) {
result = -errno;
} else {
result = ashmem_set_prot_region(ashmemFd, PROT_READ | PROT_WRITE);
if (result >= 0) {
void* data = ::mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, ashmemFd, 0);
if (data == MAP_FAILED) {
result = -errno;
} else {
result = ashmem_set_prot_region(ashmemFd, PROT_READ);
if (result >= 0) {
CursorWindow* window = new CursorWindow(name, ashmemFd,
data, size, false /*readOnly*/);
result = window->clear();
if (!result) {
LOG_WINDOW("Created new CursorWindow: freeOffset=%d, "
"numRows=%d, numColumns=%d, mSize=%d, mData=%p",
window->mHeader->freeOffset,
window->mHeader->numRows,
window->mHeader->numColumns,
window->mSize, window->mData);
*outCursorWindow = window;
return OK;
}
delete window;
}
}
::munmap(data, size);
}
::close(ashmemFd);
}
*outCursorWindow = NULL;
return result;
}

     在这里的代码，大家就非常清楚的看到我们Provider跨进程传递数据的真谛了，就是ashmem_create_region系统调用创建了一个匿名共享内存，然后通过它来实现数据的跨进程传递的。如果大家想学习匿名共享内存的相关知识，可以参考老罗的博客：
     Android系统匿名共享内存Ashmem（Anonymous Shared Memory）简要介绍和学习计划
     Android系统匿名共享内存Ashmem（Anonymous Shared Memory）驱动程序源代码分析

     Android系统匿名共享内存Ashmem（Anonymous Shared Memory）在进程间共享的原理分析

     老罗的博客写的非常细致，强力给大家推荐！！

     创建好了native层的匿名共享内存后，然后调用mCursor.fillWindow(position, window)，这里的mCursor就是SQLiteCursor对象，但是它没有重写带两个参数的fillWindow方法，是调用父类AbstractCursor，而父类的实现中也非常简单，就是直接调用DatabaseUtils.cursorFillWindow(this, position, window)来处理的，我们来看一下它的实现：

public static void cursorFillWindow(final Cursor cursor,
int position, final CursorWindow window) {
if (position < 0 || position >= cursor.getCount()) {
return;
}
final int oldPos = cursor.getPosition();
final int numColumns = cursor.getColumnCount();
window.clear();
window.setStartPosition(position);
window.setNumColumns(numColumns);
if (cursor.moveToPosition(position)) {
do {
if (!window.allocRow()) {
break;
}
for (int i = 0; i < numColumns; i++) {
final int type = cursor.getType(i);
final boolean success;
switch (type) {
case Cursor.FIELD_TYPE_NULL:
success = window.putNull(position, i);
break;

case Cursor.FIELD_TYPE_INTEGER:
success = window.putLong(cursor.getLong(i), position, i);
break;

case Cursor.FIELD_TYPE_FLOAT:
success = window.putDouble(cursor.getDouble(i), position, i);
break;

case Cursor.FIELD_TYPE_BLOB: {
final byte[] value = cursor.getBlob(i);
success = value != null ? window.putBlob(value, position, i)
: window.putNull(position, i);
break;
}

default: // assume value is convertible to String
case Cursor.FIELD_TYPE_STRING: {
final String value = cursor.getString(i);
success = value != null ? window.putString(value, position, i)
: window.putNull(position, i);
break;
}
}
if (!success) {
window.freeLastRow();
break;
}
}
position += 1;
} while (cursor.moveToNext());
}
cursor.moveToPosition(oldPos);
}

     分析这个方法之前，我们要先明白传进来的参数，第一个cursor就是SQLiteCursor，position是0，因为我们当前是第一次调用，window就是我们才刚刚创建好的CursorWindow对象了。接下来看一下这个方法的实现，也就是数据库操作中的本质的东西了，查到的数据都会通过调用window.putLong()、window.putDouble()、window.putBlob()、window.putString()填充到window对象上，其他剩下的逻辑我们就不展开了，大家自己有兴趣的，可以分析一下。

     上面的fillWindow方法执行完成后，最终就把window对象返回到客户端BulkCursorToCursorAdaptor对象当中了，moveToNext的逻辑也就执行完了。

     3、cursor.getBlob(cursor.getColumnIndex(Media.DATA))

     这一步就是直接调用服务端CursorWindow对象查询完成后填充好的数据了，中间的过程我们就不看了，它的最终实现是在android_database_CursorWindow.cpp当中的nativeGetBlob方法，我们来看一下它的代码：

static jbyteArray nativeGetBlob(JNIEnv* env, jclass clazz, jlong windowPtr,
jint row, jint column) {
CursorWindow* window = reinterpret_cast(windowPtr);
LOG_WINDOW("Getting blob for %d,%d from %p", row, column, window);

CursorWindow::FieldSlot* fieldSlot = window->getFieldSlot(row, column);
if (!fieldSlot) {
throwExceptionWithRowCol(env, row, column);
return NULL;
}

int32_t type = window->getFieldSlotType(fieldSlot);
if (type == CursorWindow::FIELD_TYPE_BLOB || type == CursorWindow::FIELD_TYPE_STRING) {
size_t size;
const void* value = window->getFieldSlotValueBlob(fieldSlot, &size);
jbyteArray byteArray = env->NewByteArray(size);
if (!byteArray) {
env->ExceptionClear();
throw_sqlite3_exception(env, "Native could not create new byte[]");
return NULL;
}
env->SetByteArrayRegion(byteArray, 0, size, static_cast(value));
return byteArray;
} else if (type == CursorWindow::FIELD_TYPE_INTEGER) {
throw_sqlite3_exception(env, "INTEGER data in nativeGetBlob ");
} else if (type == CursorWindow::FIELD_TYPE_FLOAT) {
throw_sqlite3_exception(env, "FLOAT data in nativeGetBlob ");
} else if (type == CursorWindow::FIELD_TYPE_NULL) {
// do nothing
} else {
throwUnknownTypeException(env, type);
}
return NULL;
}

     在这里，我想看一下它里边的数据，就自己加了一些日志输出，但是代码全部加在这个文件当中，又怕后边忘了不好找，我们就自己写个类，专门来完成我们自己的意图。为了方便查看C++中的内容，我们自己在系统的jni目录下加一个文件，专门添加我们自己的代码，防止和framework当中的代码有干扰，好，我们现在在frameworks/base/core/jni目录下加一个头文件和一个源文件，分别命名为a_leui.h、a_leui.cpp，先加一个打印jbyteArray的方法，代码非常简单：



     好，添加完成后，我们在jni目录下mm，然后打编译成功的so文件替换掉手机中当前的so库，然后再次运行并打印日志。



     这里呢需要说一下，我们搞应用层的，对C++了解非常少，当然也有很多同事经常用到JNI，那就非常熟悉了，这里的日志打印当中的%s、%d、%p等等是个格式化输出符，在网上找到了一个非常详细的总结的博客，大家如果对这个不是很了解，可以学习一下：

     printf 格式化输出符号详细说明

      好了，这里也只是简单的引入一下，只要有这个点，就可以加很多逻辑了。那么我们这里反过来，在2步骤的最后，是通过DatabaseUtils.cursorFillWindow方法来把数据填充进去的，那我们就来看一下它是怎么填充的，取出来的过程也就理解了。我们要取的blob数据，最终是调用android_database_CursorWindow.cpp当中的nativePutBlob方法来完成的，我们来看一下它的实现：

static jboolean nativePutBlob(JNIEnv* env, jclass clazz, jlong windowPtr,
jbyteArray valueObj, jint row, jint column) {
CursorWindow* window = reinterpret_cast(windowPtr);
jsize len = env->GetArrayLength(valueObj);

void* value = env->GetPrimitiveArrayCritical(valueObj, NULL);
status_t status = window->putBlob(row, column, value, len);
env->ReleasePrimitiveArrayCritical(valueObj, value, JNI_ABORT);

if (status) {
LOG_WINDOW("Failed to put blob. error=%d", status);
return false;
}

LOG_WINDOW("%d,%d is BLOB with %u bytes", row, column, len);
return true;
}

     这里的重点就是调用native层中对应的CursorWindow类的putBlob方法来填充数据了，putBlob方法很简单，是直接调用putBlobOrString来完成的，putBlobOrString方法的实现如下：

status_t CursorWindow::putBlobOrString(uint32_t row, uint32_t column,
const void* value, size_t size, int32_t type) {
if (mReadOnly) {
return INVALID_OPERATION;
}

FieldSlot* fieldSlot = getFieldSlot(row, column);
if (!fieldSlot) {
return BAD_VALUE;
}

uint32_t offset = alloc(size);
if (!offset) {
return NO_MEMORY;
}

memcpy(offsetToPtr(offset), value, size);

fieldSlot->type = type;
fieldSlot->data.buffer.offset = offset;
fieldSlot->data.buffer.size = size;
return OK;
}

     在CursorWindow内部还使用FieldSlot、RowSlot来组织管理数据的，因为本人C++基础薄弱，而且Linux系统基本上不懂，所以再深的就不展开了。有哪位清楚的话，也请指点我一下。

    这节课也就到这里了，从整个过程当中，我们可以看到，底层的实现非常的复杂，尤其是在第一步的时候，一句query调用，底层为我们作了大量的工作。也正是这种庞大的机制才能最终保证了我们使用ContentProvider数据的简易和方便！！

     好了，同学们，下课！！