通过前面的学习,我们知道在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中:
  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, nullnull);  
  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文件中:
  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文件中:
  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文件中:
  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文件中:
  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接口的操作。