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);

~~~

1. 客户端发起请求

ContentResolver requestSync的代码如下：

**ContentResolver.java::requestSync**

~~~

public static void requestSync(Account account,String authority,

Bundle extras) {

//检查extras携带的参数的数据类型，目前只支持float、int和String等几种类型

validateSyncExtrasBundle(extras);

try {

//调用ContentService的requestSync函数

getContentService().requestSync(account, authority, extras);

}......

}

~~~

与添加账户(addAccount)相比，客户端发起一次同步请求所要做的工作就太简单了。

下面转战ContentService去看它的requestSync函数。

2. ContentService 的requestSync函数分析

**ContentService.java::requestSync**

~~~

public void requestSync(Account account, Stringauthority, Bundle extras) {

ContentResolver.validateSyncExtrasBundle(extras);

longidentityToken = clearCallingIdentity();

try {

SyncManager syncManager = getSyncManager();

if(syncManager != null) {

//调用syncManager的scheduleSync

syncManager.scheduleSync(account, authority, extras,

0,false);

}

}finally {

restoreCallingIdentity(identityToken);

}

}

~~~

ContentService将工作转交给SyncManager来完成，其调用的函数是scheduleSync。

(1) SyncManager的scheduleSync函数分析

先行介绍的scheduleSync函数非常重要。

~~~

/*

scheduleSync一共5个参数，其作用分别如下。

requestedAccount表明要进行同步操作的账户。如果为空，SyncManager将同步所有账户。

requestedAuthority表明要同步的数据项。如果为空，SyncManager将同步所有数据项。

extras指定同步操作中的一些参数信息。这部分内容后续分析时再来介绍。

delay指定本次同步请求是否延迟执行。单位为毫秒。

onlyThoseWithUnkownSyncableState是否只同步那些处于unknown状态的同步服务。该参数

在代码中没有注释。结合前面对syncable为unknown的分析，如果该参数为true，则

本次同步请求的主要作用就是通知同步服务进行初始化操作

*/

public void scheduleSync(Account requestedAccount,String requestedAuthority,

Bundleextras, long delay,boolean onlyThoseWithUnkownSyncableState)

~~~

关于scheduleSync的代码将分段分析，其相关代码如下：

**SyncManager.java::scheduleSync**

~~~

boopublic void scheduleSync(AccountrequestedAccount,

StringrequestedAuthority, Bundle extras,

long delay, boolean onlyThoseWithUnkownSyncableState)

//判断是否允许后台数据传输

finalboolean backgroundDataUsageAllowed = !mBootCompleted ||

getConnectivityManager().getBackgroundDataSetting();

if (extras== null) extras = new Bundle();

//下面将解析同步服务中特有的一些参数信息，下面将逐条解释

//SYNC_EXTRAS_EXPEDITED参数表示是否立即执行。如果设置了该选项，则delay参数不起作用

//delay参数用于设置延迟执行时间，单位为毫秒

Booleanexpedited = extras.getBoolean(

ContentResolver.SYNC_EXTRAS_EXPEDITED,false);

if (expedited)

delay = -1;

Account[]accounts;

if (requestedAccount != null) {

accounts = new Account[]{requestedAccount};

} ......

//SYNC_EXTRAS_UPLOAD参数设置本次同步是否对应为上传。从本地同步到服务端为Upload，

//反之为download

finalboolean uploadOnly = extras.getBoolean(

ContentResolver.SYNC_EXTRAS_UPLOAD, false);

//SYNC_EXTRAS_MANUAL等同于SYNC_EXTRAS_IGNORE_BACKOFF加

//SYNC_EXTRAS_IGNORE_SETTINGS

final boolean manualSync = extras.getBoolean(

ContentResolver.SYNC_EXTRAS_MANUAL, false);

//如果是手动同步，则忽略backoff和settings参数的影响

if(manualSync) {

//知识点一：SYNC_EXTRAS_IGNORE_BACKOFF：该参数和backoff有关，见下文的解释

extras.putBoolean(

ContentResolver.SYNC_EXTRAS_IGNORE_BACKOFF, true);

//SYNC_EXTRAS_IGNORE_SETTINGS：忽略设置

extras.putBoolean(

ContentResolver.SYNC_EXTRAS_IGNORE_SETTINGS, true);

}

finalboolean ignoreSettings = extras.getBoolean(

ContentResolver.SYNC_EXTRAS_IGNORE_SETTINGS,false);

//定义本次同步操作的触发源，见下文解释

int source;

if(uploadOnly) {

source = SyncStorageEngine.SOURCE_LOCAL;

} else if(manualSync) {

source = SyncStorageEngine.SOURCE_USER;

} else if(requestedAuthority == null) {

source = SyncStorageEngine.SOURCE_POLL;

} else {

source = SyncStorageEngine.SOURCE_SERVER;

}

~~~

在以上代码中，有两个知识点需要说明。

知识点一和backoff有关：这个词不太好翻译。和其相关的应用场景是，如果本次同步操作执行失败，则尝试休息一会再执行，而backoff在这个场景中的作用就是控制休息时间。由以上代码可知，当用户设置了手动(Manual)参数后，就无须对这次同步操作使用backoff模式。

另外，在后续的代码中，我们会发现和backoff有关的数据被定义成一个Paire，即backoff对应两个参数。这两个参数到底有什么用呢？笔者在SyncManager代码中找到了一个函数，其参数的命名很容易理解。该函数是setBackoff，原型如下：

**SyncManager.java::setBackoff**

~~~

public void setBackoff(Account account, StringproviderName,

long nextSyncTime, long nextDelay)

~~~

在调用这个函数时，Pair中的两个参数分别对应nextSyncTime和nextDelay，所以，Pair中的第一个参数对应nextSyncTime，第二个参数对应nextDelay。backoff的计算中实际上存在着一种算法。它是什么呢？读者不妨先研究setBackoff，然后再和我们一起分享。

知识点二和SyncStorageEngine定义的触发源有关。说白了，触发源就是描述该次同步操作是因何而起的。SyncStorageEngine一共定义了4种类型的源，这里笔者直接展示其原文解释：

~~~

/* Enumvalue for a local-initiated sync. */

public static final int SOURCE_LOCAL = 1;

/** Enum value for a poll-based sync (e.g., upon connectionto network)*/

public static final int SOURCE_POLL = 2;

/* Enumvalue for a user-initiated sync. */

public static final int SOURCE_USER = 3;

/* Enumvalue for a periodic sync. */

publicstatic final int SOURCE_PERIODIC = 4;

~~~

触发源的作用主要是为了SyncStorageEngine的统计工作。本节不打算深究这部分内容，感兴趣的读者可在学习完本节后自行研究。

关于scheduleSync下一阶段的工作，代码如下：

**SyncManager.java::scheduleSync**

~~~

//从SyncAdaptersCache中取出所有SyncService信息

final HashSetsyncableAuthorities = new HashSet();

for(RegisteredServicesCache.ServiceInfo

syncAdapter :mSyncAdapters.getAllServices()) {

syncableAuthorities.add(syncAdapter.type.authority);

}

//如果指定了本次同步的authority，则从上述同步服务信息中找到满足要求的SyncService

if(requestedAuthority != null) {

final boolean hasSyncAdapter =

syncableAuthorities.contains(requestedAuthority);

syncableAuthorities.clear();

if(hasSyncAdapter) syncableAuthorities.add(requestedAuthority);

}

finalboolean masterSyncAutomatically =

mSyncStorageEngine.getMasterSyncAutomatically();

for(String authority : syncableAuthorities) {

for(Account account : accounts) {

//取出AuthorityInfo中的syncable状态，如果为1，则syncable为true，

//如果为-1，则状态为unknown

intisSyncable = mSyncStorageEngine.getIsSyncable(

account,authority);

if(isSyncable == 0) continue;//syncable为false，则不能进行同步操作

final RegisteredServicesCache.ServiceInfo

syncAdapterInfo =

mSyncAdapters.getServiceInfo(

SyncAdapterType.newKey(authority, account.type));

......

//有些同步服务支持多路并发同步操作

final boolean allowParallelSyncs =

syncAdapterInfo.type.allowParallelSyncs();

finalboolean isAlwaysSyncable = syncAdapterInfo.type.

isAlwaysSyncable();

//如果该同步服务此时的状态为unknown，而它又是永远可同步的(AlwaysSyncable)，

//那么通过setIsSyncable设置该服务的状态为1

if(isSyncable < 0 && isAlwaysSyncable) {

mSyncStorageEngine.setIsSyncable(account, authority, 1);

isSyncable = 1;

}

//如果只操作unknow状态的同步服务，并且该服务的状态不是unknown，则不允许后续操作

if(onlyThoseWithUnkownSyncableState && isSyncable >= 0)

continue;

//如果此同步服务不支持上传，而本次同步又需要上传，则不允许后续操作

if(!syncAdapterInfo.type.supportsUploading() && uploadOnly)

continue;

//判断是否允许执行本次同步操作。如果同步服务状态为unknown，则总是允许发起同步请求，

//因为这时的同步请求只是为了初始化SyncService

boolean syncAllowed = (isSyncable < 0) ||ignoreSettings

|| (backgroundDataUsageAllowed && masterSyncAutomatically

&& mSyncStorageEngine.getSyncAutomatically(

account,authority));

......

//取出对应的backoff参数

Pair backoff = mSyncStorageEngine.getBackoff(

account,authority);

//获取延迟执行时间

longdelayUntil = mSyncStorageEngine.getDelayUntilTime(

account,authority);

finallong backoffTime = backoff != null ? backoff.first : 0;

if(isSyncable < 0) {

Bundle newExtras = new Bundle();

//如果syncable状态为unknown，则需要设置一个特殊的参数，即

//SYNC_EXTRAS_INITIALIZE，它将通知SyncService进行初始化操作

newExtras.putBoolean(ContentResolver.SYNC_EXTRAS_INITIALIZE, true);

scheduleSyncOperation(

new SyncOperation(account, source, authority, newExtras, 0,

backoffTime,delayUntil,allowParallelSyncs));

}

if(!onlyThoseWithUnkownSyncableState)

scheduleSyncOperation(

new SyncOperation(account,source, authority, extras, delay,

backoffTime, delayUntil,allowParallelSyncs));

}//for循环结束

}

}

~~~

scheduleSync函数较复杂，难点在于其策略控制。建议读者反复阅读这部分内容。

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

(2) 处理MESSAGE_CHECK_ALARMS消息

SyncHandler的handleMessage代码如下：

**SyncManager.java::SyncHandler:handleMessage**

~~~

public void handleMessage(Message msg) {

longearliestFuturePollTime = Long.MAX_VALUE;

longnextPendingSyncTime = Long.MAX_VALUE;

try {

waitUntilReadyToRun();

mDataConnectionIsConnected = readDataConnectionState();

//获得WakeLock，防止在同步过程中掉电

mSyncManagerWakeLock.acquire();

//处理周期同步的操作

earliestFuturePollTime= scheduleReadyPeriodicSyncs();

switch (msg.what) {

......

case SyncHandler.MESSAGE_CHECK_ALARMS:

//调用maybeStartNextSyncLocked函数，返回一个时间。见下文解释

nextPendingSyncTime = maybeStartNextSyncLocked();

break;

......

}//switch结束

} finally{

manageSyncNotificationLocked();

/*

将上边函数调用的返回值传递给manageSyncAlarmLocked，该函数内部与

AlarmManagerService交互，其实就是定义一个定时提醒。在Alarm超时后，就会广播

在SyncManager构造函数中定义的那个PendingIntent mSyncAlarmIntent，

而SyncManager收到该广播后又会做对应处理。相关内容读者可自行阅读

*/

manageSyncAlarmLocked(earliestFuturePollTime,nextPendingSyncTime);

mSyncTimeTracker.update();

mSyncManagerWakeLock.release();

}

}

~~~

如以上代码所述，MESSAGE_CHECK_ALARMS消息的处理就是调用maybeStartNextSyncLocked函数。这个函数内容较繁琐，它主要做了以下几项工作。

- 检查SyncQueue中保存的同步操作对象SyncOperation，判断它们对应的同步服务的状态是否为false，如果为false，则不允许执行该同步操作。

- 查询ConnectivityManagerService以判断目标同步服务是否使用了网络。如果该服务当前没有使用网络，则不允许执行该同步操作。

- 判断同步操作对象的执行时间是否已到，如果未到，则不允许执行该操作。

- 将通过上述判断的同步操作对象SyncOperation与当前系统中正在执行的同步操作上下文对象进行比较。系统当前正在执行的同步操作上下文对象对应的数据类是ActiveSyncContext，它是在同步操作对象之上的一个封装，包含了能和同步服务交互的接口。由于并非所有同步服务都支持多路并发同步操作，因此这里需做一些处理，以避免不必要的同步操作。另外，如一个仅对应初始化同步服务的同步操作执行时间过长(由系统属性“sync.max_time_per_sync”控制，默认是5分钟)，系统也需做一些处理。

* * * * *

**提示**：maybeStartNextSyncLocked是笔者在本节留给读者自行分析的函数中最难的一个。读者务必阅读完下面的分析后，尝试去研究此函数。

* * * * *

通过上述层层考验后，manageSyncAlarmLocked最后将调用dispatchSyncOperation真正去派发一个同步操作。下面来看dispatchSyncOperation的代码。

**SyncManager.java::dispatchSyncOperation**

~~~

private booleandispatchSyncOperation(SyncOperation op) {

SyncAdapterType syncAdapterType = SyncAdapterType.

newKey(op.authority,op.account.type);

RegisteredServicesCache.ServiceInfo

syncAdapterInfo=

mSyncAdapters.getServiceInfo(syncAdapterType);

......

//构造一个ActiveSyncContext对象，它就是前面提到的同步操作上下文对象

ActiveSyncContextactiveSyncContext =

new ActiveSyncContext(op,

insertStartSyncEvent(op), syncAdapterInfo.uid);

activeSyncContext.mSyncInfo =

mSyncStorageEngine.addActiveSync(activeSyncContext);

// mActiveSyncContexts保存了当前系统中所有的ActiveSyncContext对象

mActiveSyncContexts.add(activeSyncContext);

//为该对象绑定到具体的同步服务上

if(!activeSyncContext.bindToSyncAdapter(syncAdapterInfo)) {

closeActiveSyncContext(activeSyncContext);

return false;

}

returntrue;

}

~~~

ActiveSyncContext是SyncManager和同步服务交互的关键类，其家族图谱如图8-16所示。

:-: 

图8-16 ActiveSyncContext的 UML类图

图8-16中的ActiveSyncContext和图8-8中的Session非常像。ActiveSyncContext的主要工作包括下面两部分。

- 它将首先通过bindService方式启动SyncService，并在onServiceConnected函数中得到用于和SyncService交互的接口对象，即参与Binder通信的ISyncAdapterBp端。

- ActiveSyncContext是ISyncContext接口的Binder通信的Bn端，它在调用ISyncAdapter的startSync时，会把自己传递给同步服务。同步服务得到的当然是ISyncContext的Bp端对象。当同步服务完成此次同步操作后就会调用ISyncContext 的Bp端对象的onFinished函数以通知ActiveSyncContext同步操作的执行结果。

下面再看第一部分的工作。

(3) ActiveSyncContext派发请求

**SyncManager.java::ActiveSyncContext.bindToSyncAdapter**

~~~

booleanbindToSyncAdapter(RegisteredServicesCache.ServiceInfo info) {

Intentintent = new Intent();

intent.setAction("android.content.SyncAdapter");

//设置目标同步服务的ComponentName

intent.setComponent(info.componentName);

intent.putExtra(Intent.EXTRA_CLIENT_LABEL,

com.android.internal.R.string.sync_binding_label);

intent.putExtra(Intent.EXTRA_CLIENT_INTENT,

PendingIntent.getActivity(

mContext, 0,

new Intent(Settings.ACTION_SYNC_SETTINGS),0));

mBound= true;

//调用bindService启动指定的同步服务

finalboolean bindResult = mContext.bindService(intent, this,

Context.BIND_AUTO_CREATE | Context.BIND_NOT_FOREGROUND

| Context.BIND_ALLOW_OOM_MANAGEMENT);

if(!bindResult)

mBound = false;

returnbindResult;

}

~~~

当目标SyncService从其onBind函数返回后，ActiveSyncContext的onServiceConnected将被调用，该函数的内部处理流程如下：

**SyncManager.java::ActiveSyncContext.onServiceConnected**

~~~

public void onServiceConnected(ComponentName name,IBinder service) {

Messagemsg = mSyncHandler.obtainMessage();

msg.what= SyncHandler.MESSAGE_SERVICE_CONNECTED;

//构造一个ServiceConnectionData对象，并发送MESSAGE_SERVICE_CONNECTED消息

//给mSyncHandler。第二个参数就是SyncService在onBind函数中返回的ISyncAdapter的

//Binder通信对象。不过在ActiveSyncContext中，它是Bp端

msg.obj= new ServiceConnectionData(this,

ISyncAdapter.Stub.asInterface(service));

mSyncHandler.sendMessage(msg);

}

~~~

**SyncManager.java::SyncHandler.handleMessage**

~~~

case SyncHandler.MESSAGE_SERVICE_CONNECTED: {

ServiceConnectionData msgData = (ServiceConnectionData)msg.obj;

if(isSyncStillActive(msgData.activeSyncContext))

//调用runBoundToSyncAdapter函数处理

runBoundToSyncAdapter(msgData.activeSyncContext,

msgData.syncAdapter);

break;

}

~~~

**SyncManager.java::runBoundToSyncAdapter**

~~~

private void runBoundToSyncAdapter(final ActiveSyncContextactiveSyncContext,

ISyncAdapter syncAdapter) {

activeSyncContext.mSyncAdapter = syncAdapter;

finalSyncOperation syncOperation = activeSyncContext.mSyncOperation;

try {

activeSyncContext.mIsLinkedToDeath = true;

syncAdapter.asBinder().linkToDeath(activeSyncContext, 0);

//调用目标同步服务的startSync函数

syncAdapter.startSync(activeSyncContext, syncOperation.authority,

syncOperation.account, syncOperation.extras);

} ......

}

~~~

对SynManager工作的分析到此为止，下面将分析目标同步服务。

3. EmailSyncAdapterService处理请求

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

(1) onBind分析

**EmailSyncAdapterService.java::onBind**

~~~

public IBinder onBind(Intent intent) {

//sSyncAdapter是EmailSyncAdapterService的内部类对象，见下文解释

returnsSyncAdapter.getSyncAdapterBinder();

}

~~~

在以上代码中，sSyncAdapter的类型是EmailSyncAdapterService中的内部类SyncAdapterImpl。它的派生关系如图8-17所示。

:-: 

图8-17 SyncAdapterImpl派生关系图

有图8-17可知：

- AbstractThreadSyncAdapter是核心类，其内部有一个成员变量mISyncAdapterIml，该变量用于和ActiveSyncContext交互，是ISyncAdapter Binder通信的Bn端。该对象也是以上代码中onBind函数的返回值。

- SyncThread从Thread派生。从这一点可看出，同步服务将创建工作线程来执行具体的同步操作。AbstractThreadSyncAdapter中的mSyncThreads保存该同步服务中所有的SyncThread对象。

- 同步操作的结果将通过SyncResult返给SyncManager。

再看SyncManager runBoundToSyncAdapter函数最后调用的startSync函数。

(2) startSync分析

在SyncService中，首先被调用的函数是ISyncAdapterImpl的startSync函数，其代码为：

**AbstractThreadedSyncAdapter.java::ISyncAdapterImpl.startSync**

~~~

public void startSync(ISyncContext syncContext,String authority,

Account account,Bundle extras) {

//构造一个SyncContext对象，用于保存上下文信息

finalSyncContext syncContextClient = new SyncContext(syncContext);

booleanalreadyInProgress;

finalAccount threadsKey = toSyncKey(account);

synchronized (mSyncThreadLock) {

//判断是否存在已经在执行的SyncThread

if(!mSyncThreads.containsKey(threadsKey)) {

if (mAutoInitialize

&& extras != null&& extras.getBoolean(

ContentResolver.SYNC_EXTRAS_INITIALIZE, false)) {

//一般而言，mAutoInitialize都为true，表示同步服务支持自动初始化

//如果该服务对应的syncable状态为unknown，则重新设置syncable为1

if (ContentResolver.getIsSyncable(account, authority) < 0)

ContentResolver.setIsSyncable(account,authority, 1);

//直接返回，不再做后续的处理，实际上后续的流程是可以继续进行的

syncContextClient.onFinished(new SyncResult());

return;

}

//创建一个新的SyncThread对象

SyncThread syncThread = new SyncThread(

"SyncAdapterThread-" +

mNumSyncStarts.incrementAndGet(),

syncContextClient,authority, account, extras);

mSyncThreads.put(threadsKey, syncThread);

syncThread.start();//启动工作线程

alreadyInProgress = false;

}else {

alreadyInProgress = true;

}

}

if(alreadyInProgress)

syncContextClient.onFinished(SyncResult.ALREADY_IN_PROGRESS);

}

~~~

假如尚未匹配的工作线程(根据account生成一个key作为标示来查找是否已经存在对应的工作线程)，SyncService将创建一个SyncThread，其run函数代码是：

**AbstractThreadedSyncAdapter.java::ISyncAdapterImpl.run**

~~~

public void run() {

Process.setThreadPriority(Process.THREAD_PRIORITY_BACKGROUND);

SyncResult syncResult = new SyncResult();

ContentProviderClient provider = null;

try {

if(isCanceled()) return;

//获得同步操作指定的ContentProvider，provider是ContentProviderClient

//类型，用于和目标ContentProvider交互

provider = mContext.getContentResolver().

acquireContentProviderClient(mAuthority);

if (provider != null) {

//调用AbstractThreadedSyncAdapter子类的onPerformSync函数

AbstractThreadedSyncAdapter.this.onPerformSync(mAccount,

mExtras,mAuthority,provider, syncResult);

} else

syncResult.databaseError = true;

}finally {

if (provider != null)

provider.release();

if (!isCanceled()) //通知结果

mSyncContext.onFinished(syncResult);

//工作完成，将该线程从mSyncThreads中移除

synchronized (mSyncThreadLock) {

mSyncThreads.remove(mThreadsKey);

}

}

}

~~~

来看AbstractThreadedSyncAdapter子类实现的onPeroformSync函数，在本例中，子类是SyncAdapterImpl，代码如下：

**EmailSyncAdapterService.java::SyncAdapterImpl.onPerformSync**

~~~

public void onPerformSync(Account account, Bundleextras, String authority,

ContentProviderClient provider,SyncResult syncResult) {

try {

//调用EmailSyncAdapterService performSync完成真正的同步，这部分代码和

//Email业务逻辑相关，此处不再深入研究

EmailSyncAdapterService.performSync(mContext, account, extras,

authority, provider,syncResult);

}......

}

~~~

执行完onPerformSync函数后，ISyncAdapterImpl.run返回前会调用mSyncContext.onFinished函数，向位于SyncManager中的ActiveSyncContext通知同步操作的结果。读者可自行研究这部分内容。

4. ContentResolver requestSync分析总结

总结requestSync的工作流程，如图8-18所示。

:-: 

图8-18 requestSync流程

由图8-18可知，requestSync涉及的对象及调用流程比较繁琐。但从技术上看，则没有什么需要特别注意的地方。