背景
現(xiàn)有的項(xiàng)目中，App的升級率不高，雖然中間存在多個強(qiáng)升版本，但是依舊大量存在低版本的用戶。輕(比如小bug)則影響用戶體驗(yàn)從而損失用戶，重(比如支付購買類嚴(yán)重漏洞被利用)則影響公司收益。
分析
可以從兩方面來分析此問題。1.原生代碼層面，2.接口層面。
原生代碼層面分析
可能性1：很多App請求升級接口的邏輯往往放在進(jìn)入App首頁的時候，如果網(wǎng)絡(luò)調(diào)用失敗，則App可以繼續(xù)使用。
解決方案1：可以將上次請求成功的數(shù)據(jù)進(jìn)行緩存，如果調(diào)用失敗則使用緩存數(shù)據(jù)。
缺點(diǎn)1：如果升級策略回滾，則線上用戶仍然使用緩存數(shù)據(jù)去升級
缺點(diǎn)2：首次無緩存的時候，如果斷網(wǎng)，仍然可以繞過
解決方案2：監(jiān)聽網(wǎng)絡(luò)連接，如果請求失敗，在連接上之后，再次請求接口
優(yōu)點(diǎn)：開發(fā)量小，后端資源消耗少
缺點(diǎn)：如果是服務(wù)端臨時性問題，沒法解決（一般情況可忽略此情況）
解決方案3：所有接口添加版本校驗(yàn)邏輯，再返回統(tǒng)一錯誤碼，手機(jī)端針對錯誤碼統(tǒng)一處理
優(yōu)點(diǎn)：覆蓋全
缺點(diǎn)1：后端開發(fā)量大，如果是新項(xiàng)目，可忽略，如果是舊項(xiàng)目，慎用
缺點(diǎn)2：所有接口都檢查，如果同一時間請求多個接口，則造成資源浪費(fèi)。
解決方案4：同上，但是只是主要流程添加校驗(yàn)邏輯，比如登錄、支付等主流程
優(yōu)點(diǎn)：解決了方案3的缺點(diǎn)
解決方案5：開啟一個service，在service中請求更新接口，如果失敗，按照時間指數(shù)遞增，延遲重新獲取（2、4、8、16、32、64、128、256、512、1024，單位：秒，可設(shè)置次數(shù)閥值）直至成功
缺點(diǎn)：如果這幾次都沒成功，同樣可繞過，可以增加閥值大小，也可以達(dá)到一定時間長度之后，不要以指數(shù)增長，比如2、4、8、16、32、64、128、256、512、1024、1024、1024...
總結(jié)：以上方案都可行，根據(jù)自身情況具體問題具體分析
可能性2：彈出框在強(qiáng)制升級的時候可以取消
解決方案：設(shè)置為不可取消的對話框
可能性3：強(qiáng)制升級的時候，升級過程中（下載、安裝等過程），返回App，強(qiáng)制升級框消失
解決方案1：升級框設(shè)為不可取消，點(diǎn)擊升級的時候，升級框也不會消失
解決方案2：在resume生命周期中添加對應(yīng)邏輯，確保強(qiáng)升過程中，返回App，升級框再次展示
接口層面分析
可能性1：Android多個渠道配置因人為原因，導(dǎo)致漏配或者忘配
解決方案1：人員培訓(xùn)（和技術(shù)無關(guān)）
解決方案2：漏配或者忘配的渠道，走兜底方案，取默認(rèn)官網(wǎng)渠道的配置（注意：渠道變更可能會涉及運(yùn)營統(tǒng)計(jì)數(shù)據(jù)異常，謹(jǐn)慎采用）
可能性2：升級只考慮最新數(shù)據(jù)，沒有兼容舊的強(qiáng)升數(shù)據(jù)
現(xiàn)象：比如當(dāng)前手機(jī)版本為1，2為強(qiáng)制升級版本，3為非強(qiáng)制升級版本。從1到3，應(yīng)該返回強(qiáng)制升級，目前返回非強(qiáng)制
解決方案：修改對應(yīng)邏輯，如果最新的是非強(qiáng)制，則還要去匹配舊的數(shù)據(jù)，直至匹配到強(qiáng)升數(shù)據(jù)為止
更多考慮
后端
1.版本比對（可以在后端處理，也可以在前端處理）
分析：Android有兩個字段代表版本，versionCode和versionName。versionCode：整型，比對非常簡單。versionName，常見的是x.x.x的格式，但是需要考慮x.x.x.x和xx.xx.xx的格式
2.是否需要區(qū)分pad和phone
分析：有些App pad和phone是兩套代碼，線上的版本號不一致，則需要單獨(dú)區(qū)分處理
3.考慮強(qiáng)制和非強(qiáng)制交替出現(xiàn)的情況
分析：正如上面所說，最新版是非強(qiáng)制升級，但是一旦中間存在強(qiáng)制版本，而低版本請求的時候返回的卻是非強(qiáng)制，那么對用戶側(cè)影響非常大。一旦中間存在重大漏洞，則會對公司造成經(jīng)濟(jì)損失。
4.是否需要區(qū)分不同渠道
分析：大部分Android應(yīng)用會存在多個渠道，多的甚至達(dá)到幾十個?？赡苡行┣缹徍藭r間差異或者某些其他原因，就需要針對某些渠道做單獨(dú)的升級邏輯。
5.是否需要指定版本
分析：一般情況下強(qiáng)制升級的版本很少，普遍都是非強(qiáng)制。比如微信QQ等，很少見強(qiáng)制升級。如果某些舊版本存在致命級別的bug，但是最新版產(chǎn)品要求是非強(qiáng)制升級，這就需要針對有bug的舊版本做強(qiáng)制升級的處理。
既然能夠支持指定版本，那么也要支持指定多個版本，因?yàn)椴豢赡苤挥?個版本存在致命問題。
6.是否需要指定某一范圍內(nèi)的版本
分析：同上，某一個致命級別bug藏的夠深，存在于多個版本，則需要對涉及的版本做個范圍處理
7.考慮是否灰度
分析：一個新功能/技術(shù)改造的上線，可能會存在重大bug，如果一下子全量上線，會影響全部用戶。采用灰度功能，可以先從部分用戶開始，將問題暴露出來，集中整改，再發(fā)新版本或者熱修復(fù)，從而減少對用戶的影響。
問題1：但是app一般情況下可以由接口控制升級，也可以由應(yīng)用市場控制升級，所以沒法控制應(yīng)用市場的灰度邏輯
問題2：灰度邏輯是否針對到user，很多情況下升級接口在登錄/未登錄都可以請求，未登錄的情況下沒法指定到人?？梢允褂胻oken，或者未登錄的情況下不能請求灰度的版本，可以根據(jù)業(yè)務(wù)需求具體分析。
手機(jī)端
1.可以直接走應(yīng)用市場更新，點(diǎn)擊升級的時候，跳轉(zhuǎn)到指定應(yīng)用市場，指引用戶升級。
2.可以直接走app下載，則需要考慮是否加入斷點(diǎn)續(xù)傳，以及md5校驗(yàn)的功能，因?yàn)楹芏嗲闆r下會出現(xiàn)重復(fù)下載、安裝解析失敗等原因。如果apk文件是放到oss阿里云上的話，這些邏輯oss的sdk都已經(jīng)支持。
總結(jié)：
一個健全的系統(tǒng)，應(yīng)該要考慮以下幾點(diǎn)（甚至更多我沒有考慮到的地方），然后結(jié)合自身業(yè)務(wù)，最終采用其中的某些點(diǎn)。升級邏輯的控制粒度盡量要細(xì)，一旦有問題，降級策略也好針對性處理，對用戶的影響就小。
手機(jī)端
1.考慮請求升級接口的時機(jī)
2.版本比對如果使用versionName的話需要考慮x.x.x.x和xx.xx.xx
3.考慮跳轉(zhuǎn)市場升級，還是自行下載apk升級
4.強(qiáng)制升級框如果不點(diǎn)升級，不應(yīng)該被取消（包括進(jìn)入后臺再進(jìn)入前臺、下載的時候返回、安裝的時候返回等等情況）
5.下載是否考慮斷點(diǎn)
6.下載是否考慮校驗(yàn)文件正確性
后端
1.版本比對如果使用versionName的話需要考慮x.x.x.x和xx.xx.xx
2.是否需要區(qū)分pad和phone
3.是否需要區(qū)分不同渠道
4.是否需要針對指定版本、多個指定版本、版本范圍，做特殊處理
5.考慮強(qiáng)制和非強(qiáng)制交替出現(xiàn)的情況
6.考慮是否灰度
7.針對漏配考慮是否添加兜底方案
8.針對非強(qiáng)制，可以考慮添加每日彈框次數(shù)功能
補(bǔ)充說明
正常的版本更新，往往非強(qiáng)制要多于強(qiáng)制升級。
如果是非強(qiáng)制升級，則可以支持大于指定版本、小于指定版本、等于（1或N個）指定版本做非強(qiáng)制升級處理。同時會存在針對某些有致命bug的版本做強(qiáng)制升級處理，比如大于指定版本，小于指定版本，等于（1或N個）指定版本
如果是強(qiáng)制升級，則可以支持大于指定版本、小于指定版本、等于（1或N個）指定版本做強(qiáng)制升級處理，同時不應(yīng)該存在非強(qiáng)制升級的版本判斷
