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

标签：android   style   blog   http   io   ar   color   os   使用   

文章转载至CSDN社区罗升阳的安卓之旅，原文地址：http://blog.csdn.net/luoshengyang/article/details/6963418

通过前面的学习，我们知道在Android系统中，Content Provider可以为不同的应用程序访问相同的数据提供统一的入口。Content Provider一般是运行在独立的进程中的，每一个Content Provider在系统中只有一个实例存在，其它应用程序首先要找到这个实例，然后才能访问它的数据。那么，系统中的Content Provider实例是由谁来负责启动的呢？本文将回答这个问题。

        Content Provider和应用程序组件Activity、Service一样，需要在AndroidManifest.xml文件中配置之后才能使用。系统在安 装包含Content Provider的应用程序的时候，会把这些Content Provider的描述信息保存起来，其中最重要的就是Content Provider的Authority信息，Android应用程序的安装过程具体可以参考Android应用程序安装过程源代码分析一 文。注意，安装应用程序的时候，并不会把相应的Content Provider加载到内存中来，系统采取的是懒加载的机制，等到第一次要使用这个Content Provider的时候，系统才会把它加载到内存中来，下次再要使用这个Content Provider的时候，就可以直接返回了。

        本文以前面一篇文章Android应用程序组件Content Provider应用实例中的例子来详细分析Content Provider的启动过程。在Android应用程序组件Content Provider应用实例这 篇文章介绍的应用程序Article中，第一次使用ArticlesProvider这个Content Provider的地方是ArticlesAdapter类的getArticleCount函数，因为MainActivity要在ListView中 显示文章信息列表时， 首先要知道ArticlesProvider中的文章信息的数量。从ArticlesAdapter类的getArticleCount函数调用开始，一 直到ArticlesProvider类的onCreate函数被调用，就是ArticlesProvider的完整启动过程，下面我们就先看看这个过程 的序列图，然后再详细分析每一个步骤：

        Step 1. ArticlesAdapter.getArticleCount

        这个函数定义在前面一篇文章Android应用程序组件Content Provider应用实例介绍的应用程序Artilce源代码工程目录下，在文件为packages/experimental/Article/src/shy/luo/article/ArticlesAdapter.java中：

[java] view plaincopy

1. public class ArticlesAdapter {  
2.     ......  
3.   
4.     private ContentResolver resolver = null;  
5.   
6.     public ArticlesAdapter(Context context) {  
7.         resolver = context.getContentResolver();  
8.     }  
9.   
10.     ......  
11.   
12.     public int getArticleCount() {  
13.         int count = 0;  
14.   
15.         try {  
16.             IContentProvider provider = resolver.acquireProvider(Articles.CONTENT_URI);  
17.             Bundle bundle = provider.call(Articles.METHOD_GET_ITEM_COUNT, null, null);  
18.             count = bundle.getInt(Articles.KEY_ITEM_COUNT, 0);  
19.         } catch(RemoteException e) {  
20.             e.printStackTrace();  
21.         }  
22.   
23.         return count;  
24.     }  
25.   
26.     ......  
27. }  

         这个函数通过应用程序上下文的ContentResolver接口resolver的acquireProvider函数来获得与 Articles.CONTENT_URI对应的Content Provider对象的IContentProvider接口。常量Articles.CONTENT_URI是在应用程序 ArticlesProvider中定义的，它的值为“content://shy.luo.providers.articles/item”，对应的 Content Provider就是ArticlesProvider了。

         Step 2. ContentResolver.acqireProvider

         这个函数定义在frameworks/base/core/java/android/content/ContentResolver.java文件中：

[java] view plaincopy

1. public abstract class ContentResolver {  
2.     ......  
3.   
4.     public final IContentProvider acquireProvider(Uri uri) {  
5.         if (!SCHEME_CONTENT.equals(uri.getScheme())) {  
6.             return null;  
7.         }  
8.         String auth = uri.getAuthority();  
9.         if (auth != null) {  
10.             return acquireProvider(mContext, uri.getAuthority());  
11.         }  
12.         return null;  
13.     }  
14.   
15.     ......  
16. }  

        函数首先验证参数uri的scheme是否正确，即是否是以content://开头，然后取出它的authority部分，最后调用另外一个成员函数 acquireProvider执行获取ContentProvider接口的操作。在我们这个情景中，参数uri的authority的内容便是 “shy.luo.providers.articles”了。

        从ContentResolver类的定义我们可以看出，它是一个抽象类，两个参数版本的acquireProvider函数是由它的子类来实现的。回 到Step 1中，这个ContentResolver接口是通过应用程序上下文Context对象的getContentResolver函数来获得的，而应用程序 上下文Context是由ContextImpl类来实现的，它定义在frameworks/base/core/java/android/app /ContextImpl.java文件中：

[java] view plaincopy

1. class ContextImpl extends Context {  
2.     ......  
3.   
4.     private ApplicationContentResolver mContentResolver;  
5.   
6.     ......  
7.   
8.     final void init(LoadedApk packageInfo,  
9.             IBinder activityToken, ActivityThread mainThread,  
10.             Resources container) {  
11.         ......  
12.   
13.         mContentResolver = new ApplicationContentResolver(this, mainThread);  
14.   
15.         ......  
16.     }  
17.   
18.     ......  
19.   
20.     @Override  
21.     public ContentResolver getContentResolver() {  
22.         return mContentResolver;  
23.     }  
24.   
25.     ......  
26. }  

         ContextImpl类的init函数是在应用程序启动的时候调用的，具体可以参考Android应用程序启动过程源代码分析一文中的Step 34。

         因此，在上面的ContentResolver类的acquireProvider函数里面接下来要调用的ApplicationContentResolver类的acquireProvider函数。

         Step 3. ApplicationContentResolve.acquireProvider

         这个函数定义在frameworks/base/core/java/android/app/ContextImpl.java文件中：

[java] view plaincopy

1. class ContextImpl extends Context {  
2.     ......  
3.   
4.     private static final class ApplicationContentResolver extends ContentResolver {  
5.         ......  
6.   
7.         @Override  
8.         protected IContentProvider acquireProvider(Context context, String name) {  
9.             return mMainThread.acquireProvider(context, name);  
10.         }  
11.   
12.         ......  
13.   
14.         private final ActivityThread mMainThread;  
15.     }  
16.   
17.     ......  
18. }  

         它调用ActivityThread类的acquireProvider函数进一步执行获取Content Provider接口的操作。

         Step 4. ActivityThread.acquireProvider

         这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件中：

[java] view plaincopy

1. public final class ActivityThread {  
2.     ......  
3.   
4.     public final IContentProvider acquireProvider(Context c, String name) {  
5.         IContentProvider provider = getProvider(c, name);  
6.         if(provider == null)  
7.             return null;  
8.         ......  
9.         return provider;  
10.     }  
11.   
12.     ......  
13. }  

         它又是调用了另外一个成员函数getProvider来进一步执行获取Content Provider接口的操作。

         Step 5. ActivityThread.getProvider

         这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件中：

[java] view plaincopy

1. public final class ActivityThread {  
2.     ......  
3.   
4.     private final IContentProvider getExistingProvider(Context context, String name) {  
5.         synchronized(mProviderMap) {  
6.             final ProviderClientRecord pr = mProviderMap.get(name);  
7.             if (pr != null) {  
8.                 return pr.mProvider;  
9.             }  
10.             return null;  
11.         }  
12.     }  
13.   
14.     ......  
15.   
16.     private final IContentProvider getProvider(Context context, String name) {  
17.         IContentProvider existing = getExistingProvider(context, name);  
18.         if (existing != null) {  
19.             return existing;  
20.         }  
21.   
22.         IActivityManager.ContentProviderHolder holder = null;  
23.         try {  
24.             holder = ActivityManagerNative.getDefault().getContentProvider(  
25.                 getApplicationThread(), name);  
26.         } catch (RemoteException ex) {  
27.         }  
28.   
29.         IContentProvider prov = installProvider(context, holder.provider,  
30.             holder.info, true);  
31.   
32.         ......  
33.   
34.         return prov;  
35.     }  
36.   
37.     ......  
38. }  

         这个函数首先会通过getExistingProvider函数来检查本地是否已经存在这个要获取的ContentProvider接口，如果存在，就直 接返回了。本地已经存在的ContextProvider接口保存在ActivityThread类的mProviderMap成员变量中，以 ContentProvider对应的URI的authority为键值保存。在我们这个情景中，因为是第一次调用ArticlesProvider接 口，因此，这时候通过getExistingProvider函数得到的IContentProvider接口为null，于是下面就会调用 ActivityManagerService服务的getContentProvider接口来获取一个ContentProviderHolder对 象holder，这个对象就包含了我们所要获取的ArticlesProvider接口，在将这个接口返回给调用者之后，还会调用 installProvider函数来把这个接口保存在本地中，以便下次要使用这个ContentProvider接口时，直接就可以通过 getExistingProvider函数获取了。

        我们先进入到ActivityManagerService服务的getContentProvider函数中看看它是如何获取我们所需要的ArticlesProvider接口的，然后再返回来看看installProvider函数的实现。

        Step 6. ActivityManagerService.getContentProvider

        这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityManagerService.java文件中：

[java] view plaincopy

1. public final class ActivityManagerService extends ActivityManagerNative  
2.         implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback {  
3.     ......  
4.   
5.     public final ContentProviderHolder getContentProvider(  
6.             IApplicationThread caller, String name) {  
7.         ......  
8.   
9.         return getContentProviderImpl(caller, name);  
10.     }  
11.   
12.     ......  
13. }  

        它调用getContentProviderImpl函数来进一步执行操作。

        Step 7. ActivityManagerService.getContentProviderImpl

        这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityManagerService.java文件中：

[java] view plaincopy

1. public final class ActivityManagerService extends ActivityManagerNative  
2.         implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback {  
3.     ......  
4.   
5.     private final ContentProviderHolder getContentProviderImpl(  
6.             IApplicationThread caller, String name) {  
7.         ContentProviderRecord cpr;  
8.         ProviderInfo cpi = null;  
9.   
10.         synchronized(this) {  
11.             ProcessRecord r = null;  
12.             if (caller != null) {  
13.                 r = getRecordForAppLocked(caller);  
14.                 ......  
15.             }  
16.   
17.             // First check if this content provider has been published...  
18.             cpr = mProvidersByName.get(name);  
19.             if (cpr != null) {  
20.                 ......  
21.             } else {  
22.                 try {  
23.                     cpi = AppGlobals.getPackageManager().  
24.                         resolveContentProvider(name,  
25.                         STOCK_PM_FLAGS | PackageManager.GET_URI_PERMISSION_PATTERNS);  
26.                 } catch (RemoteException ex) {  
27.                 }  
28.                 ......  
29.             }  
30.   
31.             cpr = mProvidersByClass.get(cpi.name);  
32.             final boolean firstClass = cpr == null;  
33.             if (firstClass) {  
34.                 try {  
35.                     ApplicationInfo ai =  
36.                         AppGlobals.getPackageManager().  
37.                         getApplicationInfo(  
38.                         cpi.applicationInfo.packageName,  
39.                         STOCK_PM_FLAGS);  
40.                     ......  
41.                     cpr = new ContentProviderRecord(cpi, ai);  
42.                 } catch (RemoteException ex) {  
43.                     // pm is in same process, this will never happen.  
44.                 }  
45.             }  
46.   
47.             if (r != null && cpr.canRunHere(r)) {  
48.                 // If this is a multiprocess provider, then just return its  
49.                 // info and allow the caller to instantiate it.  Only do  
50.                 // this if the provider is the same user as the caller‘s  
51.                 // process, or can run as root (so can be in any process).  
52.                 return cpr;  
53.             }  
54.   
55.             ......  
56.   
57.             // This is single process, and our app is now connecting to it.  
58.             // See if we are already in the process of launching this  
59.             // provider.  
60.             final int N = mLaunchingProviders.size();  
61.             int i;  
62.             for (i=0; i<N; i++) {  
63.                 if (mLaunchingProviders.get(i) == cpr) {  
64.                     break;  
65.                 }  
66.             }  
67.   
68.             // If the provider is not already being launched, then get it  
69.             // started.  
70.             if (i >= N) {  
71.                 final long origId = Binder.clearCallingIdentity();  
72.                 ProcessRecord proc = startProcessLocked(cpi.processName,  
73.                     cpr.appInfo, false, 0, "content provider",  
74.                     new ComponentName(cpi.applicationInfo.packageName,  
75.                     cpi.name), false);  
76.                 ......  
77.                 mLaunchingProviders.add(cpr);  
78.                 ......  
79.             }  
80.   
81.             // Make sure the provider is published (the same provider class  
82.             // may be published under multiple names).  
83.             if (firstClass) {  
84.                 mProvidersByClass.put(cpi.name, cpr);  
85.             }  
86.             cpr.launchingApp = proc;  
87.             mProvidersByName.put(name, cpr);  
88.   
89.             ......  
90.         }  
91.   
92.         // Wait for the provider to be published...  
93.         synchronized (cpr) {  
94.             while (cpr.provider == null) {  
95.                 ......  
96.                 try {  
97.                     cpr.wait();  
98.                 } catch (InterruptedException ex) {  
99.                 }  
100.             }  
101.         }  
102.   
103.         return cpr;  
104.     }  
105.       
106.     ......  
107. }  

        这个函数比较长，我们一步一步地分析。
        函数首先是获取调用者的进程记录块信息：

[java] view plaincopy

1. ProcessRecord r = null;  
2. if (caller != null) {  
3.     r = getRecordForAppLocked(caller);  
4.     ......  
5. }  

        在我们这个情景中，要获取的就是应用程序Article的进程记录块信息了，后面会用到。

        在ActivityManagerService中，有两个成员变量是用来保存系统中的Content Provider信息的，一个是mProvidersByName，一个是mProvidersByClass，前者是以Content Provider的authoriry值为键值来保存的，后者是以Content Provider的类名为键值来保存的。一个Content Provider可以有多个authority，而只有一个类来和它对应，因此，这里要用两个Map来保存，这里为了方便根据不同条件来快速查找而设计 的。下面的代码就是用来检查要获取的Content Provider是否已经加存在的了：

[java] view plaincopy

1. // First check if this content provider has been published...  
2. cpr = mProvidersByName.get(name);  
3. if (cpr != null) {  
4.     ......  
5. } else {  
6.     try {  
7.         cpi = AppGlobals.getPackageManager().  
8.             resolveContentProvider(name,  
9.             STOCK_PM_FLAGS | PackageManager.GET_URI_PERMISSION_PATTERNS);  
10.     } catch (RemoteException ex) {  
11.     }  
12.     ......  
13. }  
14.   
15. cpr = mProvidersByClass.get(cpi.name);  
16. final boolean firstClass = cpr == null;  
17. if (firstClass) {  
18.     try {  
19.         ApplicationInfo ai =  
20.             AppGlobals.getPackageManager().  
21.             getApplicationInfo(  
22.             cpi.applicationInfo.packageName,  
23.             STOCK_PM_FLAGS);  
24.         ......  
25.         cpr = new ContentProviderRecord(cpi, ai);  
26.     } catch (RemoteException ex) {  
27.         // pm is in same process, this will never happen.  
28.     }  
29. }  

        在我们这个情景中，由于是第一次调用ArticlesProvider接口，因此，在mProvidersByName和 mProvidersByClass两个Map中都不存在ArticlesProvider的相关信息，因此，这里会通过 AppGlobals.getPackageManager函数来获得PackageManagerService服务接口，然后分别通过它的 resolveContentProvider和getApplicationInfo函数来分别获取ArticlesProvider应用程序的相关信 息，分别保存在cpi和cpr这两个本地变量中。这些信息都是在安装应用程序的过程中保存下来的，具体可以参考Android应用程序安装过程源代码分析一文。

        接下去这个代码判断当前要获取的Content Provider是否允许在客户进程中加载，即查看一个这个Content Provider否配置了multiprocess属性为true，如果允许在客户进程中加载，就直接返回了这个Content Provider的信息了：

[java] view plaincopy

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设置了要在独立的进程中运行，因此，继续往下执行：

[java] view plaincopy

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，继续往前执行：

[java] view plaincopy

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.     ProcessRecord proc = startProcessLocked(cpi.processName,  
6.         cpr.appInfo, false, 0, "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的过程，继续往下执行：

[java] view plaincopy

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是在新的进程中加载完成的：

[java] view plaincopy

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，这里就不再详细描述了。

         Step 13. ActivityManagerService.attachApplicationLocked

         这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityManagerService.java文件中：

[java] view plaincopy

1. public final class ActivityManagerService extends ActivityManagerNative  
2.         implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback {  
3.     ......  
4.   
5.     private final boolean attachApplicationLocked(IApplicationThread thread,  
6.             int pid) {  
7.         // Find the application record that is being attached...  either via  
8.         // the pid if we are running in multiple processes, or just pull the  
9.         // next app record if we are emulating process with anonymous threads.  
10.         ProcessRecord app;  
11.         if (pid != MY_PID && pid >= 0) {  
12.             synchronized (mPidsSelfLocked) {  
13.                 app = mPidsSelfLocked.get(pid);  
14.             }  
15.         } else if (mStartingProcesses.size() > 0) {  
16.             ......  
17.         } else {  
18.             ......  
19.         }  
20.   
21.         ......  
22.   
23.         app.thread = thread;  
24.         app.curAdj = app.setAdj = -100;  
25.         app.curSchedGroup = Process.THREAD_GROUP_DEFAULT;  
26.         app.setSchedGroup = Process.THREAD_GROUP_BG_NONINTERACTIVE;  
27.         app.forcingToForeground = null;  
28.         app.foregroundServices = false;  
29.         app.debugging = false;  
30.   
31.         ......  
32.   
33.         boolean normalMode = mProcessesReady || isAllowedWhileBooting(app.info);  
34.         List providers = normalMode ? generateApplicationProvidersLocked(app) : null;  
35.   
36.         try {  
37.             ......  
38.   
39.             thread.bindApplication(processName, app.instrumentationInfo != null  
40.                 ? app.instrumentationInfo : app.info, providers,  
41.                 app.instrumentationClass, app.instrumentationProfileFile,  
42.                 app.instrumentationArguments, app.instrumentationWatcher, testMode,  
43.                 isRestrictedBackupMode || !normalMode,  
44.                 mConfiguration, getCommonServicesLocked());  
45.   
46.             ......  
47.         } catch (Exception e) {  
48.             ......  
49.         }  
50.   
51.         ......  
52.           
53.         return true;  
54.     }  
55.   
56.     ......  
57.   
58.     private final List generateApplicationProvidersLocked(ProcessRecord app) {  
59.         List providers = null;  
60.         try {  
61.             providers = AppGlobals.getPackageManager().  
62.                 queryContentProviders(app.processName, app.info.uid,  
63.                 STOCK_PM_FLAGS | PackageManager.GET_URI_PERMISSION_PATTERNS);  
64.         } catch (RemoteException ex) {  
65.         }  
66.         if (providers != null) {  
67.             final int N = providers.size();  
68.             for (int i=0; i<N; i++) {  
69.                 ProviderInfo cpi =  
70.                     (ProviderInfo)providers.get(i);  
71.                 ContentProviderRecord cpr = mProvidersByClass.get(cpi.name);  
72.                 if (cpr == null) {  
73.                     cpr = new ContentProviderRecord(cpi, app.info);  
74.                     mProvidersByClass.put(cpi.name, cpr);  
75.                 }  
76.                 app.pubProviders.put(cpi.name, cpr);  
77.                 app.addPackage(cpi.applicationInfo.packageName);  
78.                 ensurePackageDexOpt(cpi.applicationInfo.packageName);  
79.             }  
80.         }  
81.         return providers;  
82.     }  
83.   
84.     ......  
85. }  

        这个函数首先是根据传进来的进程ID找到相应的进程记录块，注意，这个进程ID是应用程序ArticlesProvider的ID，然后对这个进程记录 块做一些初倾始化的工作。再接下来通过调用generateApplicationProvidersLocked获得需要在这个过程中加载的 Content Provider列表，在我们这个情景中，就只有ArticlesProvider这个Content Provider了。最后调用从参数传进来的IApplicationThread对象thread的bindApplication函数来执行一些应用 程序初始化工作。从Android应用程序启动过程源代码分析一 文中我们知道，在Android系统中，每一个应用程序进程都加载了一个ActivityThread实例，在这个ActivityThread实例里 面，有一个成员变量mAppThread，它是一个Binder对象，类型为ApplicationThread，实现了 IApplicationThread接口，它是专门用来和ActivityManagerService服务进行通信的。因此，调用下面语句：

[java] view plaincopy

1. thread.bindApplication(processName, app.instrumentationInfo != null  
2.     ? app.instrumentationInfo : app.info, providers,  
3.     app.instrumentationClass, app.instrumentationProfileFile,  
4.     app.instrumentationArguments, app.instrumentationWatcher, testMode,  
5.     isRestrictedBackupMode || !normalMode,  
6.     mConfiguration, getCommonServicesLocked());  

        就会进入到应用程序ArticlesProvider进程中的ApplicationThread对象的bindApplication函数中去。在我们这个情景场，这个函数调用中最重要的参数便是第三个参数providers了，它是我们要处理的对象。

        Step 14. ApplicationThread.bindApplication

        这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件中：

[java] view plaincopy

1. public final class ActivityThread {  
2.     ......  
3.   
4.     private final class ApplicationThread extends ApplicationThreadNative {  
5.         ......  
6.   
7.         public final void bindApplication(String processName,  
8.                 ApplicationInfo appInfo, List<ProviderInfo> providers,  
9.                 ComponentName instrumentationName, String profileFile,  
10.                 Bundle instrumentationArgs, IInstrumentationWatcher instrumentationWatcher,  
11.                 int debugMode, boolean isRestrictedBackupMode, Configuration config,  
12.                 Map<String, IBinder> services) {  
13.             if (services != null) {  
14.                 // Setup the service cache in the ServiceManager  
15.                 ServiceManager.initServiceCache(services);  
16.             }  
17.   
18.             AppBindData data = new AppBindData();  
19.             data.processName = processName;  
20.             data.appInfo = appInfo;  
21.             data.providers = providers;  
22.             data.instrumentationName = instrumentationName;  
23.             data.profileFile = profileFile;  
24.             data.instrumentationArgs = instrumentationArgs;  
25.             data.instrumentationWatcher = instrumentationWatcher;  
26.             data.debugMode = debugMode;  
27.             data.restrictedBackupMode = isRestrictedBackupMode;  
28.             data.config = config;  
29.             queueOrSendMessage(H.BIND_APPLICATION, data);  
30.         }  
31.   
32.         ......  
33.     }  
34.   
35.     ......  
36. }  

         这个函数把相关的信息都封装成一个AppBindData对象，然后以一个消息的形式发送到主线程的消息队列中去等等待处理。这个消息最终是是在ActivityThread类的handleBindApplication函数中进行处理的。

         Step 15. ActivityThread.handleBindApplication

         这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件中：

[java] view plaincopy

1. public final class ActivityThread {  
2.     ......  
3.       
4.     private final void handleBindApplication(AppBindData data) {  
5.         ......  
6.   
7.         List<ProviderInfo> providers = data.providers;  
8.         if (providers != null) {  
9.             installContentProviders(app, providers);  
10.             ......  
11.         }  
12.   
13.         ......  
14.     }  
15.   
16.     ......  
17. }  

         这个函数的内容比较多，我们忽略了其它无关的部分，只关注和Content Provider有关的逻辑，这里主要就是调用installContentProviders函数来在本地安装Content Providers信息。

         Step 16. ActivityThread.installContentProviders

         这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件中：

[java] view plaincopy

1. public final class ActivityThread {  
2.     ......  
3.       
4.     private final void installContentProviders(  
5.             Context context, List<ProviderInfo> providers) {  
6.         final ArrayList<IActivityManager.ContentProviderHolder> results =  
7.             new ArrayList<IActivityManager.ContentProviderHolder>();  
8.   
9.         Iterator<ProviderInfo> i = providers.iterator();  
10.         while (i.hasNext()) {  
11.             ProviderInfo cpi = i.next();  
12.             StringBuilder buf = new StringBuilder(128);  
13.             buf.append("Pub ");  
14.             buf.append(cpi.authority);  
15.             buf.append(": ");  
16.             buf.append(cpi.name);  
17.             Log.i(TAG, buf.toString());  
18.             IContentProvider cp = installProvider(context, null, cpi, false);  
19.             if (cp != null) {  
20.                 IActivityManager.ContentProviderHolder cph =  
21.                     new IActivityManager.ContentProviderHolder(cpi);  
22.                 cph.provider = cp;  
23.                 results.add(cph);  
24.                 // Don‘t ever unload this provider from the process.  
25.                 synchronized(mProviderMap) {  
26.                     mProviderRefCountMap.put(cp.asBinder(), new ProviderRefCount(10000));  
27.                 }  
28.             }  
29.         }  
30.   
31.         try {  
32.             ActivityManagerNative.getDefault().publishContentProviders(  
33.                 getApplicationThread(), results);  
34.         } catch (RemoteException ex) {  
35.         }  
36.     }  
37.   
38.     ......  
39. }  

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

        Step 17. ActivityThread.installProvider

        这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件中：

[java] view plaincopy

1. public final class ActivityThread {  
2.     ......  
3.       
4.     private final IContentProvider installProvider(Context context,  
5.             IContentProvider provider, ProviderInfo info, boolean noisy) {  
6.         ContentProvider localProvider = null;  
7.         if (provider == null) {  
8.             ......  
9.   
10.             Context c = null;  
11.             ApplicationInfo ai = info.applicationInfo;  
12.             if (context.getPackageName().equals(ai.packageName)) {  
13.                 c = context;  
14.             } else if (mInitialApplication != null &&  
15.                 mInitialApplication.getPackageName().equals(ai.packageName)) {  
16.                     c = mInitialApplication;  
17.             } else {  
18.                 try {  
19.                     c = context.createPackageContext(ai.packageName,  
20.                         Context.CONTEXT_INCLUDE_CODE);  
21.                 } catch (PackageManager.NameNotFoundException e) {  
22.                 }  
23.             }  
24.   
25.             ......  
26.   
27.             try {  
28.                 final java.lang.ClassLoader cl = c.getClassLoader();  
29.                 localProvider = (ContentProvider)cl.  
30.                     loadClass(info.name).newInstance();  
31.                 provider = localProvider.getIContentProvider();  
32.                 ......  
33.   
34.                 // XXX Need to create the correct context for this provider.  
35.                 localProvider.attachInfo(c, info);  
36.             } catch (java.lang.Exception e) {  
37.                 ......  
38.             }  
39.   
40.         } else if (localLOGV) {  
41.             ......  
42.         }  
43.   
44.         synchronized (mProviderMap) {  
45.             // Cache the pointer for the remote provider.  
46.             String names[] = PATTERN_SEMICOLON.split(info.authority);  
47.             for (int i=0; i<names.length; i++) {  
48.                 ProviderClientRecord pr = new ProviderClientRecord(names[i], provider,  
49.                     localProvider);  
50.                 try {  
51.                     provider.asBinder().linkToDeath(pr, 0);  
52.                     mProviderMap.put(names[i], pr);  
53.                 } catch (RemoteException e) {  
54.                     return null;  
55.                 }  
56.             }  
57.             if (localProvider != null) {  
58.                 mLocalProviders.put(provider.asBinder(),  
59.                     new ProviderClientRecord(null, provider, localProvider));  
60.             }  
61.         }  
62.   
63.         return provider;  
64.     }  
65.   
66.     ......  
67. }  

         这个函数的作用主要就是在应用程序进程中把相应的Content Provider类加载进来了，在我们这个种情景中，就是要在ArticlesProvider这个应用程序中把ArticlesProvider这个 Content Provider类加载到内存中来了：

[java] view plaincopy

1. final java.lang.ClassLoader cl = c.getClassLoader();  
2. localProvider = (ContentProvider)cl.  
3.     loadClass(info.name).newInstance();  

         接着通过调用localProvider的getIContentProvider函数来获得一个Binder对象，这个Binder对象返回给 installContentProviders函数之后，就会传到ActivityManagerService中去，后续其它应用程序就是通过获得这 个Binder对象来和相应的Content Provider进行通信的了。我们先看一下这个函数的实现，然后再回到installProvider函数中继续分析。

         Step 18. ContentProvider.getIContentProvider

         这个函数定义在frameworks/base/core/java/android/content/ContentProvider.java文件中：

[java] view plaincopy

1. public abstract class ContentProvider implements ComponentCallbacks {  
2.     ......  
3.   
4.     private Transport mTransport = new Transport();  
5.   
6.     ......  
7.   
8.     class Transport extends ContentProviderNative {  
9.         ......  
10.     }  
11.   
12.     public IContentProvider getIContentProvider() {  
13.         return mTransport;  
14.     }  
15.   
16.     ......  
17. }  

        从这里我们可以看出，ContentProvider类和Transport类的关系就类似于ActivityThread和 ApplicationThread的关系，其它应用程序不是直接调用ContentProvider接口来访问它的数据，而是通过调用它的内部对象 mTransport来间接调用ContentProvider的接口，这一点我们在下一篇文章中分析调用Content Provider接口来获取共享数据时将会看到。
        回到前面的installProvider函数中，它接下来调用下面接口来初始化刚刚加载好的Content Provider：

[java] view plaincopy

1. // XXX Need to create the correct context for this provider.  
2. localProvider.attachInfo(c, info);  

        同样，我们先进入到ContentProvider类的attachInfo函数去看看它的实现，然后再回到installProvider函数来。

        Step 19. ContentProvider.attachInfo

        这个函数定义在frameworks/base/core/java/android/content/ContentProvider.java文件中：

[java] view plaincopy

1. public abstract class ContentProvider implements ComponentCallbacks {  
2.     ......  
3.   
4.     public void attachInfo(Context context, ProviderInfo info) {  
5.         /* 
6.         * Only allow it to be set once, so after the content service gives 
7.         * this to us clients can‘t change it. 
8.         */  
9.         if (mContext == null) {  
10.             mContext = context;  
11.             mMyUid = Process.myUid();  
12.             if (info != null) {  
13.                 setReadPermission(info.readPermission);  
14.                 setWritePermission(info.writePermission);  
15.                 setPathPermissions(info.pathPermissions);  
16.                 mExported = info.exported;  
17.             }  
18.             ContentProvider.this.onCreate();  
19.         }  
20.     }  
21.   
22.     ......  
23. }  

        这个函数很简单，主要就是根据这个Content Provider的信息info来设置相应的读写权限，然后调用它的子类的onCreate函数来让子类执行一些初始化的工作。在我们这个情景中，这个子 类就是ArticlesProvide应用程序中的ArticlesProvider类了。

        Step 20. ArticlesProvider.onCreate

        这个函数定义在前面一篇文章Android应用程序组件Content Provider应用实例介 绍的应用程序ArtilcesProvider源代码工程目录下，在文件为packages/experimental /ArticlesProvider/src/shy/luo/providers/articles/ArticlesProvider.java中：

[java] view plaincopy

1. public class ArticlesProvider extends ContentProvider {  
2.     ......  
3.   
4.     @Override  
5.     public boolean onCreate() {  
6.         Context context = getContext();  
7.         resolver = context.getContentResolver();  
8.         dbHelper = new DBHelper(context, DB_NAME, null, DB_VERSION);  
9.   
10.         return true;  
11.     }  
12.   
13.     ......  
14. }  

        这个函数主要执行一些简单的工作，例如，获得应用程序上下文的ContentResolver接口和创建数据库操作辅助对象，具体可以参考前面一篇文章Android应用程序组件Content Provider应用实例。

        回到前面Step 17中的installProvider函数中，它接下来就是把这些在本地中加载的Content Provider信息保存下来了，以方便后面查询和使用：

[java] view plaincopy

1. synchronized (mProviderMap) {  
2.     // Cache the pointer for the remote provider.  
3.     String names[] = PATTERN_SEMICOLON.split(info.authority);  
4.     for (int i=0; i<names.length; i++) {  
5.     ProviderClientRecord pr = new ProviderClientRecord(names[i], provider,  
6.         localProvider);  
7.     try {  
8.         provider.asBinder().linkToDeath(pr, 0);  
9.         mProviderMap.put(names[i], pr);  
10.     } catch (RemoteException e) {  
11.         return null;  
12.     }  
13.     }  
14.     if (localProvider != null) {  
15.     mLocalProviders.put(provider.asBinder(),  
16.         new ProviderClientRecord(null, provider, localProvider));  
17.     }  
18. }  

        和ActivityMangerService类似，在ActivityThread中，以Content Provider的authority为键值来把这个Content Provider的信息保存在mProviderMap成员变量中，因为一个Content Provider可以对应多个authority，因此这里用一个for循环来处理，同时又以这个Content Provider对应的Binder对象provider来键值来把这个Content Provider的信息保存在mLocalProviders成员变量中，表明这是一个在本地加载的Content Provider。

        函数installProvider执行完成以后，返回到Step 16中的instalContentProviders函数中，执行下面语句：

[java] view plaincopy

1. try {  
2.     ActivityManagerNative.getDefault().publishContentProviders(  
3.         getApplicationThread(), results);  
4. } catch (RemoteException ex) {  
5. }  

        前面已经提到，这个函数调用的作用就是通知ActivityMangerService，需要在这个进程中加载的Content Provider已经完加载完成了，参数results就包含了这些已经加载好的Content Provider接口。

        Step 21. ActivityMangerService.publishContentProviders

        这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityManagerService.java文件中：

[java] view plaincopy

1. public final class ActivityManagerService extends ActivityManagerNative  
2.         implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback {  
3.     ......  
4.   
5.     public final void publishContentProviders(IApplicationThread caller,  
6.             List<ContentProviderHolder> providers) {  
7.         ......  
8.   
9.         synchronized(this) {  
10.             final ProcessRecord r = getRecordForAppLocked(caller);  
11.             ......  
12.   
13.             final int N = providers.size();  
14.             for (int i=0; i<N; i++) {  
15.                 ContentProviderHolder src = providers.get(i);  
16.                 if (src == null || src.info == null || src.provider == null) {  
17.                     continue;  
18.                 }  
19.                 ContentProviderRecord dst = r.pubProviders.get(src.info.name);  
20.                 if (dst != null) {  
21.                     mProvidersByClass.put(dst.info.name, dst);  
22.                     String names[] = dst.info.authority.split(";");  
23.                     for (int j = 0; j < names.length; j++) {  
24.                         mProvidersByName.put(names[j], dst);  
25.                     }  
26.   
27.                     int NL = mLaunchingProviders.size();  
28.                     int j;  
29.                     for (j=0; j<NL; j++) {  
30.                         if (mLaunchingProviders.get(j) == dst) {  
31.                             mLaunchingProviders.remove(j);  
32.                             j--;  
33.                             NL--;  
34.                         }  
35.                     }  
36.                     synchronized (dst) {  
37.                         dst.provider = src.provider;  
38.                         dst.app = r;  
39.                         dst.notifyAll();  
40.                     }  
41.                     ......  
42.                 }  
43.             }  
44.         }  
45.     }  
46.   
47.     ......  
48. }  

         在我们这个情景中，只有一个Content Provider，因此，这里的N等待1。在中间的for循环里面，最重要的是下面这个语句：

[java] view plaincopy

1. ContentProviderRecord dst = r.pubProviders.get(src.info.name);  

         从这里得到的ContentProviderRecord对象dst，就是在前面Step 7中创建的ContentProviderRecord对象cpr了。在for循环中，首先是把这个Content Provider信息保存好在mProvidersByClass和mProvidersByName中：

[java] view plaincopy

1. mProvidersByClass.put(dst.info.name, dst);  
2. String names[] = dst.info.authority.split(";");  
3. for (int j = 0; j < names.length; j++) {  
4.     mProvidersByName.put(names[j], dst);  
5. }  

        前面已经说过，这两个Map中，一个是以类名为键值保存Content Provider信息，一个是以authority为键值保存Content Provider信息。

        因为这个Content Provider已经加载好了，因此，把它从mLaunchingProviders列表中删除：

[java] view plaincopy

1. int NL = mLaunchingProviders.size();  
2. int j;  
3. for (j=0; j<NL; j++) {  
4.     if (mLaunchingProviders.get(j) == dst) {  
5.         mLaunchingProviders.remove(j);  
6.         j--;  
7.         NL--;  
8.     }  
9. }  

        最后，设置这个ContentProviderRecord对象dst的provider域为从参数传进来的Content Provider远程接口：

[java] view plaincopy

1. synchronized (dst) {  
2.     dst.provider = src.provider;  
3.     dst.app = r;  
4.     dst.notifyAll();  
5. }  

        执行了dst.notiryAll语句后，在Step 7中等待要获取的Content Provider接口加载完毕的线程就被唤醒了。唤醒之后，它检查本地ContentProviderRecord变量cpr的provider域不为 null，于是就返回了。它最终返回到Step 5中的ActivityThread类的getProvider函数中，继续往下执行：

[java] view plaincopy

1. IContentProvider prov = installProvider(context, holder.provider,  
2.     holder.info, true);  

        注意，这里是在Article应用程序中进程中执行installProvider函数的，而前面的Step 17的installProvider函数是在ArticlesProvider应用程序进程中执行的。

        Step 22. ActivityThread.installProvider

        这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件中：

[java] view plaincopy

1. public final class ActivityThread {  
2.     ......  
3.       
4.     private final IContentProvider installProvider(Context context,  
5.             IContentProvider provider, ProviderInfo info, boolean noisy) {  
6.         ......  
7.         if (provider == null) {  
8.             ......  
9.         } else if (localLOGV) {  
10.             ......  
11.         }  
12.   
13.         synchronized (mProviderMap) {  
14.             // Cache the pointer for the remote provider.  
15.             String names[] = PATTERN_SEMICOLON.split(info.authority);  
16.             for (int i=0; i<names.length; i++) {  
17.                 ProviderClientRecord pr = new ProviderClientRecord(names[i], provider,  
18.                     localProvider);  
19.                 try {  
20.                     provider.asBinder().linkToDeath(pr, 0);  
21.                     mProviderMap.put(names[i], pr);  
22.                 } catch (RemoteException e) {  
23.                     return null;  
24.                 }  
25.             }  
26.             ......  
27.         }  
28.   
29.         return provider;  
30.     }  
31.   
32.     ......  
33. }  

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

        这样，获取与"shy.luo.providers.artilces"这个uri对应的Content Provider（shy.luo.providers.articles.ArticlesProvider）就完成了，它同时也是启动Content Provider的完整过程。第三方应用程序获得了这个Content Provider的接口之后，就可以访问它里面的共享数据了。在下面一篇文章中，我们将重点分析Android应用程序组件Content Provider在不同进程中传输数据的过程，即Content Provider在不同应用程序中共享数据的原理，敬请关注。

老罗的新浪微博：http://weibo.com/shengyangluo，欢迎关注！

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

标签：android   style   blog   http   io   ar   color   os   使用   

原文地址：http://www.cnblogs.com/Free-Thinker/p/4142577.html