0x01 扯东扯西的前言&概述
本片博客对应时序图上的step15—26：上接第二篇博客：ContentProvider启动流程分析二！
同时此系列博客同步在博客园发布：ContentProvider启动流程分析系列！详情戳这里即可访问~
0x02 ContentProvider启动流程分析
step15: ApplicationThread#bindApplication()
上一步，在ApplicationThreadProxy类的bindApplication()函数中，通过Binder对象mRemote发出了一个进程间通信请求！
反查源码很容易知道，bindApplication()函数，其实是IApplicationThread接口类的接口函数，而ActivityThread类的内部类ApplicationThread实现了这一接口，所以自然也就实现了接口函数bindApplication()，我们来看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 enableOpenGlTrace, boolean isRestrictedBackupMode, boolean persistent,
Configuration config, CompatibilityInfo compatInfo, Map<String, IBinder> services,
Bundle coreSettings) {
AppBindData data = new AppBindData();
data.processName = processName;
data.appInfo = appInfo;
data.providers = providers;
data.instrumentationName = instrumentationName;
data.instrumentationArgs = instrumentationArgs;
data.instrumentationWatcher = instrumentationWatcher;
data.instrumentationUiAutomationConnection = instrumentationUiConnection;
data.debugMode = debugMode;
data.enableOpenGlTrace = enableOpenGlTrace;
data.restrictedBackupMode = isRestrictedBackupMode;
data.persistent = persistent;
data.config = config;
data.compatInfo = compatInfo;
data.initProfilerInfo = profilerInfo;
sendMessage(H.BIND_APPLICATION, data);
}
- 没错！ApplicationThread类的成员函数bindApplication()，就是类型为BIND_APPLICATION_TRANSACTION的进程间通信请求的真正处理者！处理的逻辑是：先把将要启动的ContentProvider组件列表，封装成一个AppBindData对象；
- 然后再调用外部类ActivityThread的成员函数sendMessage()，再次将这个AppBindData对象封装成一个类型为BIND_APPLICATION的消息，以便可以发送到新建应用程序进程的主线程的消息队列中！
step16: ActivityThread#sendMessage()
ActivityThread类持有一个mH成员变量，mH实际上是一个Handler对象，通过mH.sendMessage()发送消息到新建应用程序进程的主线程的消息队列中！所以，这个消息最后是最终是在mH.handleMessage()函数中处理的。
step17: ActivityThread#handleMessage()
ActivityThread内部类H的程艳方法handleMessage()源码删减如下：
public void handleMessage(Message msg) {
if (DEBUG_MESSAGES) Slog.v(TAG, ">>> handling: " + codeToString(msg.what));
switch (msg.what) {
......
case BIND_APPLICATION:
AppBindData data = (AppBindData)msg.obj;
handleBindApplication(data);
break;
......
}
if (DEBUG_MESSAGES) Slog.v(TAG, "<<< done: " + codeToString(msg.what));
}
- 在handleMessage()函数中，我们只考虑BIND_APPLICATION的情况，首先将Message对象msg的成员变量obj强转成个AppBindData对象，它包含了要启动的ContentProvider列表。
- 然后，调用handleBindApplication()函数把这些ContentProvider组件启动起来！
接下来，关注handleBindApplication()函数，是怎样把这些ContentProvider组件启动起来的？
step18： ActivityThread#handleBindApplication()
ActivityThread类的成员函数handleBindApplication()源码如下：
private void handleBindApplication(AppBindData data) {
......
// don't bring up providers in restricted mode; they may depend on the
// app's custom Application class
if (!data.restrictedBackupMode) {
List<ProviderInfo> providers = data.providers;
if (providers != null) {
installContentProviders(app, providers);
......
}
}
}
参数data是一个AppBindData对象，data的成员变量providers保存了，需要在当前进程中启动的ContentProvider组件，接下来则会调用ActivityThread类的成员函数installContentProviders()来启动这些组件！
step19: ActivityThread#installContentProviders()
ActivityThread类的成员函数installContentProviders()源码如下：
private void installContentProviders(
Context context, List<ProviderInfo> providers) {
final ArrayList<IActivityManager.ContentProviderHolder> results =
new ArrayList<IActivityManager.ContentProviderHolder>();
for (ProviderInfo cpi : providers) {
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) {
}
}
- for-each循环得到保存在providers中的每一个组件ProviderInfo对象cpi，然后调用installProvider()函数启动每个cpi对应的ContnetProvider组件；
- 这些组件启动之后，就可以获得其对应的一个IContentProvider接口；然后，把这个接口封装成一个ContentProviderHolder对象；
- 最后调用AMS代理对象（也即，ActivityManagerProxy）的成员函数publishContentProviders()，将这些ContentProviderHolder对象传递给AMS；AMS正是通过这些ContentProviderHolder对象获取它所描述的ContentProvider组件的一个访问接口；
接下来，先分析ActivityThread类成员函数installProvider()在当前应用程序进程中启动一个ContentProvider组件的过程；然后，分析AMS代理对象ActivityManagerProxy成员函数publishContentProviders()将启动完成的组件发布到AMS的过程！
step20: ActivityThread#installProvider()
ActivityThread类成员函数installProvider()源码如下：
/**
* Installs the provider.
*
* Providers that are local to the process or that come from the system server
* may be installed permanently which is indicated by setting noReleaseNeeded to true.
* Other remote providers are reference counted. The initial reference count
* for all reference counted providers is one. Providers that are not reference
* counted do not have a reference count (at all).
*
* This method detects when a provider has already been installed. When this happens,
* it increments the reference count of the existing provider (if appropriate)
* and returns the existing provider. This can happen due to concurrent
* attempts to acquire the same provider.
*/
private IActivityManager.ContentProviderHolder installProvider(Context context,
IActivityManager.ContentProviderHolder holder, ProviderInfo info,
boolean noisy, boolean noReleaseNeeded, boolean stable) {
ContentProvider localProvider = null;
IContentProvider provider;
// holder为空，表示参数info所描述的ContentProvider组件需要在当前进程中启动
if (holder == null || holder.provider == null) {
Context c = null;
ApplicationInfo ai = info.applicationInfo;
if (context.getPackageName().equals(ai.packageName)) {
c = context;
}
......
final java.lang.ClassLoader cl = c.getClassLoader();
localProvider = (ContentProvider)cl.
loadClass(info.name).newInstance();
provider = localProvider.getIContentProvider();
if (provider == null) {
return null;
}
// XXX Need to create the correct context for this provider.
localProvider.attachInfo(c, info);
} else {
provider = holder.provider;
}
IActivityManager.ContentProviderHolder retHolder;
synchronized (mProviderMap) {
IBinder jBinder = provider.asBinder();
if (localProvider != null) {
ComponentName cname = new ComponentName(info.packageName, info.name);
ProviderClientRecord pr = mLocalProvidersByName.get(cname);
if (pr != null) {
provider = pr.mProvider;
} else {
holder = new IActivityManager.ContentProviderHolder(info);
holder.provider = provider;
holder.noReleaseNeeded = true;
pr = installProviderAuthoritiesLocked(provider, localProvider, holder);
mLocalProviders.put(jBinder, pr);
mLocalProvidersByName.put(cname, pr);
}
retHolder = pr.mHolder;
} else {
ProviderRefCount prc = mProviderRefCountMap.get(jBinder);
if (prc != null) {
......
} else {
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);
}
retHolder = prc.holder;
}
}
return retHolder;
}
- 对传进来的参数holder判空，如果为null，表示要在当前应用程序进程中，将参数info所描述的ContentProvider组件启动起来；另一个参数context描述了将要启动的ContentProvider组件运行的上下文环境；
- localProvider表示一个ContentProvider组件对象，通过localProvider.getIContentProvider()，也即调用localProvider的成员函数getIContentProvider()来获得该组件对应的一个IContentProvider接口provider；这个IContentProvider最终需要发布到AMS，AMS会将它返回给那些需要访问它所描述的ContentProvider组件的调用方应用程序进程；
- 接下来通过localProvider.attachInfo()来进一步初始化前面所创建的ContentProvider组件；
- 接下来对全局变量mProviderMap加同步锁，然后对localProvider判空，正常情况下此时的localProvider应该是非空的，所以，自然要把它保存到mLocalProviders和mLocalProvidersByName中；
- 但是如果localProvider仍然为空，接下来会出现一个ProviderRefCount对象prc，用来表示和记录ContentProvider组件的引用计数，如果prc为空，则把这个localProvider封装成一个ProviderClientRecord对象，并保存在prc变量中；
- 最后，返回这个ContentProviderHolder对象！
接下来，继续分析ContentProvider组件的成员函数getIContentProvider()和成员函数attachInfo()的实现细节！
step21: ContentProvider#getIContnetProvider()
ContentProvider类成员函数getIContentProvider()源码如下：
public abstract class ContentProvider implements ComponentCallbacks2 {
......
private Transport mTransport = new Transport();
......
class Transport extends ContentProviderNative {......}
......
public IContentProvider getIContentProvider() {
return mTransport;
}
......
}
- 每一个ContentProvider组件都有一个内部类Transport，其本质是一个Binder本地对象；并且持有一个类型为Transport的全局变量mTransPort来表示一个Binder本地对象。
- 通过将这个Binder本地对象传递给AMS，然后AMS会将引用了这个Binder本地对象的一个Binder代理对象返回给需要访问该ContentProvider组件的其他应用程序进程；这样，其他应用程序进程就可以通过这个Binder代理对象来间接的访问一个ContentProvider组件中的数据了！
- ContentProvider类成员函数getIContentProvider()的实现很简单，只是简单地将全局变量mTransPort描述的一个IContentProvider接口返回给调用者。
step22: ContentProvider#attachInfo()
ContentProvider类的成员函数attachInfo()，作用是初始化前面所创建的一个ContentProvider组件！attachInfo()源码如下：
public abstract class ContentProvider implements ComponentCallbacks2 {
......
/**
* After being instantiated, this is called to tell the content provider
* about itself.
*
* @param context The context this provider is running in
* @param info Registered information about this content provider
*/
public void attachInfo(Context context, ProviderInfo info) {
attachInfo(context, info, false);
}
private void attachInfo(Context context, ProviderInfo info, boolean testing) {
......
/*
* Only allow it to be set once, so after the content service gives
* this to us clients can't change it.
*/
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);
......
}
ContentProvider.this.onCreate();
}
}
......
}
- 依然是两个重载函数，接收两个参数的attachInfo()函数内部调用了接收三个参数的attachInfo()函数，我们直接关注接收三个参数的attachInfo()函数；
- setReadPermission(info.readPermission)，setWritePermission(info.writePermission)和setPathPermissions(info.pathPermissions)这三个函数的作用是，设置ContentProvider组件的读写权限和访问权限；
- 最后ContentProvider.this.onCreate()函数，实际调用的是COntentProvider子类的onCreate()函数，以便在子类的onCreate()函数中，执行一些业务相关的初始化操作！
- 在我们最开始的场景中，ContentProvider组件指的就是BxxApp应用程序进程中SubContentProvider组件，所以上面调用的时加上就是SubContentProvider类的onCreate()函数，而我们的业务逻辑相关的一些初始化工作，也正是放在SubContentProvider类的onCreate()函数中执行的！
step23: SubContentProvider#onCreate()
public class SubContentProvider extends ContentProvider {
......
@Override
public boolean onCreate() {
ContentResolver resolver = getContext().getContentResolver();
DatabaseHelper helper = new DtatabaseHelper(......);
......
return true;
}
......
}
- 需要注意，由于一个ContentProvider组件再启动过程中需要执行onCreate()函数，因此，我们应该避免在onCeate()方法中执行耗时操作，例如和IO相关的操作，否则可能造成这个ContentProvider组件启动超时！
这一步执行完成后，就会返回到前面的step20，然后再次返回到前面的step19，即ActivityThread类成员函数installContentProviders()中，接下来就会调用AMS代理对象的成员函数publishContentProviders()，也即ActivityManagerProxy的成员函数publishContentProviders()，将前面所有启动的ContentProvider组件的一个IContentProvider访问接口发布到ActivityManagerService中~
step24: ActivityManagerProxy#publishContentProviders()
ActivityManagerProxy类成员函数publishContentProviders()，会将所有启动的ContentProvider组件的一个IContentProvider访问接口发布到ActivityManagerService中，源码如下：
public void publishContentProviders(IApplicationThread caller,
List<ContentProviderHolder> providers) throws RemoteException {
Parcel data = Parcel.obtain();
Parcel reply = Parcel.obtain();
data.writeInterfaceToken(IActivityManager.descriptor);
data.writeStrongBinder(caller != null ? caller.asBinder() : null);
data.writeTypedList(providers);
mRemote.transact(PUBLISH_CONTENT_PROVIDERS_TRANSACTION, data, reply, 0);
reply.readException();
data.recycle();
reply.recycle();
}
- 先把接收的参数保存到Parcel对象data中；
- 接着再通过ActivityManagerProxy类内部的一个Binder代理对象mRemote向ActivityMnagerService发送一个类型为PUBLISH_CONTENT_PROVIDERS_TRANSACTION进程间通信请求；
step25: ActivityManagerService#publishContentProviders()
以上10步都是在新建的应用程序进程中执行的！step25是在ActivityManagerService中执行的，AMS类成员函数publishContentProviders()，用来处理类型为PUBLISH_CONTENT_PROVIDERS_TRANSACTION进程间通信请求，其源码如下：
AMS#publishContentProviders()
- 参数caller是一个类型为ApplicationThread的Binder代理对象，它引用了运行在新建应用程序进程中的一个ApplicationThread对象，getRecordForAppLocked(caller)方法通过caller来获取一个用来描述新建应用程序进程的ProcessRecord对象r；
- 新建应用程序进程在启动时，会将需要在它里面运行的ContentProvider组件启动起来！从前面的step13可知，在AMS中，这些ContentProvider组件使用一个ContentProviderRecord对象来描述，它们保存在用来描述新建应用程序进程的一个ProcessRecord对象r的一个成员变量pubProviders中；
- 第10到14行，第一个for循环，取出providers中的每一个ContentProvider组件，并且拿到ContentProvider组件对应的ContentProviderRecord对象dst；
- 第15到22行，第二个for循环，通过两种方式，把ContentProviderRecord对象dst保存到全局变量mProviderMap；
- 参数providers包含了要发布到AMS中的ContentProvider组件，每一个ContentProvider组件都使用一个ContentProviderHolder对象来描述，它里面包含了要发布的ContentProvider组件的一个IContentProvider接口，如图第34行到40行所示！
从前面的step8可知，一个应用程序进程请求ActivityManagerService返回一个ContentProvider组件的代理对象时，如果这个ContentProvider组件还未启动起来，那么AMS就会先创建一个新的应用程序进程来启动该ContentProvider组件，然后再在一个while循环中等待该ContentProvider组件启动完成，并且将他的一个代理对象发布到AMS中。
现在既然这个ContentProvider已经启动完成，并且将它的一个代理对象，即一个类型为Transport的Binder代理对象发布到AMS，因此，前面正在等待的一个AMS线程就可以停止等待，并且将这个类型为Transport的Binder代理对象封装成一个ContentProvider对象返回给请求它的应用程序进程。
这一步执行完毕，就会使得AMS从前面的step8返回step5，即返回到MainActivity组件所运行的应用程序进程中，即AxxApp应用程序进程！然后，继续执行ActivityThread类成员函数installProvider()，用来保存前面从ActivityManagerService获得的一个ContentProvider组件的一个IContentProvider访问接口。
step26: ActivityThread#installProvider()
ActivityThread类成员函数installProvider()源码如下：
/**
* Installs the provider.
*
* Providers that are local to the process or that come from the system server
* may be installed permanently which is indicated by setting noReleaseNeeded to true.
* Other remote providers are reference counted. The initial reference count
* for all reference counted providers is one. Providers that are not reference
* counted do not have a reference count (at all).
*
* This method detects when a provider has already been installed. When this happens,
* it increments the reference count of the existing provider (if appropriate)
* and returns the existing provider. This can happen due to concurrent
* attempts to acquire the same provider.
*/
private IActivityManager.ContentProviderHolder installProvider(Context context,
IActivityManager.ContentProviderHolder holder, ProviderInfo info,
boolean noisy, boolean noReleaseNeeded, boolean stable) {
ContentProvider localProvider = null;
IContentProvider provider;
if (holder == null || holder.provider == null) {
Context c = null;
ApplicationInfo ai = info.applicationInfo;
if (context.getPackageName().equals(ai.packageName)) {
c = context;
} else if (mInitialApplication != null &&
mInitialApplication.getPackageName().equals(ai.packageName)) {
c = mInitialApplication;
} else {
try {
c = context.createPackageContext(ai.packageName,
Context.CONTEXT_INCLUDE_CODE);
} catch (PackageManager.NameNotFoundException e) {
// Ignore
}
}
if (c == null) {
return null;
}
try {
final java.lang.ClassLoader cl = c.getClassLoader();
localProvider = (ContentProvider)cl.
loadClass(info.name).newInstance();
provider = localProvider.getIContentProvider();
if (provider == null) {
return null;
}
// XXX Need to create the correct context for this provider.
localProvider.attachInfo(c, info);
} catch (java.lang.Exception e) {......}
} else {
provider = holder.provider;
}
IActivityManager.ContentProviderHolder retHolder;
synchronized (mProviderMap) {
IBinder jBinder = provider.asBinder();
if (localProvider != null) {
ComponentName cname = new ComponentName(info.packageName, info.name);
ProviderClientRecord pr = mLocalProvidersByName.get(cname);
if (pr != null) {
provider = pr.mProvider;
} else {
holder = new IActivityManager.ContentProviderHolder(info);
holder.provider = provider;
holder.noReleaseNeeded = true;
pr = installProviderAuthoritiesLocked(provider, localProvider, holder);
mLocalProviders.put(jBinder, pr);
mLocalProvidersByName.put(cname, pr);
}
retHolder = pr.mHolder;
} else {
ProviderRefCount prc = mProviderRefCountMap.get(jBinder);
if (prc != null) {
// We need to transfer our new reference to the existing
// ref count, releasing the old one... but only if
// release is needed (that is, it is not running in the
// system process).
if (!noReleaseNeeded) {
incProviderRefLocked(prc, stable);
try {
ActivityManagerNative.getDefault().removeContentProvider(
holder.connection, stable);
} catch (RemoteException e) {
//do nothing content provider object is dead any way
}
}
} else {
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);
}
retHolder = prc.holder;
}
}
return retHolder;
}
这步与前面的step20，都是在ActivityThread类成员函数installProvider()。不过，前面step20是在启动ContentProvider组件的应用程序进程中执行的；而这步是在AxxApp应用程序的MainActivity中执行的！另一个区别是：这步得到参数provider不等于null，它用来描述一个在其他应用程序进程中启动的ContentProvider组件的一个IContentProvider访问接口。
这步执行完成后，就返回到前面的step1，这时在AxxApp应用的MainActivity中，就获得了与URI值对应的SubContentProvider组件的一个IContentProvider访问接口，最后就可以通过这个接口访问另一个应用程序的数据内容了！
0x03 参考文献与简单的结语
至此，ContentProvider启动流程分析到此结束！
