第八篇 android 内容提供组件机制 .

       内容提供组件提供了一个进程安全访问另一个进程数据的方法和接口，该接口对数据进行了封装，使客户端可以以一致的接口跨进程访问各种数据。

       如下是ContentProvider的系统类图：

      

 

 

      

       图中左边部分是客户端部分，右边部分是处于另外进程的ContentProvider组件和内容提供的服务部分。整个系统采用的模式与MVC模式类似。

       客户端主要的类是ContentResolver和ContentObserver，客户端通过ContentResolver类提供的接口与ContentProvider组件和内容提供服务进行跨进程访问，如数据的查询，数据的CRUD(create, retrieve, update, and delete)操作，数据监控对象的登记、数据的同步等操作，ContentResolver相当于MVC模式的控制器部分。

            ContentResolver是一个抽象接口，ContentResolver的具体类由ContextImpl对象进行实例化。客户端通过ContentResolver根据标识ContentProvider的 content URL（一个 content URL包括对应Provider的authoriry名称和对应表和行的部分的 path名称）找到要访问的ContentProvider对应的BINDER引用，然后通过ContentProviderProxy采用远程代理方式访问Provider。

             ContentObserver是作为数据观察用的一个抽象类，ContentObserver内部封装了一个Transport 桩类，提供了跨进程访问的能力，一个ContentObserver对象可以通过ContentResolver登记到ContentService中，一个ContentObserver对象根据标识Provider数据的 content URI以树的形式登记到ContentService中；也可以以ContentObserver数组形式登记到光标对象中，在光标变化时得到通知。ContentObserver对象相当于MVC模式的视图，在数据变化时每一个登记的ContentObserver对象都会得到通知。

         右边部分的ContentService和ContentProvider类相当于MVC模式的模式部分。

              ContentService是一个由框架的SystemServer服务启动的系统服务类，实现ContentObserver对象的登记和更新通知及数据同步等功能。

              ContentProvider类是实现内容提供组件的最重要的一个类，本身是一个抽象类，提供其它应用进行跨进程访问数据的一个接口，其它应用通过该接口访问内容提供组件封装的数据。

         内容提供组件开发者必须实现ContentProvider类的具体类，用来封装要对其它应用公开的数据，通过内容提供组件提供和封装的数据可以是数据库、数组之类的结构化数据，也可以文件，甚至是云端数据。内容提供组件使用统一资源标示符（URI ）标示每一个ContentProvider及         其提供的数据。ContentProvider类内部也提供一个Transport 桩类，提供了能够被其它应用跨进程访问的能力。

         每一个ContentProvider组件在第一次获取时被加载到内存,同时以ContentProviderRecord的形式被保存到活动管理服务中的两个HashMap中，一个HashMap以Content Provider的authoriry名称作为键值保存，另外一个以Content Provider的类名作为键值来保存。同时也以ProviderClientRecord的形式保存到获取ContentProvider组件的应用程序进程(ActivityRecord)中的两个HashMap中,一个也以Content Provider的authoriry名称作为键值保存，另一个以Content Provider对应的Binder对象作为键值来保存，在下次获取相同Provider时可以通过getExistingProvider函数从这两个HashMap中直接获得。

         内容提供组件通过Cursor接口返回查询后的数据。Cursor对应表格形式的数据，Cursor类相当于一个包含多个数据行的列表类，提供了以行和列随机存取ContentProvider封装数据的方式，通过Cursor类可以遍历每一行的数据，还可以访问每一行的每一列的内容。

         如下是Content Provider组件使用到的光标类图。

         

                整个类图采用了装饰模式、适配器模式、观察者模式等设计模式。

             客户端通过ContentResolver的query函数返回的光标对象为CursorWrapperInner类型，CursorWrapperInner是ContentResolver通过ContentProviderProxy代理调用query函数返回的BulkCursorToCursorAdaptor类型光标对象的包装，采用了装饰模式。

          具体ContentProvider的query函数返回的光标类型是与具体封装的数据对应的，对于数据库查询使用的是SQLiteCursor类型，如CalendarProvider、ContactsProvider等；数组类型使用的光标类型是MatrixCursor，如gallery3d应用的GalleryProvider采用就是MatrixCursor类型的光标。光标类型本身不是Binder对象，不能跨进程调用，因此为了客户端能够跨进程调用光标函数， ContentProvider内部的本地STUB对象在调用具体ContentProvider的query函数返回时，对返回的实际光标对象采用CursorToBulkCursorAdaptor对象采用了适配器模式进行了包装，CursorToBulkCursorAdaptor通过BulkCursorNative类继承自Binder，因此是一个Binder对象，因此客户端可以跨进程访问该对象。具体ContentProvider的query函数返回的光标对象作为CursorToBulkCursorAdaptor的一个成员，对CursorToBulkCursorAdaptor对象的调用实际都转给具体的光标对象处理。

        在ContentProviderProxy代理端，BulkCursorToCursorAdaptor对象又对ContentProvider的本地STUB对象返回的CursorToBulkCursorAdaptor对象采用适配器模式进行了包装，CursorToBulkCursorAdaptor对象作为BulkCursorToCursorAdaptor对象成员，对BulkCursorToCursorAdaptor对象的函数访问都转给CursorToBulkCursorAdaptor对象的相同函数处理。

       在通过ContentProviderProxy代理进行query函数调用时，也把BulkCursorToCursorAdaptor对象的一个内部SelfContentObserver对象通过BINDER调用传给ContentProvider的本地端，ContentProvider的本地端在CursorToBulkCursorAdaptor封装光标时也把该SelfContentObserver对象登记到具体光标对象中，因此当光标发生变化时SelfContentObserver对象得到通知，再通过SelfContentObserver对象通知在客户端的光标对象中登记的其它ContentObserver对象。这是观察者设计模式的采用。

          下图是客户端对Provider进行一次查询的序列图。

         

    

    1）客户端应用通过getContentResolver函数获得ContentResolver对象，向该对象发起QUERY请求，ContentResolver对象首先调用acquireProvider函数获得一个Provider，函数acquireProvider实际调用ContentResolver具体类ApplicationContentResolver的acquireProvider函数；

     2）ApplicationContentResolver的acquireProvider函数通过其内部ActivityThread对象转而调用ActivityThread对象的acquireProvider函数；

     3）ActivityThread的acquireProvider函数首先调用acquireExistingProvider函数，在本对象的mProviderMap HashMap中根据要获取的Provider的authoriry名称（从Provider的URL中获得）查找要获取的Provider的是否已经存在，如果已经存在，增加Provider的引用计数，返回获得的Provider；

     4）否则调用ActivityManagerService 服务的getContentProvider函数在ActivityManagerService 服务中查找登记的ContentProvider。getContentProvider函数实际调用getContentProviderImpl函数，getContentProviderImpl函数首先在ActivityManagerService 服务的mProvidersByName HashMap中根据要获取的Provider的authoriry名称查找Provider是否已经存在；如果已经存在，判断是否对该Provider有许可权限；如果有许可权线，则判断Provider是否能够在客户端进程运行；若允许则根据找到的ContentProviderRecord对象克隆一个ContentProviderRecord后返回，否则直接返回找到的ContentProviderRecord；如果在mProvidersByName 的HashMap中没有找到则需要根据包管理器的resolveContentProvider函数获得Provider的包信息；获得Provider的包信息后根据包名从mProvidersByClass的HashMap中查找；如果在mProvidersByClass的HashMap中没有找到则重新实例化一个新的ContentProviderRecord；然后判断Provider是否可以在客户端进程运行，是则返回；否则则启动新的进程加载该Provider；加载后把Provide添加到mProvidersByName和mProvidersByClass两个HashMap中，返回ContentProviderRecord；

     5）ActivityThread的acquireProvider函数继续调用installProvider在本地mProviderMap和mLocalProviders两个HashMap中添加ProviderClientRecord记录，一个以authoriry名称为键值，另一个以Provider对应的Binder对象为键值；并增加该Provider的引用计数，把该Provider的引用计数以Provider对应的Binder对象为键值添加到mProviderRefCountMap中；ActivityThread的acquireProvider函数最后返回Provider对应的Binder对象；

     6）获得Provider后ContentResolver对象接着调用ContentProviderProxy代理的query函数；

     7）ContentProviderProxy代理的query函数中首先实例化一个BulkCursorToCursorAdaptor对象。然后对参数进行序列化，在序列化时也把BulkCursorToCursorAdaptor对象中的SelfContentObserver对象作为参数进行序列化，对参数进行序列化后通过ContentProvider本地引用向ContentProvide本地桩发起transact请求；

     8）ContentProvide本地桩在onTransact中处理binder请求，对于QUERY_TRANSACTION请求，先反序列化BINDER参数后，调用具体ContentProvider对象的query函数；

     9）调用具体ContentProvider对象的query函数后，先实例化一个具有远程通讯能力的CursorToBulkCursorAdaptor对象，CursorToBulkCursorAdaptor对象对返回的具体Cursor对象进行包装。在CursorToBulkCursorAdaptor对象中也根据transact请求传进来的SelfContentObserver对象的引用构造一个代理对象登记到具体光标对象中；在CursorToBulkCursorAdaptor实例化后接着通过CursorToBulkCursorAdaptor对象发起一次读取数据记录数的调用，然后把读取的数据记录数及CursorToBulkCursorAdaptor作为binder对象序列化到返回参数中，请求处理完成返回；

     10）ContentProviderProxy代理对象在transact请求返回后读取返回的参数，根据返回的参数初始化BulkCursorToCursorAdaptor对象，把返回的CursorToBulkCursorAdaptor类型的 binder对象引用及读取的数据记录数等参数保存到BulkCursorToCursorAdaptor对象中，返回初始化的BulkCursorToCursorAdaptor对象；

     11）ContentResolver发起query请求返回后根据返回的BulkCursorToCursorAdaptor对象实例化一个CursorWrapperInner对象，对BulkCursorToCursorAdaptor对象进行包装，返回包装后CursorWrapperInner对象给应用，query调用完成。

     下图是客户端登记ContentObserver和发出数据变化通知的流程。

    

 

     1）            客户端应用通过getContentResolver函数获得ContentResolver对象，向该对象发起registerContentObserver调用；

     2）            在registerContentObserver函数中通过getContentService接口获得ContentService对象的远端代理引用，通过ContentService的远端代理引用向ContentService服务发起registerContentObserver远程调用；

     3）            在ContentService服务的registerContentObserver函数中首先调用mRootNode对象的addObserverLocked函数把ContentObserver对象以ObserverEntry记录的形式登记到ObserverNode树（根据Provider的URI 构造）中，登记完成。

     4）            客户端应用通过getContentResolver函数获得ContentResolver对象，向该对象发起notifyChange数据变化通知请求；

     5）            在ContentService服务的notifyChange函数中首先调用mRootNode对象的collectObserversLocked函数在ObserverNode树中查找登记的ContentObserver对象，每个找到的ContentObserver以ObserverCall对象记录的形式保存到ObserverCall对象数组中，返回；

     6）            接着ContentService服务的notifyChange函数在ObserverCall对象数组中遍历找到的ContentObserver对象，调用ContentObserver对象远程代理引用的onChange函数；

     7）            ContentObserver对象远程代理的onChange函数转而调用ContentObserver本地桩对象的onChange函数，然后ContentObserver本地桩对象的onChange函数调用具体的ContentObserver对象的onChange函数，完成数据变化通知；

    8）            在ContentService服务的notifyChange函数中，在完成数据变化通知后如果syncToNetwork参数为真，则通过SyncManager对象发起数据同步请求。在该步首先通过getSyncManager函数获得一个SyncManager对象；

    9）            调用SyncManager对象的scheduleLocalSync发起数据同步调用。

                                   欢迎转载,转载时请尊重原创注明出处。

本文链接