基于N源码的ContentProvider调用流程分析

内容提供者顾名思义是用来提供数据的，现在假设我要获取系统联系人的数据，可以这样查询：

getContentResolver().query(Contacts.CONTENT_URI, null, null, null, null);

这样就会跳转到联系人的provider的query：

public class ContactsProvider2 extends AbstractContactsProvider public Cursor query(Uri uri, String[] projection, String selection, String[] selectionArgs, String sortOrder, CancellationSignal cancellationSignal) {

这个过程是如何做到的？下面来跟下这个流程：

调用getContentResolver会进入ContextImpl.java：

public ContentResolver getContentResolver() { return mContentResolver; }

mContentResolver是ApplicationContentResolver类型，在实例化ContextImpl的时候初始化。

接着进入ContentResolver.java中的query：

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; } qCursor = unstableProvider.query(mPackageName, uri, projection, selection, selectionArgs, sortOrder, remoteCancellationSignal); }

先调用acquireUnstableProvider来获取IContentProvider binder接口，这个接口的真正的实现者其实是ContentProvider中的Transport:

class Transport extends ContentProviderNative { abstract public class ContentProviderNative extends Binder implements IContentProvider {

可以看到ContentProviderNative继承Binder实现IContentProvider接口，就是服务的中间者stub的替身，真正的实现者在它的子类当中：

class Transport extends ContentProviderNative { AppOpsManager mAppOpsManager = null; int mReadOp = AppOpsManager.OP_NONE; int mWriteOp = AppOpsManager.OP_NONE; @Override public Cursor query(String callingPkg, Uri uri, String[] projection, String selection, String[] selectionArgs, String sortOrder, ICancellationSignal cancellationSignal) { Cursor cursor = ContentProvider.this.query(uri, projection, selection, selectionArgs, sortOrder, CancellationSignal.fromTransport( cancellationSignal)); }

这里调用ContentProvider.this.query其实就是调用ContentProvider子类的query，比如这里调用的是联系人的ContactsProvider2，它继承AbstractContactsProvider，AbstractContactsProvider继承ContentProvider。

知道了这个binder的真身后，我们回到前面ContentResolver中的query中，是通过acquireUnstableProvider来获取binder接口，跟踪到ApplicationContentResolver中的acquireUnstableProvider：

protected IContentProvider acquireUnstableProvider(Context c, String auth) { return mMainThread.acquireProvider(c, ContentProvider.getAuthorityWithoutUserId(auth), resolveUserIdFromAuthority(auth), false); }

接着进入ActivityThread中的acquireProvider：

public final IContentProvider acquireProvider( Context c, String auth, int userId, boolean stable) { final IContentProvider provider = acquireExistingProvider(c, auth, userId, stable); if (provider != null) { return provider; } // There is a possible race here. Another thread may try to acquire // the same provider at the same time. When this happens, we want to ensure // that the first one wins. // Note that we cannot hold the lock while acquiring and installing the // provider since it might take a long time to run and it could also potentially // be re-entrant in the case where the provider is in the same process. IActivityManager.ContentProviderHolder holder = null; try { holder = ActivityManagerNative.getDefault().getContentProvider( getApplicationThread(), auth, userId, stable); } catch (RemoteException ex) { throw ex.rethrowFromSystemServer(); } if (holder == null) { Slog.e(TAG, "Failed to find provider info for " + auth); return null; } // Install provider will increment the reference count for us, and break // any ties in the race. holder = installProvider(c, holder, holder.info, true /*noisy*/, holder.noReleaseNeeded, stable); return holder.provider; }

该方法同样先调用acquireExistingProvider获取缓存中的IContentProvider binder本地代理对象，如果不存在，则跨进程到AMS中获取，获取到后调用installProvider来创建provider，最后返回provider的本地代理ContentProviderProxy。

下面进入AMS看下getContentProvider是如何获取这个holder：

public final ContentProviderHolder getContentProvider( IApplicationThread caller, String name, int userId, boolean stable) { return getContentProviderImpl(caller, name, null, stable, userId); }

进入getContentProviderImpl：

private ContentProviderHolder getContentProviderImpl(IApplicationThread caller, String name, IBinder token, boolean stable, int userId) { ContentProviderRecord cpr; ContentProviderConnection conn = null; ProviderInfo cpi = null; // First check if this content provider has been published... cpr = mProviderMap.getProviderByName(name, userId); cpi = AppGlobals.getPackageManager(). resolveContentProvider(name, STOCK_PM_FLAGS | PackageManager.GET_URI_PERMISSION_PATTERNS, userId); cpr = new ContentProviderRecord(this, cpi, ai, comp, singleton); // If the provider is not already being launched, then get it started. proc = startProcessLocked(cpi.processName, cpr.appInfo, false, 0, "content provider", new ComponentName(cpi.applicationInfo.packageName, cpi.name), false, false, false); cpr.launchingApp = proc; mLaunchingProviders.add(cpr); // Make sure the provider is published (the same provider class // may be published under multiple names). if (firstClass) { mProviderMap.putProviderByClass(comp, cpr); } mProviderMap.putProviderByName(name, cpr); <pre class="java" name="code"> synchronized (cpr) { while (cpr.provider == null) { if (cpr.launchingApp == null) { Slog.w(TAG, "Unable to launch app " + cpi.applicationInfo.packageName + "/" + cpi.applicationInfo.uid + " for provider " + name + ": launching app became null"); EventLog.writeEvent(EventLogTags.AM_PROVIDER_LOST_PROCESS, UserHandle.getUserId(cpi.applicationInfo.uid), cpi.applicationInfo.packageName, cpi.applicationInfo.uid, name); return null; } try { if (DEBUG_MU) Slog.v(TAG_MU, "Waiting to start provider " + cpr + " launchingApp=" + cpr.launchingApp); if (conn != null) { conn.waiting = true; } cpr.wait(); } catch (InterruptedException ex) { } finally { if (conn != null) { conn.waiting = false; } } } } return cpr != null ? cpr.newHolder(conn) : null;}

首先会去检查content provider是否已经发布了，如果没有就会创建ContentProviderRecord对象，如果provider所在进程未启动，接着会调用startProcessLocked启动进程。接着等待新进程保存的provider，获取provider信息后就返回ContentProviderHolder。

下面看下startProcessLocked流程：

private final void startProcessLocked(ProcessRecord app, String hostingType, String hostingNameStr, String abiOverride, String entryPoint, String[] entryPointArgs) { if (entryPoint == null) entryPoint = "android.app.ActivityThread"; Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "Start proc: " + app.processName); checkTime(startTime, "startProcess: asking zygote to start proc"); Process.ProcessStartResult startResult = Process.start(entryPoint, app.processName, uid, uid, gids, debugFlags, mountExternal, app.info.targetSdkVersion, app.info.seinfo, requiredAbi, instructionSet, app.info.dataDir, entryPointArgs); }

进入Process.start会通知zygote开启进程，接着进入ActivityThread.main:

public static void main(String[] args) { Looper.prepareMainLooper(); ActivityThread thread = new ActivityThread(); thread.attach(false); if (sMainThreadHandler == null) { sMainThreadHandler = thread.getHandler(); } Looper.loop(); }

创建消息队列后，进入ActivityThread.attach:

private void attach(boolean system) { final IActivityManager mgr = ActivityManagerNative.getDefault(); try { mgr.attachApplication(mAppThread); } }

然后跨进程进入AMS的attachApplication：

public final void attachApplication(IApplicationThread thread) { synchronized (this) { int callingPid = Binder.getCallingPid(); final long origId = Binder.clearCallingIdentity(); attachApplicationLocked(thread, callingPid); Binder.restoreCallingIdentity(origId); } }

进入attachApplicationLocked：

thread.bindApplication(processName, appInfo, providers, app.instrumentationClass, profilerInfo, app.instrumentationArguments, app.instrumentationWatcher, app.instrumentationUiAutomationConnection, testMode, mBinderTransactionTrackingEnabled, enableTrackAllocation, isRestrictedBackupMode || !normalMode, app.persistent, new Configuration(mConfiguration), app.compat, getCommonServicesLocked(app.isolated), mCoreSettingsObserver.getCoreSettingsLocked());

接着又跨进程返回ApplicationThread中的bindApplication：

public final void bindApplication(String processName, ApplicationInfo appInfo, List<ProviderInfo> providers, ComponentName instrumentationName, ProfilerInfo profilerInfo, Bundle instrumentationArgs, IInstrumentationWatcher instrumentationWatcher, IUiAutomationConnection instrumentationUiConnection, int debugMode, boolean enableBinderTracking, boolean trackAllocation, boolean isRestrictedBackupMode, boolean persistent, Configuration config, CompatibilityInfo compatInfo, Map<String, IBinder> services, Bundle coreSettings) { sendMessage(H.BIND_APPLICATION, data); }

这里发送消息BIND_APPLICATION，然后接收消息：

case BIND_APPLICATION: Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "bindApplication"); AppBindData data = (AppBindData)msg.obj; handleBindApplication(data); Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER); break;

进入handleBindApplication：

private void handleBindApplication(AppBindData data) { installContentProviders(app, data.providers); } private void installContentProviders( Context context, List<ProviderInfo> providers) { final ArrayList<IActivityManager.ContentProviderHolder> results = new ArrayList<IActivityManager.ContentProviderHolder>(); 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()); } IActivityManager.ContentProviderHolder cph = installProvider(context, null, cpi, false /*noisy*/, true /*noReleaseNeeded*/, true /*stable*/); if (cph != null) { cph.noReleaseNeeded = true; results.add(cph); } } try { ActivityManagerNative.getDefault().publishContentProviders( getApplicationThread(), results); } catch (RemoteException ex) { throw ex.rethrowFromSystemServer(); } }

这个函数主要是做了两件事情，一是调用installProvider来在本地安装每一个Content Proivder的信息，并且为每一个Content Provider创建一个ContentProviderHolder对象来保存相关的信息。ContentProviderHolder对象是一个Binder对象，是用来把Content Provider的信息传递给ActivityManagerService服务的。当这些Content Provider都处理好了以后，还要调用ActivityManagerService服务的publishContentProviders函数来通知ActivityManagerService服务，这个进程中所要加载的Content Provider，都已经准备完毕了，而ActivityManagerService服务的publishContentProviders函数的作用就是用来唤醒在前面等待的线程的了。

下面看下installProvider:

private IActivityManager.ContentProviderHolder installProvider(Context context, IActivityManager.ContentProviderHolder holder, ProviderInfo info, boolean noisy, boolean noReleaseNeeded, boolean stable) { ContentProvider localProvider = null; IContentProvider provider; final java.lang.ClassLoader cl = c.getClassLoader(); localProvider = (ContentProvider)cl. loadClass(info.name).newInstance(); provider = localProvider.getIContentProvider(); localProvider.attachInfo(c, info); }

这个函数的作用主要就是在应用程序进程中把相应的Content Provider类加载进来了,调用getIContentProvider获取本地binder对象。ContentProvider类和Transport类的关系就类似于ActivityThread和ApplicationThread的关系，其它应用程序不是直接调用ContentProvider接口来访问它的数据，而是通过调用它的内部对象mTransport来间接调用ContentProvider的接口，接着调用attachInfo函数调用provider的onCreate方法。 接着看下AMS的publishContentProviders方法：

public final void publishContentProviders(IApplicationThread caller, List<ContentProviderHolder> providers) { synchronized (this) { final ProcessRecord r = getRecordForAppLocked(caller); if (DEBUG_MU) Slog.v(TAG_MU, "ProcessRecord uid = " + r.uid); if (r == null) { throw new SecurityException( "Unable to find app for caller " + caller + " (pid=" + Binder.getCallingPid() + ") when publishing content providers"); } final long origId = Binder.clearCallingIdentity(); final int N = providers.size(); for (int i = 0; i < N; i++) { ContentProviderHolder src = providers.get(i); if (src == null || src.info == null || src.provider == null) { continue; } ContentProviderRecord dst = r.pubProviders.get(src.info.name); if (DEBUG_MU) Slog.v(TAG_MU, "ContentProviderRecord uid = " + dst.uid); if (dst != null) { ComponentName comp = new ComponentName(dst.info.packageName, dst.info.name); mProviderMap.putProviderByClass(comp, dst); String names[] = dst.info.authority.split(";"); for (int j = 0; j < names.length; j++) { mProviderMap.putProviderByName(names[j], dst); } int launchingCount = mLaunchingProviders.size(); int j; boolean wasInLaunchingProviders = false; for (j = 0; j < launchingCount; j++) { if (mLaunchingProviders.get(j) == dst) { mLaunchingProviders.remove(j); wasInLaunchingProviders = true; j--; launchingCount--; } } if (wasInLaunchingProviders) { mHandler.removeMessages(CONTENT_PROVIDER_PUBLISH_TIMEOUT_MSG, r); } synchronized (dst) { dst.provider = src.provider; dst.proc = r; dst.notifyAll(); } updateOomAdjLocked(r); maybeUpdateProviderUsageStatsLocked(r, src.info.packageName, src.info.authority); } } } }

首先是把这个Content Provider信息保存好在mProvidersByClass和mProvidersByName中，这两个Map中，一个是以类名为键值保存Content Provider信息，一个是以authority为键值保存Content Provider信息。执行了dst.notiryAll语句后，在前面等待要获取的Content Provider接口加载完毕的线程就被唤醒了。

private ContentProviderHolder getContentProviderImpl(IApplicationThread caller, String name, IBinder token, boolean stable, int userId) { cpr.wait(); return cpr != null ? cpr.newHolder(conn) : null; }

唤醒之后，它检查本地ContentProviderRecord变量cpr的provider域不为null，于是就返回了。

它最终返回到ActivityThread类的acquireProvider函数中。

public final IContentProvider acquireProvider( Context c, String auth, int userId, boolean stable) { holder = installProvider(c, holder, holder.info,true /*noisy*/, holder.noReleaseNeeded, stable); return holder.provider; }

这里同样是执行installProvider函数，这里传进来的参数provider是不为null的，因此，它不需要执行在本地加载Content Provider的工作，只需要把从ActivityMangerService中获得的Content Provider接口保存在成员变量mProviderMap中就可以了：

private IActivityManager.ContentProviderHolder installProvider(Context context, IActivityManager.ContentProviderHolder holder, ProviderInfo info, boolean noisy, boolean noReleaseNeeded, boolean stable) { provider = holder.provider; ProviderClientRecord client = installProviderAuthoritiesLocked( provider, localProvider, holder); if (noReleaseNeeded) { prc = new ProviderRefCount(holder, client, 1000, 1000); } else { prc = stable ? new ProviderRefCount(holder, client, 1, 0) : new ProviderRefCount(holder, client, 0, 1); } mProviderRefCountMap.put(jBinder, prc); }

这里我们分析Android应用程序组件Content Provider在不同进程中传输数据的过程，即Content Provider在不同应用程序中共享数据的原理。