注：本文翻譯自Google官方的Android Developers Training文檔，譯者技術一般，由于喜愛安卓而產生了翻譯的念頭，純屬個人興趣愛好。

原文鏈接： http://developer.android.com/training/cloudsave/conflict-res.html

在云存儲中保存和加載過程是很直接的：它只是將用于數據和byte數組之間的序列化轉換，并將這些數組存儲在云端。然而， 當你的用戶有多個設備，并且兩個以上的設備嘗試將它們的數據存儲在云端時，這一保存可能會引起沖突，因此你必須決定應該如何處理。你在云端存儲的數據結構在很大程度上決定了你的沖突解決方案的魯棒性，所以小心地設計你的數據，使得你的沖突檢測解決方案邏輯可以正確地處理每一種情況。

本片文章從描述一些有缺陷的方法入手，并解釋他們為何具有缺陷。之后呈現一個解決方案來避免沖突。用于討論的例子關注于游戲，但解決問題的宗旨是可以適用于任何將數據存儲于云端的應用的。

一）. 沖突時獲得通知

OnStateLoadedListener 方法負責從 Google 服務器下載應用的狀態數據。回調函數 OnStateLoadedListener.onStateConflict 為你的應用在本地狀態和云端存儲的狀態發生沖突時， 提供了一個解決機制：

      
        @Override


      
      
        public
      
      
        void
      
       onStateConflict(
      
        int
      
      
         stateKey, String resolvedVersion,

    
      
      
        byte
      
      [] localData, 
      
        byte
      
      
        [] serverData) {

    
      
      
        //
      
      
         resolve conflict, then call mAppStateClient.resolveConflict()
      
      
         ...

}
      
    

此時你的應用必須決定要保留哪一個數據，或者它自己提交一個新的數據來表示合并后的數據狀態（譯者注：是不是有點像git/svn呢？），解決沖突的邏輯由你來實現。

我們必須要意識到云存儲服務是在后臺執行同步的。所以你應該確保你的應用能夠在你創建這一數據的context之外接收回調。特別地，如果Google Play服務應用在后臺檢測到了一個沖突，該回調函數可以在你下一次加載數據時被調用，而不是下一次用戶啟動該應用時。

因此，你的云存儲代碼和沖突解決代碼的設計必須是和當前context無關的：即給兩個沖突的數據，你必須僅通過數據集中獲取的數據區解決沖突，而不依賴于任何其它外部環境。

二）. 處理簡單地情況

下面列舉一些沖突解決的簡單例子。對于很多應用而言，用這些策略或者其變體就足夠解決大多數問題了：

新的比舊的更有效 ：在一些情況下，新的數據總是替代老數據。例如，如果數據代表了用戶選擇角色的衣服顏色，那么最近的新的選擇就應該覆蓋老的選擇。在這種情況下，你可能會選擇在云存儲數據中存儲時間戳。當處理這些沖突時，選擇時間戳最新的數據（記住要選擇一個可靠的時鐘，并注意對不同時區的處理）。

有一個數據集中的數據比其它的更好 ：在一些情況下，我們是可以有方法在若干數據集中選取一個最好的。例如，如果數據代表了玩家在賽車比賽中的最佳時間，那么顯然，在沖突發生時，你應該保留成績最好的那個數據。

進行合并 ：有可能通過計算兩個數據集的合并版本來解決沖突。例如，如果你的數據代表了用戶解鎖關卡的進度，那么解決的數據就是沖突集的并集。通過這個方法，用戶不會丟失任何他的游戲進度。這里的 例子 使用了這一操作的一個變形。

三）. 為更復雜的情況設計一個策略

一個更復雜的情況是當你的游戲允許玩家收集可以互換的東西時（比如金幣或者經驗點數），我們來假想一個游戲，叫做“金幣跑酷”，一個無限跑步的角色其目標是不斷地收集金幣是自己變的富有。每個收集到的金幣都會加入到玩家的儲蓄罐中。

下面的章節將展示三種在多個設備間解決沖突的方案：有兩個聽上去很不錯，可惜最終還是不能適用于所有的場景，最后一個解決方案可以解決多個設備間的沖突。

第一個嘗試：只保存總數

首先，這個問題看上去像是說：云存儲的數據只要存儲金幣的數量就行了。但是如果就只有這些數據是可用的，那么解決沖突的方案將會嚴重受到限制。此時最佳的方案就是在沖突發生時存儲最大數值得數據。

想一下表一中所展現的場景。假設玩家一開始有20枚硬幣，然后再設備A上收集了10個，在設備B上收集了15個。然后設備B將數據存儲到了云端。當設備A嘗試去存儲的時候，沖突發生了。“只存儲總數”的沖突解決方案會存儲35作為這一數據的值（兩數之間最大的）

表1. 值保存最大的數（不佳的策略）

這一策略會失敗——玩家的金幣數從20變成35，但實際上玩家總共收集了25個硬幣（A設備10個，B設備15個）。所以有10個硬幣丟失了。只在云端存儲硬幣的總數是不足以實現一個魯棒的沖突解決算法的。

第二個嘗試：存儲總數和變化值

另一個方法是在存儲數據中包括一些額外的數據：自上次提交后硬幣增加的數量（delta）。在這一方法中，存儲的數據可以用一個二元組來表示（T, d），其中T是硬幣的總數，而d是硬幣增加的數量。

在這個結構中，你的沖突檢測算法在魯棒性上有更大的提升空間，如下將要講的那樣。但是這個方法還是無法給出一個可靠的玩家最終的狀態。

下面是包含delta的沖突解決算法過程：

• 本地數據： （T, d）
• 云端數據： （T', d'）
• 解決后的數據： （T'+d, d）

例如，當你在本地狀態（ T, d ）和云端狀態（ T', d ）之間發生了沖突時，你可以將它們合并成 （ T'+d, d ）。意味著你從本地拿出delta數據，并將它和云端的數據結合起來，乍一看，這種方法可以很好的計量多個設備所收集的金幣。

看上去很可靠的方法，但這個方法在動態移動環境中難以適用：

• 用戶可能在設備不在線時存儲數據。這些改變會以隊列形式等待手機聯網后提交。
• 這個方法的同步機制是用最新的變化覆蓋掉任何之前的變化。換句話說，第二次寫入的變化會提交到云端（當設備聯網了以后），而第一次寫入的變化就被忽略了。

為了進一步說明，我們考慮一下表2所列的場景。在表2的一系列操作后，云端的狀態將是（130, +5），之后最終沖突解決后的狀態時（140, +10）。這是不正確的，因為從總體上而言，用戶一共在A上收集了110枚硬幣而在B上收集了120枚硬幣。總數應該為250。

表2. “總數+增量”策略的失敗案例

注：x代表與該場景無關的數據

你可能會嘗試在每次保存后不重置增量數據來解決此問題，這樣的話在每個設備上的第二次存儲所收集到的硬幣將不會產生問題。這樣的話設備A在第二次本地存儲完成后，數據將是（ 130, +110 ）而不是（ 130, +10 ）。然而，這樣做的話就會發生如表3所述的情況：

表3. 算法改進后的失敗案例

注：x代表與該場景無關的數據

現在你碰到了另一個問題：你給予了玩家過多的硬幣。這個玩家拿到了211枚硬幣，但實際上他只收集了111枚。

解決辦法：

我們分析之前的幾次嘗試，我們發現這些策略都沒有這樣一個能力：知曉哪些硬幣已經計數了，哪些硬幣沒有被計數，尤其是當多個設備連續提交的時候，算法會出現混亂。

該問題的解決辦法將你云端的存儲結構改為字段，使用字符串+整形的鍵值對。每一個鍵值對都會代表一個包含硬幣的“委托”，而總數就應該是將所有值加起來。這一設計的宗旨是每個設備有它自己的委托，并且只有設備自己可以吧硬幣放到其委托中。

字典的結構是： (A:a, B:b, C:c, ...) ，其中a代表了委托A所擁有的硬幣，b是委托B所擁有的硬幣，以此類推。

這樣的話，新的沖突解決策略算法將如下所示：

本地數據： (A:a, B:b, C:c, ...)

云端數據： (A:a', B:b', C:c', ...)

解決后的數據 ： (A: max (a,a'), B: max (b,b'), C: max (c,c'), ...)

例如，如果本地數據是 (A:20, B:4, C:7) 并且云端數據是 (B:10, C:2, D:14) ，這樣的話解決沖突后的數據將會是 (A:20, B:10, C:7, D:14) 。注意，你應用的沖突解決邏輯會根據具體的場景可能有所差異。比如，有一些應用你可能希望挑選最小的值。

為了測試新的算法，將它應用于任何一個之前提到過的場景。你將會發現它都能取得正確地結果。

表4闡述了這一點，它基于表3的場景。注意下面所列的：

在初始狀態，玩家有20枚硬幣。此數值在所有設備和云端都是正確的，我們用（X:20）這一元祖代表它，其中X我們不用太多關心，我們不去追求這個初始化的數據是哪兒來的。

當玩家在設備A上收集了100枚硬幣，這一變化會作為一個元組保存到云端。它的值是100是因為這就是玩家在設備A上收集的硬幣數量。在這一過程中，沒有要執行數據的計算——設備A僅僅是將玩家所收集的數據匯報給了云端。

每一個新的硬幣提交會打包成一個于設備關聯的元組并保存到云端。例如，假設玩家又在設備A上收集了100枚硬幣，那么元組的值被更新為110。

最終的結果就是，應用知道了玩家在每個設備上收集硬幣的總數。這樣它就能輕易地計算總數了。

表4. 鍵值對策略的成功應用案例

四）. 清除你的數據

在云端存儲數據的大小是由限制的，所以在后續的論述中，我們將會關注與如何避免創建過大的詞典。一開始，看上去每個設備只會有一個詞典字段，即使是非常激進的用戶也不太會擁有上千條字段。然而， 獲取設備ID的方法很難，并且我們認為這是一種不好的實踐方式，所以你應該使用一個安裝ID，這更容易獲取也更可靠。這樣的話就意味著，每一次用戶在每臺設備安裝一次就會產生一個ID。假設每個鍵值對占據32字節，由于一個個人云存儲緩存最多可以有128K的大小，那么你最多可以存儲4096個字段。

在現實場景中，你的數據可能更加復雜。在這種情況下，存儲的數據字段數也會進一步受到限制。具體而言則需要取決于實現，比如可能需要添加時間戳來指明每個字段是何時修改的。當你檢測到有一個字段在過去幾個禮拜或者幾個月的時間內都沒有被修改，那么就可以安全地將它轉移到另一個字段中并刪除老的字段。

【Android Developers Training】 91. 解決云儲存沖突