工作這幾年碰到的版本檢測升級的接口也算是五花八門，啥樣的都有拓哟，但肯定有的功能是
有個apk的下載鏈接主到，能間接或直接提示你是強制還是非強制更新：
- 間接是指提供你后臺最新版本號，讓你自己與本地版本號通過比較得出是否升級或強制升級阴挣；
- 直接就是后臺接口直接返回個Boolean類型告訴你是強制或者非強制更新气堕。
個人認為一個好的版本檢測接口需要設(shè)計的更靈活更清晰用起來更方便，下面就我理解的接口設(shè)計如下（如思路有誤，歡迎指正）：
總字段如下(并不是所有字段都要返回給客戶端)：
1.最新版本號 ：newVersion
2.最小支持版本號 : minVersion
3.apk下載url : apkUrl
4.更新文案 : updateDescription
5.是否有更新 : isUpdate
6.是否強制更新 : forceUpdate
可選字段：
7.apk文件大芯グ拧：apkSize
8.apk的文件MD5值：md5
方案一（前端處理邏輯）：
前端調(diào)用獲取當前服務(wù)器端最新版本信息的接口揖膜，然后根據(jù)返回的服務(wù)器端最新版本信息與客戶端當前版本信息進行比較，此處需要后端提供最新版本號 ：newVersion 梅桩、 最小支持版本號 : minVersion 壹粟、apk下載url : apkUrl 、更新文案 : updateDescription 這四個字段宿百。如下表：
| 字段 | 字段描述 |
|---|---|
| newVersion | 最新版本號 |
| minVersion | 最小支持版本號 |
| apkUrl | apk下載url |
| updateDescription | 更新文案 |
客戶端邏輯如下：
- 如果currentVersion < newVersion,則有更新信息趁仙；
- 如果currentVersion < minVersion,則需要強制更新；
- 如果currentVersion >= minVersion,則不需要強制更新;
- 如果currentVersion == newVersion犀呼，則沒有更新信息幸撕。
客戶端對應(yīng)的流程圖：
前端處理邏輯不足之處：
對指定版本進行強制更新可能不是那么好，可是為什么要對指定版本進行更新呢外臂？
此處做個假設(shè)：你的應(yīng)用當前線上運行版本為V2.1.1, V2.1.2兩個版本用戶量比較多坐儿，又快要發(fā)布V2.1.3了，此時發(fā)現(xiàn)V2.1.2有個bug需要修復(fù)一下宋光，然后在V2.1.3修復(fù)后發(fā)布了貌矿，當時感覺小問題就非強制更新（
畢竟強制更新比較反感），過了幾天查看V2.1.1, V2.1.2版本的用戶量依然不減罪佳，升級的積極性不高啊逛漫，可是現(xiàn)在發(fā)現(xiàn)V2.1.2的這個bug風險很大，一旦出問題要卷鋪蓋走人的地步赘艳，那就要強制更新了酌毡，可又不想影響V2.1.1和V2.1.3版本的用戶（對強制更新比較反感），此時想到要是能對V2.1.2一個版本強制更新就好了蕾管。備注：此場景只是一個假設(shè)枷踏，當然即便碰到這個假設(shè)，只要前期設(shè)計的合理都能解決掰曾，比如：
- 后端說我再多返回一個字段
forceUpdateList給你旭蠕，內(nèi)容為指定版本強制更新的版本號列表，只要當前版本在該列表中就強制更新旷坦。（此方案前端表示想哭） - 或者不想要強制更新的版本號列表也可以掏熬，給你個字段
forceUpdateVersion表示需要強制更新的版本信息,用正則匹配，如果匹配到的版本號就強制更新秒梅。（前端能做旗芬，后端也能做，看誰能說服誰了） - 可能也有人會說熱修復(fù)或者插件化表示不擔心捆蜀，那就繞過吧岗屏，此處目的是為了分析版本升級的最優(yōu)方案辆琅。
方案二(后端處理邏輯)：
在客戶端請求參數(shù)中添加當前版本號currentVersion傳輸給后臺，由后臺根據(jù)客戶端傳過來的當前版本號currentVersion做相應(yīng)的判斷后給出是否強制更新这刷。
后端邏輯如下：
- 根據(jù)是否有特殊需求可指定某個版本必須強制更新，如currentVersion == XXX,則forceUpdate = true;
- 如果currentVersion < newVersion,則isUpdate = true娩井；
- 如果currentVersion < minVersion,則forceUpdate = true暇屋；
- 如果currentVersion >= minVersion,則forceUpdate = false;
- 如果currentVersion == newVersion，則isUpdate = false.
后端邏輯對應(yīng)流程圖：
結(jié)論：
返回客戶端的字段僅需要apk下載url : apkUrl洞辣、更新文案 : updateDescription咐刨、是否有更新 : isUpdate 、 是否強制更新 : forceUpdate 這四個字段即可扬霜。如下表：
| 字段 | 字段描述 |
|---|---|
| apkUrl | apk下載url |
| updateDescription | 更新文案 |
| isUpdate | 是否有更新 |
| forceUpdate | 是否強制更新 |
總結(jié)：
細心的你可能會發(fā)現(xiàn)上面的可選字段apkSize和md5并沒有用到定鸟，既然是可選字段也就是可用可不用，根據(jù)需要決定是否采用著瓶，這里來講下他們的用處联予。
-
apk文件大小apkSize
這個用處可以說出于考慮用戶體驗，需要在升級彈框出來展示給用戶將要更新的內(nèi)容多大材原，讓用戶決定在非WIFI狀態(tài)是否要更新沸久，不能為了拉用戶下載量或所謂的UV數(shù)直接讓用戶在不知道大小的情況下去直接下載（土豪用戶繞路）。 -
apk的文件MD5值
這個主要是出于安全考慮吧余蟹，因為文件內(nèi)容固定的話對應(yīng)的md5是一樣的卷胯，我們可以通過這個md5值來和下載的apk的md5值進行比較去保證我們從服務(wù)器更新下載的apk是一個完整的未被篡改的安裝包，也就是說如果我們下載的apk的md5值和服務(wù)器返回的md5值相等威酒，則說明我們下載的apk是完整的窑睁，且沒有被相關(guān)有心人處理過的apk。
綜上所述葵孤，這個版本更新的處理邏輯客戶端和后端誰來做都可以担钮，無關(guān)乎懶不懶的問題，個人感覺靈活性后端比客戶端方便多了佛呻，當然客戶端也能做裳朋，只是客戶端做起來前期準備工作要考慮周全，各種場景都要考慮進去（還是會存在一些未知場景）吓著，不然只能下個版本實現(xiàn)了鲤嫡，考驗?zāi)阍O(shè)計能力的時候到了。以上純屬個人見解绑莺，如有更好的方案暖眼，歡迎指教。
2021期待與你一起共事纺裁，點擊查看崗位
