ContentProvider内部机制

1．ContentProvider接口调用过程

    ContentProvider依赖ContentResolver/ActivityThread/ActivityManagerService对外提供服务。虽然ContentProvider的用法以及表现形式不是一个Service，实际上它可以看作是ActivityManagerService提供的一种服务, 它实现了IBinder接口。

    首先调用者通过特定uri调用特定ContentProvider的接口函数，比如insert(),  此时ContentResolver会通过uri获取特定ContentProvider的实例，ActivityThread检查本地Cache，如果发现此ContentProvider已经被引用过，则直接直接取出ContentProvider返回给调用者。如果没有发现，由于 ContentProvider可能已经被load了，可能还没有load；可能要创建Process，可能要检查permission，所以ActivityThread调用到ActivityManagerService来进行相关处理/检查。如果该Provider是Single Process，ActivityManagerService会为ContentProvider创建一个独立Process；如果是MultiProcess，说明每个调用者可以拥有独立的ContentProvider实例，于是ActivityManagerService只是返回ContentProvider的相关信息给ActivityThread，由ActivityThread负责ContentProvider的实例化，此时ContentProvider运行在调用者Process中。实例化后，IConentProvider会返回给调用者，通过该接口可以调用所需功能。

    ActivityThread本地维护一个mProviderMap <ProviderName, ProviderRecord >，记录已被引用的ContentProvider,  同时使用引用计数mProviderRefCountMap <IBinder, ProviderRefCount>记录特定ContentProvider的引用情况

2．ContentProvider实例创建过程

     ContentProvider实例的创建与multiprocess属性有关系(Androidmanifest.xml里指定），个人认为理解成多进程并不准确。应该理解为ContentProvider的多实例，不会存在多个ContentProvider进程的情况，ContentProvider 可能存在多个实例。