跟着Innost理解下数据更新、数据同步

本章将先分析ContentService中数据通知机制的实现，然后分析AccountManagerService，最后再介绍ContentService中的数据同步服务。

在理解内部实现之前，最好先弄清增么用。由于涉及的类太多，搞不清楚状况，可以先阅读：
https://sites.google.com/site/andsamples/concept-of-syncadapter-androidcontentabstractthreadedsyncadapter
http://www.c99.org/2010/01/23/writing-an-android-sync-provider-part-1/
http://www.c99.org/2010/01/23/writing-an-android-sync-provider-part-2/

ContentService包含以下两个主要功能：
· 它是Android平台中数据更新通知的执行者。数据更新通知与Cursor，query函数实现时提到的ContentObserver有关。
· 它是Android平台中数据同步服务的管理中枢。当用户通过Android手机中的Contacts应用将联系人信息同步到远端服务器时，就需要和ContentService交互

AccountManagerService，负责管理Android手机中用户的账户，这些账户是用户的online账户，例如用户在Google、Facebook上注册的账户。

1. 数据更新通知机制分析

如果程序需要监控某数据项的变化，可以采用一个类似while循环的语句不断查询它以判断其值是否发生了变化。显而易见，这种方式的效率很低。有了通知机制以后，程序只需注册一个ContentObserver实例即可。一旦该项数据发生变化，系统就会通过ContentObserver的onChange函数来通知我们。与前面所述的轮询相比，此处的通知方式明显更高效。

通过上面的描述可以知道，通知机制的实施包括两个步骤：第一步，注册观察者；第二步，通知观察者。在Android平台中，这两步都离不开ContentService，下面来认识一下它。

1.1 ContentService的生成和初始化

SystemServer创建ContentService的代码非常简单。直接调用了ContentService的main函数。在一般情况下，该函数第二个参数为false。
ContentService中最难的功能是数据同步服务，不过该功能的实现都封装在SyncManager及相关类中了，所以在分析通知机制时不会和数据同步服务有太多瓜葛。

1.2 ContentResovler.registerContentObserver

下面来分析通知机制实施的第一步，注册ContentObserver。该步骤由ContentResovler提供的registerContentObserver函数来实现。registerContentObserver最终将调用ContentService的registerContentObserver函数。

1.2.1 ContentObserver
内部定义了一个Transport类参与Binder通信。由图可知，Transport类从IContentObserver.stub派生。从Binder通信角度来看，客户端进程中的Transport将是Bn端。如此，通过registerContentObserver传递到ContentService所在进程的就是Bp端。IContentObserverBp端对象的真实类型是IContentObserver.Stub.Proxy。

注意IContentObserver.java由aidl处理IContentObserver.aidl生成

1.2.2 ContentService.registerContentObserver函数分析
ContentService要做的事情其实很简单，就是保存uri和observer的对应关系到其内部变量mRootNode中
mRootNode是ContentService的成员变量，其类型为ObserverNode。ObserverNode的组织形式是数据结构中的树，其叶子节点的类型为ObserverEntry，它保存了uri和对应的IContentObserver对象。

1.3 ContentResolver的 notifyChange

再来看通知机制实施的第二步，即通知观察者。数据更新的通知由ContentResolver的notifyChange函数触发。

2. AccountManagerService

AccountManagerService负责管理手机中用户的online账户，主要工作涉及账户的添加和删除、AuthToken（全称为authentication token。有了它，客户端就无须每次操作都向服务器发送密码了）的获取和更新等。

2.1 AccountManagerService构造和初始化

注册AccountManagerService到ServiceManager，服务名为“account”
在AccountManagerService构造函数中创建了一个AccountAuthenticatorCache对象，它是什么？

2.1.1 AccountAuthenticatorCache
AccountAuthenticatorCache是Android平台中账户验证服务（Account AuthenticatorService，AAS）的管理中心。而AAS则由应用程序通过在AndroidManifest.xml中输出符合指定要求的Service信息而来。稍后读者将看到这些要求的具体格式。

2.1.1.1 AAS 解析和输入输出举例
在Email应用的AndroidManifest.xml中定义了一个AAS，如下：

在Email中这个Service对应为EasAuthenticatorService，其Intent匹配的Action为“android.accounts.AccountAuthenticator”，其MetaData的name为“android.accounts.AccountAuthenticator”，而MetaData的具体信息保存在resource资源中。
MetaData保存在resource中另一个xml文件，即eas_authenticator.xml。内容如下：

这个xml中的内容是有严格要求的，其中：
· accountType标签用于指定账户类型（账户类型和具体应用有关，Android并未规定账户的类型）。
· icon、smallIcon、label和accountPreferences等用于界面显示。例如，当需要用户输入账户信息时，系统会弹出一个Activity，上述几个标签就用于界面显示。详细情况可阅读SDK文档AbstractAccountAuthenticator的说明。

一个实际的android.accounts.AccountAuthenticator.xml的内容如图：

有3个AAS服务，其中同一个uid有两个服务（即uid为10015对应的两个Service）。

2.1.1.2 AccountAuthenticatorCache类图

类图解释：
· AccountAuthenticatorCache从RegisteredServicesCache派生。RegisteredServicesCache是一个模板类，专门用于管理系统中指定Service的信息收集和更新，而具体是哪些Service由RegisteredServicesCache构造时的参数指定。AccountAuthenticatorCache对外输出由RegisteredServicesCache模板参数指定的类的实例。在图中应该就是AuthenticatorDescription。
· AuthenticatorDescription继承了Parcelable接口，这代表它可以跨Binder传递。该类描述了AAS相关的信息。
· AccountAuthenticatorCache实现了IAccountAuthenticatorCache接口。这个接口供外部调用者使用以获取AAS的信息。

AccountAuthenticatorCache调用在其基类RegisteredServicesCache的构造函数时，传递了3个字符串参数，这3个参数用于控制RegisteredServicesCache从PackageManagerService获取哪些Service的信息。

2.1.1.3 RegisteredServicesCache
· 成员变量mPersistentServicesFile指向/data/system/registered_service/目录下的一个文件，该文件保存了以前获取的对应Service的信息。就AccountAuthenticator而言，mPersistentServicesFile指向该目录的android.accounts.AccountAuthenticator.xml文件。
· 由于RegisteredServicesCache管理的是系统中指定Service的信息，当系统中有Package安装、卸载或更新时，RegisteredServicesCache也需要对应更新自己的信息，因为有些Service可能会随着APK被删除而不复存在。

generateServiceMap函数将获取指定的Service信息

2.1.1.4 parseServiceInfo
parseServiceInfo将解析Service中的MetaData信息，然后调用子类实现的parseServiceAttributes函数，以获取特定类型Service的信息。

2.1.2 AccountManagerService构造函数

创建数据库文件/data/system/accounts.db：
accounts.db数据库中有一个grants表，用于存储授权信息，该信息用于保存哪些Package有权限获取账户信息。下面的函数将根据grants表中的数据查询PKMS，以判断这些Package是否还存在。如果系统中已经不存在这些Package，则grants表需要更新

accounts.db中有一个accounts表，该表中存储了账户类型和账户名。其中，账户类型就是AuthenticatorDescription中的accountType，它和具体应用有关。下面这个函数将比较accounts表中的内容与AccountAuthenticatorCache中服务的信息，如果AccountAuthenticatorCache已经不存在对应账户类型的服务，则需要删除accounts表中的对应项

2.2 AccountManager.addAccount()

AccountManagerService是一个运行在SystemServer中的服务，客户端进程必须借助AccountManager提供的API来使用AccountManagerService服务，

AccountManagerService在addAccount流程中所起的是桥梁作用，具体如下：
· 客户端将请求发送给AccountManagerService，然后AccountManagerService再转发给对应的AAS。
· AAS处理完的结果先返回给AccountManagerService，再由AccountManagerService返回给客户端。

该流程涉及3个模块，分别是客户端、AccountManagerService和AAS。

2.2.1 AccountManager的addAccount发起请求

AccountManager 的addAccount函数的参数和返回值较复杂:
· addAccount的返回值类型是AccountManagerFuture。其中，AccountManagerFuture是一个模板Interface，其真实类型只有在分析addAccount的实现时才能知道。现在可以告诉读者的是，它和Java并发库（concurrent库）中的FutureTask有关，是对异步函数调用的一种封装[①]。调用者在后期只要调用它的getResult函数即可取得addAccount的调用结果。由于addAccount可能涉及网络操作（例如，AAS需要把账户添加到网络服务器上），所以这里采用了异步调用的方法以避免长时间的阻塞。这也是AccountManagerFuture的getResult不能在主线程中调用的原因。
· addAccount的第一个参数accountType代表账户类型。该参数不能为空。就本例而言，它的值为“com.android.email”。
· authTokenType、requiredFeatures和addAccountOptions与具体的AAS服务有关。如果想添加指定账户类型的Account，则须对其背后的AAS有所了解。
· activity：此参数和界面有关。例如有些AAS需要用户输入用户名和密码，故需启动一Activity。在这种情况下，AAS会返回一个Intent，客户端将通过这个activity启动Intent所标示的Activity。读者将通过下文的分析了解这一点。
· callback和handler：这两个参数与如何获取addAccount返回结果有关。如这两个参数为空，客户端则须单独启动一个线程去调用AccountManagerFuture的getResult函数。

2.2.1.1 AmsTask介绍
· AmsTask继承自FutureTask，并实现了AccountManagerFuture接口。FutureTask是Java concurrent库中一个常用的类。AmsTask定义了一个doWork虚函数，该函数必须由子类来实现。
· 一个AmsTask对象中有一个mResponse成员，该成员的类型是AmsTask中的内部类Response。从Response的派生关系可知，Response将参与Binder通信，并且它是Binder通信的Bn端。而AccountManagerService的addAccount将得到它的Bp端对象。当添加完账户后，AccountManagerService会通过这个Bp端对象的onResult或onError函数向Response通知处理结果。

2.2.1.2 AmsTask匿名类处理分析
AccountManager的addAccount最终返回给客户端的是一个AmsTask的子类
下一步调用的是这个匿名类的start函数

2.2.2 AccountManagerService addAccount转发请求
AccountManagerService的addAccount函数最后也创建了一个匿名类对象，该匿名类派生自Session。addAccount最后还调用了这个对象的bind函数。其中最重要的内容就是Session。那么，Session又是什么呢？

2.2.2.1 Session介绍
· Session从IAccountAuthenticatorResponse.Stub派生，这表明它将参与Binder通信，并且它是Bn端。那么这个Binder通信的目标是谁呢？，它正是具体的AAS服务。AccountManagerService会将自己传递给AAS，这样，AAS就得到IAccountAuthenticatorResponse的Bp端对象。当AAS完成了具体的账户添加工作后，会通过IAccountAuthenticatorResponse的Bp端对象向Seession返回处理结果。
· Session通过mResponse成员变量指向来自客户端的IAccountManagerResponse接口，当Session收到AAS的返回结果后，又通过IAccountManagerResponse 的Bp端对象向客户端返回处理结果。
· Session mAuthenticator变量的类型是IAccountAuthenticator，它用于和远端的AAS通信。客户端发起的请求将通过Session经由mAuthenticator调用对应AAS中的函数。

2.2.2.2 Session匿名类处理分析
Session的bind函数将启动指定类型的Service，这是通过bindService函数完成的。如果服务启动成功，Session的onServiceConnected函数将被调用
AccountManagerService在addAccount最终将调用AAS实现的addAccount函数。

2.2.3 Eas.AuthenticatorService处理请求
下面来看本例中满足“com.android.email”类型的服务是如何处理addAccount的请求的。该服务就是Email应用中的EasAuthenticatorService
EasAuthenticatorService的创建是AccountManagerService调用了bindService导致的，该函数会触发EasAuthenticatorService的onBind函数被调用

2.2.3.1 EasAuthenticator介绍

· EasAuthenticator从AbstractAccountAuthenticator类派生。AbstractAccountAuthenticator内部有一个mTransport的成员变量，其类型是AbstractAccountAuthenticator的内部类Transport。在前面的onBind函数中，EasAuthenticator的getIBinder函数返回的就是这个变量。
· Transport类继承自Binder，故它将参与Binder通信，并且是IAccountAuthenticator的Bn端。Session匿名类通过onServiceConnected函数将得到一个IAccountAuthenticator的Bp端对象。
当由AccoutManagerService的addAccount创建的那个Session匿名类调用IAccountAuthenticator Bp端对象的addAccount时，将触发位于Emai进程中的IAccountAuthenticatorBn端的addAccount。下面来分析Bn端的addAccount函数。

2.2.3.2 EasAuthenticator的 addAccount函数分析

不同的AAS有自己特定的处理逻辑，以上代码向读者展示了EasAuthenticatorService的工作流程。虽然每个AAS的处理方式各有不同，但Android还是定义了一些通用的参数，例如OPTIONS_USERNAME用于表示用户名，OPTIONS_PASSWORD用于表示密码等。

2.2.3.4 返回值的处理流程
在EasAuthenticator的addAccount返回处理结果后，AbstractAuthenticator将通过IAccountAuthenticatorResponse的onResult将其返回给由AccountManagerService创建的Session匿名类对象。

3. 数据同步管理SyncManager分析

本节将分析ContentService中负责数据同步管理的SyncManager。SynManager和AccountManagerService之间的关系比较紧密。同时，由于数据同步涉及手机中重要数据（例如联系人信息、Email、日历等）的传输，因此它的控制逻辑非常严谨，知识点也比较多，难度相对比AccountManagerService大。

3.1 SyncManager基础

3.1.1 SyncManager类图

· 左上角是SyncAdaptersCache类，从功能和派生关系上看，它和AccountManagerService中的AccountAuthenticatorCaches类似。SyncAdaptersCache用于管理系统中SyncService服务的信息。在SyncManager中，SyncService的信息用SyncAdapterType类来表示。
· 左下角是SyncQueue和SyncOperation类，SyncOperation代表一次正在执行或等待执行的同步操作，而SyncQueue通过mOperationsMap保存系统中存在的SyncOperation。
· 右半部分是SyncStorageEngine，由于同步操作涉及,重要数据的传输，加之可能耗时较长，所以SyncStorageEngine提供了一些内部类来保存同步操作中的一些信息。例如PendingOperation代表保存在从本地文件中的那些还没有执行完的同步操作的信息。另外，SyncStrorageEngine还需要对同步操作进行一些统计，例如耗电量统计等。SyncStorageEngine包含的内容较多，读者学习完本章后可自行研究相关内容。

两个重要知识点。
第一， SyncManager为SyncStorageEngine设置了一个状态监听对象。根据前文的描述，在SyncManager家族中，SyncStorageEngine专门负责管理和保存同步服务中绝大部分的信息，所以当外界修改了这些信息时，SyncStorageEngine需要通知状态监听对象。
第二，SyncManager将为AccountManager设置一个账户更新监听对象（注意，此处是AccountManager，而不是AccountManagerService。AccountManager这部分功能的代码不是很简单，读者有必要反复研究）。在Android平台上，数据同步和账户的关系非常紧密，并且同一个账户可以对应不同的数据项。例如在EasAuthenticator的addAccount实现中，读者会发现一个Exchange账户可以对应Contacts、Calendar和Email三种不同的数据项。在添加Exchange账户时，还可以选择是否同步其中的某项数据（通过判断实现addAccount时传递的options是否含有对应的同步选项，例如同步邮件数据时需要设置的OPTIONS_EMAIL_SYNC_ENABLED选项）。由于SyncManager和账户之间的这种紧密关系的存在，SyncManager就必须监听手机中账户的变化情况。

3.1.2 SyncStorageEngine介绍
SyncStorageEngine负责整个同步系统中信息管理方面的工作。

SyncStorageEngine的构造函数得到系统中加密文件系统的路径:
/data/system/sync/status.bin，该文件记录同步服务管理运行过程中的一些统计信息
/data/system/sync/pending.bin，该文件记录了当前处于pending状态的同步请求
/data/system/sync/stats.bin，该文件记录同步服务管理运行过程中的一些统计信息
data/system/sync/accounts.xml 的内容：
· listen-for-tickles，该标签和Android平台中的Master Sync有关。Master Sync用于控制手机中是否所有账户对应的所有数据项都自动同步。用户可通过ContentResolver setMasterSyncAutomatically进行设置。
· AuthorityInfo。AuthorityInfo记录了账户和SyncService相关的一些信息。此框中的account为笔者的邮箱，type为“com.google”。另外，从图中还可发现，一个账户（包含account和type两个属性）可以对应多种类型的数据项，例如此框中对应的数据项是“com.android.email.provider”，而此框前面一个AuthorityInfo对应的数据项是“com.google.android.apps.books”。AuthorityInfo中的periodicSync用于控制周期同步的时间，单位是秒，默认是86400秒，也就是1天。另外，AuthorityInfo中还有一个重要属性syncable，它的可选值为true、false或unknown（在代码中，这3个值分别对应整型值1、0和-1）。如果某个SyncService的状态为unknown，那么在启动它时必须传递一个SYNC_EXTRAS_INITIALIZE选项，SyncService解析该选项后即可知自己尚未被初始化。当它完成初始化后，需要调用setIsSyncable函数设置syncable的状态为1。另外，SyncService初始化完成后，是否可接着执行同步请求呢？目前的设计是，它们并不会立即执行同步，需要用户再次发起请求。

3.1.3 SyncAdaptersCache介绍
图列出了同步服务，其中黑框列出的是“com.android.exchange”，该项服务和Android中Exchange应用有关。

Exchange的AndroidManifest.xml文件的信息如图所示。图列出了Exchange应用所支持的针对邮件提供的同步服务，即EmailSyncAdapterService。该服务会通过meta-data中的resource来描述自己

EmailSyncAdapterService对应的账户类型是“com.android.exchange”，需要同步的邮件数据地址由contentAuthority表示，即本例中的“com.android.email.provider”。注意，EmailSyncAdapterService只支持从网络服务端同步数据到本机，故supportsUploading为false。

3.1.4 SyncQueue介绍
SyncQueue用于管理同步操作对象SyncOperation。
SyncQueue比较简单，其中一个比较难理解的概念是backoff，后文再对此作解释。

3.2 ContentResolver 的requestSync分析

面将通过实例分析同步服务的工作流程。在本例中，将同步Email数据，目标同步服务为EmailSyncAdapterService。

ContentResolver提供了一个requestSync函数，用于发起一次数据同步请求。在本例中，该函数的调用方法如下：

Account emailSyncAccount = newAccount("fanping.deng@gmail",
                                               "com.google");
String emailAuthority ="com.android.email.provider";
Bundle emailBundle = new Bundle();
......//为emailBundle添加相关的参数。这些内容和具体的同步服务有关
//发起Email同步请求
ContentResolver.requesetSync(emailSyncAccount,emailAuthority,emailBundle);

3.2.1 客户端发起请求
将请求发给ContentService.requestSync()

3.2.2 ContentService 的requestSync函数分析
ContentService将工作转交给SyncManager来完成

3.2.2.1 SyncManager的scheduleSync函数分析
scheduleSync一共5个参数，其作用分别如下。
requestedAccount表明要进行同步操作的账户。如果为空，SyncManager将同步所有账户。
requestedAuthority表明要同步的数据项。如果为空，SyncManager将同步所有数据项。
extras指定同步操作中的一些参数信息。这部分内容后续分析时再来介绍。
delay指定本次同步请求是否延迟执行。单位为毫秒。
onlyThoseWithUnkownSyncableState是否只同步那些处于unknown状态的同步服务。该参数在代码中没有注释。结合前面对syncable为unknown的分析，如果该参数为true，则本次同步请求的主要作用就是通知同步服务进行初始化操作

scheduleSync最后将构造一个SyncOperation对象，并调用scheduleSyncOperation处理它。scheduleSyncOperation内部会将这个SyncOperation对象保存到mSyncQueue中，然后发送MESSAGE_CHECK_ALARMS消息让mSyncHandler去处理。由于scheduleSyncOperation函数比较简单，因此下面将直接去mSyncHandler的handleMessage函数中分析MESSAGE_CHECK_ALARMS的处理过程。

3.2.2.2 处理MESSAGE_CHECK_ALARMS消息
MESSAGE_CHECK_ALARMS消息的处理就是调用maybeStartNextSyncLocked函数。这个函数内容较繁琐，它主要做了以下几项工作。
· 检查SyncQueue中保存的同步操作对象SyncOperation，判断它们对应的同步服务的状态是否为false，如果为false，则不允许执行该同步操作。
· 查询ConnectivityManagerService以判断目标同步服务是否使用了网络。如果该服务当前没有使用网络，则不允许执行该同步操作。
· 判断同步操作对象的执行时间是否已到，如果未到，则不允许执行该操作。
· 将通过上述判断的同步操作对象SyncOperation与当前系统中正在执行的同步操作上下文对象进行比较。系统当前正在执行的同步操作上下文对象对应的数据类是ActiveSyncContext，它是在同步操作对象之上的一个封装，包含了能和同步服务交互的接口。由于并非所有同步服务都支持多路并发同步操作，因此这里需做一些处理，以避免不必要的同步操作。另外，如一个仅对应初始化同步服务的同步操作执行时间过长（由系统属性“sync.max_time_per_sync”控制，默认是5分钟），系统也需做一些处理。

ActiveSyncContext是SyncManager和同步服务交互的关键类。ActiveSyncContext的主要工作包括下面两部分。
· 它将首先通过bindService方式启动SyncService，并在onServiceConnected函数中得到用于和SyncService交互的接口对象，即参与Binder通信的ISyncAdapterBp端。
· ActiveSyncContext是ISyncContext接口的Binder通信的Bn端，它在调用ISyncAdapter的startSync时，会把自己传递给同步服务。同步服务得到的当然是ISyncContext的Bp端对象。当同步服务完成此次同步操作后就会调用ISyncContext 的Bp端对象的onFinished函数以通知ActiveSyncContext同步操作的执行结果。

3.2.2.3 ActiveSyncContext派发请求
当目标SyncService从其onBind函数返回后，ActiveSyncContext的onServiceConnected将被调用

3.3.3 EmailSyncAdapterService处理请求
在本例中，目标同步服务位于EmailSyncAdapterService中，先看它通过onBind函数返回给ActiveSyncContext的是什么。

3.3.3.1 onBind分析
sSyncAdapter的类型是EmailSyncAdapterService中的内部类SyncAdapterImpl。它的派生关系如图：

AbstractThreadSyncAdapter是核心类，其内部有一个成员变量mISyncAdapterIml，该变量用于和ActiveSyncContext交互，是ISyncAdapter Binder通信的Bn端。该对象也是以上代码中onBind函数的返回值。
· SyncThread从Thread派生。从这一点可看出，同步服务将创建工作线程来执行具体的同步操作。AbstractThreadSyncAdapter中的mSyncThreads保存该同步服务中所有的SyncThread对象。
· 同步操作的结果将通过SyncResult返给SyncManager。

3.3.3.2 startSync分析
假如尚未匹配的工作线程（根据account生成一个key作为标示来查找是否已经存在对应的工作线程），SyncService将创建一个SyncThread
来看AbstractThreadedSyncAdapter子类实现的onPeroformSync函数，在本例中，子类是SyncAdapterImpl
执行完onPerformSync函数后，ISyncAdapterImpl.run返回前会调用mSyncContext.onFinished函数，向位于SyncManager中的ActiveSyncContext通知同步操作的结果。