接下去这个代码判断当前要获取的Content Provider是否允许在客户进程中加载,即查看一个这个Content Provider否配置了multiprocess属性为true,如果允许在客户进程中加载,就直接返回了这个Content Provider的信息了:
  1. if (r != null && cpr.canRunHere(r)) {   
  2.     // If this is a multiprocess provider, then just return its   
  3.     // info and allow the caller to instantiate it.  Only do   
  4.     // this if the provider is the same user as the caller's   
  5.     // process, or can run as root (so can be in any process).   
  6.     return cpr;   
  7. }   
 在我们这个情景中,要获取的ArticlesProvider设置了要在独立的进程中运行,因此,继续往下执行: 
  1. // This is single process, and our app is now connecting to it.   
  2. // See if we are already in the process of launching this   
  3. // provider.   
  4. final int N = mLaunchingProviders.size();   
  5. int i;   
  6. for (i=0; i<N; i++) {   
  7.     if (mLaunchingProviders.get(i) == cpr) {   
  8.         break;   
  9.     }   
  10. }   
   系统中所有正在加载的Content Provider都保存在mLaunchingProviders成员变量中。在加载相应的Content Provider之前,首先要判断一下它是可否正在被其它应用程序加载,如果是的话,就不用重复加载了。在我们这个情景中,没有其它应用程序也正在加载ArticlesProvider这个Content Provider,继续往前执行:
  1. // If the provider is not already being launched, then get it  
  2. // started.  
  3. if (i >= N) {  
  4.     final long origId = Binder.clearCallingIdentity();  
  5.     Proce***ecord proc = startProcessLocked(cpi.processName,  
  6.         cpr.appInfo, false0"content provider",  
  7.         new ComponentName(cpi.applicationInfo.packageName,  
  8.         cpi.name), false);  
  9.     ......  
  10.     mLaunchingProviders.add(cpr);  
  11.     ......  
  12. }  
        这里的条件i >= N为true,就表明没有其它应用程序正在加载这个Content Provider,因此,就要调用startProcessLocked函数来启动一个新的进程来加载这个Content Provider对应的类了,然后把这个正在加载的信息增加到mLaunchingProviders中去。我们先接着分析这个函数,然后再来看在新进程中加载Content Provider的过程,继续往下执行:
  1. // Make sure the provider is published (the same provider class  
  2. // may be published under multiple names).  
  3. if (firstClass) {  
  4.     mProvidersByClass.put(cpi.name, cpr);  
  5. }  
  6. cpr.launchingApp = proc;  
  7. mProvidersByName.put(name, cpr);  
        这段代码把这个Content Provider的信息分别保存到mProvidersByName和mProviderByCalss两个Map中去,以方便后续查询。
 
        因为我们需要获取的Content Provider是在新的进程中加载的,而getContentProviderImpl这个函数是在系统进程中执行的,它必须要等到要获取的Content Provider是在新的进程中加载完成后才能返回,这样就涉及到进程同步的问题了。这里使用的同步方法是不断地去检查变量cpr的provider域是否被设置了。当要获取的Content Provider在新的进程加载完成之后,它会通过Binder进程间通信机制调用到系统进程中,把这个cpr变量的provider域设置为已经加载好的Content Provider接口,这时候,函数getContentProviderImpl就可以返回了。下面的代码就是用来等待要获取的Content Provider是在新的进程中加载完成的:
  1. // Wait for the provider to be published...  
  2. synchronized (cpr) {  
  3.     while (cpr.provider == null) {  
  4.         ......  
  5.         try {  
  6.             cpr.wait();  
  7.         } catch (InterruptedException ex) {  
  8.         }  
  9.     }  
  10. }  
        下面我们再分析在新进程中加载ArticlesProvider这个Content Provider的过程。
 
         Step 8. ActivityManagerService.startProcessLocked
         Step 9. Process.start
         Step 10. ActivityThread.main
         Step 11. ActivityThread.attach
         Step 12. ActivityManagerService.attachApplication
   这五步是标准的Android应用程序启动步骤,具体可以参考
Android应用程序启动过程源代码分析一文中的Step 23到Step 27,或者Android系统在新进程中启动自定义服务过程(startService)的原理分析一文中的Step 4到Step 9,这里就不再详细描述了。