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

通过前面的学习，我们知道在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中：

public class ArticlesAdapter {
......
private ContentResolver resolver = null;
public ArticlesAdapter(Context context) {
resolver = context.getContentResolver();
}
......
public int getArticleCount() {
int count = 0;
try {
IContentProvider provider = resolver.acquireProvider(Articles.CONTENT_URI);
Bundle bundle = provider.call(Articles.METHOD_GET_ITEM_COUNT, null, null);
count = bundle.getInt(Articles.KEY_ITEM_COUNT, 0);
} catch(RemoteException e) {
e.printStackTrace();
}
return count;
}
......
}

这个函数通过应用程序上下文的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文件中：

public abstract class ContentResolver {
......
public final IContentProvider acquireProvider(Uri uri) {
if (!SCHEME_CONTENT.equals(uri.getScheme())) {
return null;
}
String auth = uri.getAuthority();
if (auth != null) {
return acquireProvider(mContext, uri.getAuthority());
}
return null;
}
......
}

函数首先验证参数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文件中：

class ContextImpl extends Context {
......
private ApplicationContentResolver mContentResolver;
......
final void init(LoadedApk packageInfo,
IBinder activityToken, ActivityThread mainThread,
Resources container) {
......
mContentResolver = new ApplicationContentResolver(this, mainThread);
......
}
......
@Override
public ContentResolver getContentResolver() {
return mContentResolver;
}
......
}

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

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

Step 3. ApplicationContentResolve.acquireProvider

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

class ContextImpl extends Context {
......
private static final class ApplicationContentResolver extends ContentResolver {
......
@Override
protected IContentProvider acquireProvider(Context context, String name) {
return mMainThread.acquireProvider(context, name);
}
......
private final ActivityThread mMainThread;
}
......
}

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

Step 4. ActivityThread.acquireProvider

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

public final class ActivityThread {
......
public final IContentProvider acquireProvider(Context c, String name) {
IContentProvider provider = getProvider(c, name);
if(provider == null)
return null;
......
return provider;
}
......
}

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

Android应用程序组件Content Provider的启动过程源代码分析（1）相关推荐

Android应用程序组件Content Provider的启动过程源代码分析（6）
Step 17. ActivityThread.installProvider 这个函数定义在frameworks/base/core/java/android/app/Act ...
Android应用程序组件Content Provider的共享数据更新通知机制分析
在Android系统中,应用程序组件Content Provider为不同的应用程序实现数据共享提供了基础设施,它主要通过Binder进程间通信机制和匿名共享内存机制来实现的.关于数据共享的另一个话 ...
Android应用程序组件Content Provider在应用程序之间共享数据的原理分析（1）
在Android系统中,不同的应用程序是不能直接读写对方的数据文件的,如果它们想共享数据的话,只能通过Content Provider组件来实现.那么,Content Provide ...
Android应用程序组件Content Provider的共享数据更新通知机制分析（3）
3. 数据更新通知的发送过程在前面这篇文章Android应用程序组件Content Provider应用实例介绍的应用程序Acticle中,当调用ArticlesAda ...
Android系统默认Home应用程序（Launcher）的启动过程源代码分析
在前面一篇文章中,我们分析了Android系统在启动时安装应用程序的过程,这些应用程序安装好之后,还需要有一个Home应用程序来负责把它们在桌面上展示出来,在Android系统中,这个默认的Home应 ...
Android系统默认Home应用程序（Launcher）的启动过程源代码分析（3）
Step 13. ActivityStack.startActivityLocked 这个函数定义在frameworks/base/services/java/com/android/server/ ...
Android应用程序组件Content Provider简要介绍和学习计划
在Android系统中,Content Provider作为应用程序四大组件之一,它起到在应用程序之间共享数据的作用,同时,它还是标准的数据访问接口.前面的一系列文章已经分析过Android应用程序的 ...
Android应用程序组件Content Provider在应用程序之间共享数据的原理分析（2）
Step 7. ContentProviderProxy.query 这个函数定义在frameworks/base/core/java/android/content/Conten ...
Android系统默认Home应用程序（Launcher）的启动过程源代码分析（2）
Step 10. ActivityManagerService.systemReady 这个函数是在上面的Step 6中的ServerThread.run函数在将系统中的一系列服务都初始化完毕之后才 ...

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

Android应用程序组件Content Provider的启动过程源代码分析（1）相关推荐

最新文章

热门文章