接上一節的內容，通過使用 Bsdiff 可以成功實現拆分和合并了。這個時候就要想一下如何完成整個更新的過程。
必須想清楚的問題
這個時候要注意不再是增量拆分，而是如何平滑得實現應用的更新。
- 優先級問題
當檢查更新時，存在最新版本的補丁時，優先使用增量更新；如若沒有，采用完整更新。 - 拆分次數問題
隨著版本不斷迭代，由于 Bsdiff 的拆分效能低，不能也沒必要做到每個新版本提供以前所有版本的補丁。
試想一下，一個版本越久遠越是可能與新版本存在較大差異，補丁包大小逐漸接近完整包大小，再者，App隨著apk的Size也隨之增加，拆分所需的時間、空間也隨之增大，發布新版本的處理時間越來越長，增量更新的優勢不復存在了，這是不能接受的。
在更新版本的時候給予設置向前比較次數，我以3個月為期，對于每月更新的APP可以設為3次。 - 唯一性問題
通常情況下，APP 的版本標識是 包名或者是 application id ，版本號，版本號，我則增加一個類型屬性，可以理解為渠道名，這是為了解決一些現實的問題，同一APP給不同客戶群體使用，例如測試人員和正式用戶，測試人員可以收到內部快速迭代的更新包，而不會影響到正式用戶，這樣可以給特定用戶群開放不同的版本功能，并且能夠實現階段性切換產品線。 - 完整性檢驗
通過SHA1校驗碼確認合并前后文件都是一致的，保障合并的成功率 - 級聯刪除
可以單獨刪除補丁包數據，相應版本只支持完整更新了；刪除完整包數據，就要附帶刪除所有相關的補丁包數據，避免導致更新系統混亂。
界面設計
目前在用的系統也是由這個雛形發展而來，而我現在并不在負責這個部分的編碼，這里公布部分界面以及邏輯原理。
- 產品管理
這里的產品管理是以移動產品為標準劃分。
產品ID：自動UUID，在各個系統模塊中通用，這里僅用于更新模塊，也可用于廣告投放模塊。
產品名稱： 必填
產品說明：一個公司里面可能存在很多類似的產品，用于區分細節。
包名：如果上傳的是APK包，則和應用市場類似，可以不填，自動獲取第一次上傳的application id ，以后通過新增版本頁面上傳是會對比這個參數，不符合就會上傳失敗，避免腦抽了，出現嚴重的問題。
云端下載：自身系統的帶寬有限，通過把包放到阿里云或者七牛等地方，減低帶寬壓力。
- 產品管理
- 2）版本管理
如圖所示。這里會在完整包信息之間插入補丁包信息。補丁包信息必須先于版本信息入庫，避免出現查詢異常。
產品名稱：必選
版本類型：必選
包名：自動獲取，產品存在包名，將會進行對比，否則記入產品信息中。
版本名：給普通用戶查看的版本信息（字符串）。
版本號：int類型，用于升級的版本信息，新上傳的版本號必須大于上一版本。
備注：填入升級信息。
向前對比版本數量：月更新產品，建議設為3次，意思是向上對比不多于3個版本號；周更新產品自己酌情處理。
SHA1：當前文件的SHA1校驗碼。
舊版本SHA1：之前版本的完整包校驗碼，用于更新查詢接口。
提交新版本過程
版本提交流程
接口設計
檢查更新接口擁有4個請求參數，如下
| 參數名 | 參數描述 |
|---|---|
| productId | 產品ID |
| versionCode | 當前版本號 |
| type | 版本類型 |
| oldsha1code | 當前版本的校驗碼 |
返回參數：
| 參數名 | 參數描述 |
|---|---|
| name | 產品ID |
| updateType | 更新類型有三種，inc(增量)、full(完整)、noupdate（無更新） |
| versionCode | 最新版本號 |
| versionName | 最新版本名 |
| size | long類型，更新包大小 |
| sizeOriginal | 在增量更新有效時，表示最新包大小 |
| newSHA | 最新包的SHA1校驗碼 |
| increaseSHA | 補丁包的SHA1校驗碼 |
| url | 下載鏈接 |
| updateList | 更新信息 |
在系統中，版本37的SHA1 是 bbc3be08...4f72f41，最新版本是39，SHA1是d53eca....46474811f,從37到39的補丁包的SHA1 是56efbfce....8628。
1）情況一 ：可能當前版本和最新版本不存在補丁包，也可能是當前版本的檢驗碼與服務器記錄不符，要求完整更新
參數：
productId:b6d9f85e...64ef
versionCode:37
type:official
oldsha1code:1c5cae2551....964fcab
接口結果:
{
"code": 1000,
"updateInfo": {
"name": "b6d9f85e...64ef",
"updateType": "full",
"versionCode": 39,
"versionName": "1.3.3",
"size": 20185438,
"newSHA": "d53eca....46474811f",
"url": "http://xxx.com/files/d53/d53ec/xxxx_1.3.3_39.apk",
"updateList": [
{
"versionCode": 39,
"versionName": "1.3.3",
"updateContent": "1.【新增】優化月租續期繳費，新增自然月續期\n2.【優化】優化附近車場列表加載速度\n3.【優化】優化修復車位申請異常信息提示\n我們始終努力改善您的體驗，提高穩定性以及性能優化"
},
{
"versionCode": 38,
"versionName": "1.3.2",
"updateContent": "1.【新增】預約車位增加車庫位置信息和線路導航；\r\n2.【新增】車場列表新增地區選擇和條件排序；\r\n3.【優化】優化附近車場信息和顯示；\r\n4.【優化】優化月租到期續費；\r\n我們始終努力改善您的體驗，提高穩定性以及性能優化。"
}
]
}
}
2） 情況二：增量更新
請求參數：
productId:b6d9f85e...64ef
versionCode:37
type:official
oldsha1code:bbc3be08...4f72f41
接口結果：
{
"code": 1000,
"updateInfo": {
"name": "b6d9f85e...64ef",
"updateType": "inc",
"versionCode": 39,
"versionName": "1.3.3",
"size": 4049580,
"sizeOriginal": 20185438,
"newSHA": "d53eca....46474811f",
"increaseSHA": "56efbfce....8628",
"url": "http://xxx.com/files/d53/d53ec/xxxx_37_39.patch",
"updateList": [
{
"versionCode": 39,
"versionName": "1.3.3",
"updateContent": "1.【新增】優化月租續期繳費，新增自然月續期\n2.【優化】優化附近車場列表加載速度\n3.【優化】優化修復車位申請異常信息提示\n我們始終努力改善您的體驗，提高穩定性以及性能優化"
},
{
"versionCode": 38,
"versionName": "1.3.2",
"updateContent": "1.【新增】預約車位增加車庫位置信息和線路導航；\r\n2.【新增】車場列表新增地區選擇和條件排序；\r\n3.【優化】優化附近車場信息和顯示；\r\n4.【優化】優化月租到期續費；\r\n我們始終努力改善您的體驗，提高穩定性以及性能優化。"
}
]
}
}
3）情況三：無更新,有兩種原因觸發，一是最新版本檢查更新時出現，也可能是測試版本出現版本號比發布系統上的新。
請求參數:
productId:b6d9f85e...64ef
versionCode:39
type:official
oldsha1code:d53eca....46474811f
接口結果：
{
"code": 1000,
"updateInfo": {
"name": "b6d9f85e...64ef",
"updateType": "noupdate"
}
}
注意：不要在同一文件夾下存放過多文件，會導致磁盤查找緩慢。可以利用像上面的方式利用SHA1來分散存儲。
服務器這邊的情況大致就是這樣了，這個只要和后臺開發說明白了，很快就能完成，這個接口除了黑盒測試之外，需要仔細過一遍白盒測試，如果存在潛在的問題，會在往后的發布過程中暴露出來，導致嚴重的更新事故。
第三部分本來想寫APP的更新過程的，細想一下，這些年我換了幾種網絡框架，大致的邏輯也沒什么變化，唯有網絡框架變化導致代碼重構。除非有迫切的原因，這個部分暫時不會寫了。
