自 iOS 及 Android 操作系統(tǒng)面世以來(lái)，移動(dòng)端的浪潮以極快的速度席卷了整個(gè)世界。而在這樣的時(shí)代演進(jìn)過(guò)程中，技術(shù)的不斷進(jìn)步和創(chuàng)新給移動(dòng)端的開發(fā)者們帶來(lái)了一次又一次的挑戰(zhàn)，比如不斷增長(zhǎng)的日活用戶、不斷刷新的版本分布、不斷碎片化的機(jī)型分布以及不斷碎片化的操作系統(tǒng)分布等。其中，隨著日活用戶的不斷增長(zhǎng)，微小概率的閃退使越來(lái)越多的用戶在體驗(yàn)上大打折扣。同時(shí)， App 版本分布的不斷增加亦加劇了代碼的碎片化，致使功能管理愈加復(fù)雜。

　　另一方面，手機(jī)型號(hào)與操作系統(tǒng)版本增多，也給移動(dòng)端開發(fā)者造成了不少困擾。特別是 Android 平臺(tái)，由于其開放性，導(dǎo)致了大量專項(xiàng)開發(fā)與優(yōu)化，增加了代碼管控的難度與復(fù)雜度，這也給移動(dòng)開發(fā)者提出了更高的挑戰(zhàn)。

　　面對(duì)這一系列技術(shù)挑戰(zhàn)，餓了么開啟了移動(dòng)基礎(chǔ)設(shè)施的建設(shè)工程，以應(yīng)對(duì)未來(lái)在移動(dòng)端所面臨的變化以及更多挑戰(zhàn)。本文將從以下幾個(gè)方面細(xì)談餓了么移動(dòng)基礎(chǔ)設(shè)施建設(shè)的實(shí)踐：

　　移動(dòng)端用戶體驗(yàn)的分級(jí)；

　　移動(dòng)基礎(chǔ)設(shè)施的概念；

　　餓了么移動(dòng)基礎(chǔ)設(shè)施的建設(shè)實(shí)踐。

　　移動(dòng)端用戶體驗(yàn)的分級(jí)

　　在這樣一個(gè)以用戶體驗(yàn)為王的時(shí)代，追求極致的用戶體驗(yàn)往往是產(chǎn)品經(jīng)理們追逐的最高夢(mèng)想。因此，更簡(jiǎn)化的流程、更炫酷的動(dòng)畫總是成為每次產(chǎn)品更新迭代的主角，從不會(huì)褪去其“No.1”的光環(huán)。

　　然而事實(shí)上，App 和過(guò)去 Web 時(shí)代的產(chǎn)品有著分明且本質(zhì)的區(qū)別，比如用戶更新意愿低、存在故障時(shí)難修復(fù)、視覺(jué)要求更高等。因此，在這樣一場(chǎng)追求 App 極致體驗(yàn)的戰(zhàn)爭(zhēng)中，移動(dòng)端的程序員兄弟們也應(yīng)該是并肩作戰(zhàn)的團(tuán)隊(duì)成員之一。因?yàn)榧夹g(shù)上的用戶體驗(yàn)，重要程度其實(shí)并不亞于以上的主角。

　　Level 1 能用

　　“能用”是每個(gè)用戶對(duì)于使用 App 最基本的訴求。但當(dāng)我們鐘愛(ài)的 App 在使用過(guò)程中遇到諸如內(nèi)存訪問(wèn)越界等特殊異常時(shí)，它往往會(huì)表現(xiàn)出一種最讓我們反感的現(xiàn)象——閃退，移動(dòng)端工程師們稱之為“Crash”。

　　這種讓 App 完全無(wú)法使用的情況是用戶最為惱火的場(chǎng)景。因此，如何最大限度地降低 App 的 Crash 率便成為了移動(dòng)端技術(shù)人員們追求的用戶體驗(yàn)最高核心。一款無(wú)法穩(wěn)定運(yùn)行的 App 當(dāng)然無(wú)法得到用戶的青睞！

　　Level 2 可用

　　“可用”，來(lái)自為用戶提供穩(wěn)定可靠的服務(wù)表述，這是比較容易理解的。設(shè)想一下，當(dāng)我們正在選擇美食時(shí)，卻提示網(wǎng)絡(luò)不可用；又或是頁(yè)面上的菊花轉(zhuǎn)了一分鐘也沒(méi)有出現(xiàn)想要的菜單，這些都會(huì)讓我們對(duì)這樣一款 App 產(chǎn)品失望。然而，“可用”卻又是比較難實(shí)現(xiàn)的一個(gè)等級(jí)。當(dāng)用戶量少、業(yè)務(wù)簡(jiǎn)單時(shí)，網(wǎng)絡(luò)的流量并不會(huì)對(duì)服務(wù)器端造成過(guò)大壓力；而隨著用戶量的增長(zhǎng)，不同地域、運(yùn)營(yíng)商、網(wǎng)絡(luò)環(huán)境的一點(diǎn)點(diǎn)小的抖動(dòng)，都會(huì)導(dǎo)致用戶網(wǎng)絡(luò)請(qǐng)求的不確定性。

　　因此，如何最大限度地保障網(wǎng)絡(luò)數(shù)據(jù)的穩(wěn)定性，讓我們的 App“可用”，是每天都在面臨的挑戰(zhàn)。

　　Level 3 好用

　　當(dāng)我們的 App 達(dá)成了“能用”和“可用”的體驗(yàn)后，便來(lái)到了第三個(gè)層次——“好用”。

　　與前兩者體驗(yàn)需求的不同之處在于，“好用”除了在產(chǎn)品上要求流程簡(jiǎn)單便捷外，同時(shí)也對(duì)動(dòng)畫效果提出了更高的要求。在技術(shù)上這往往表現(xiàn)為每秒刷新的“FPS”幀率達(dá)到一定數(shù)值，頁(yè)面切換無(wú)卡頓感，同時(shí) App 能夠在第一時(shí)間響應(yīng)用戶的觸摸操作等。

　　“好用”是對(duì)產(chǎn)品經(jīng)理以及應(yīng)用開發(fā)者在頁(yè)面性能優(yōu)化上的極致挑戰(zhàn)，是一個(gè)長(zhǎng)期追求，并不斷努力的終極目標(biāo)。

　　移動(dòng)基礎(chǔ)設(shè)施的概念

　　在以上的用戶體驗(yàn)分層概念中，我們可以看到，這種用戶體驗(yàn)的提升是不斷打怪升級(jí)的戰(zhàn)役，自然也少不了坎坷。在很長(zhǎng)一段時(shí)間內(nèi)，由于缺乏相應(yīng)的測(cè)試和監(jiān)控工具，App 端的問(wèn)題一度只能通過(guò)后端監(jiān)控來(lái)推斷。

　　為了更好地應(yīng)對(duì)這樣一系列與 App 相關(guān)的問(wèn)題，我們提出了建設(shè)移動(dòng)基礎(chǔ)設(shè)施的構(gòu)想。本節(jié)先來(lái)談?wù)勈裁词且苿?dòng)基礎(chǔ)設(shè)施。

　　我們都知道，一款 App 的研發(fā)流程大致可以總結(jié)為：

　　產(chǎn)品提出設(shè)計(jì)原型，UED 設(shè)計(jì)好視覺(jué)效果稿；

　　工程師針對(duì)設(shè)計(jì)稿件進(jìn)行編碼、Debug，完成開發(fā)；

　　工程師將開發(fā)好的程序進(jìn)行打包、發(fā)布；

　　App 產(chǎn)品正式上線并發(fā)布。

　　而在最近幾年，隨著 iOS 和 Android 的技術(shù)進(jìn)步，又出現(xiàn)了一系列線上熱修復(fù)技術(shù)，因此在以上的 App 研發(fā)流程中再添一員——“HotPatch 修復(fù)”。

　　再簡(jiǎn)單一點(diǎn)，可以直接歸納為：產(chǎn)品→開發(fā)→發(fā)布→線上→修復(fù)。

　　而移動(dòng)基礎(chǔ)設(shè)施（Mobile Infrastructure，我們稱之為“Minfra”）提供了除產(chǎn)品流程以外的一整套 App 研發(fā)管控的 SaaS 服務(wù)，即涉及開發(fā)、發(fā)布、線上和修復(fù)的全生命周期管控平臺(tái)。

　　餓了么移動(dòng)基礎(chǔ)設(shè)施建設(shè)的實(shí)踐

　　餓了么移動(dòng)技術(shù)團(tuán)隊(duì)在面對(duì)以上流程時(shí)，搭建了名為“Grand”的總體管控平臺(tái)，并分別建立相應(yīng)的管控模塊來(lái)進(jìn)行保障工作。接下來(lái)將分模塊談?wù)劽總€(gè)流程的具體細(xì)節(jié)。

　　持續(xù)集成

　　持續(xù)集成是每個(gè)互聯(lián)網(wǎng)公司基本都會(huì)部署的一道開胃菜，通過(guò)代碼倉(cāng)庫(kù)的“Webhook”操作來(lái)自動(dòng)觸發(fā)一次編譯構(gòu)造，從而快速定位該代碼集成是否會(huì)導(dǎo)致整個(gè)項(xiàng)目崩潰。這一步，是一項(xiàng)“掌控代碼”的操作。

　　對(duì)于持續(xù)集成的平臺(tái)搭建來(lái)說(shuō)，業(yè)內(nèi)最常用的便是“Jenkins”。通過(guò)簡(jiǎn)單的“job”配置就可以輕松跑起一款 App 的持續(xù)集成。同時(shí)它還具備強(qiáng)大的可擴(kuò)展性、簡(jiǎn)便的集群管控能力。也正因?yàn)檫@些優(yōu)點(diǎn)，我們最終選擇了“Jenkins”。

　　然而在餓了么，由于 App 數(shù)量眾多，且隨時(shí)可能會(huì)有新的 App 成員加入。于是乎，在這樣一種業(yè)務(wù)場(chǎng)景下，為每款 App 都單獨(dú)進(jìn)行一次自定義配置就成了奢望。如何使用一個(gè)“job”就能讓所有 App 都跑起來(lái)，是我們首要解決的問(wèn)題。

　　得益于“Jenkins”平臺(tái)的高度可自定義性，我們使用自己的 Python 腳本完成了持續(xù)集成的管控工作（如圖 1 所示），同時(shí)使用“Grand”平臺(tái)實(shí)現(xiàn)前端狀態(tài)的監(jiān)控工作。每款 App 使用一個(gè)預(yù)定義好的配置，來(lái)配合腳本內(nèi)預(yù)定義的不同打包行為，最終匯總結(jié)果于“Grand”平臺(tái)。

　　持續(xù)集成平臺(tái)的搭建，讓團(tuán)隊(duì)合作的代碼最終趨于穩(wěn)定狀態(tài)。完全自定義的腳本代碼，讓未來(lái)“靜態(tài)代碼檢測(cè)分析”、“自動(dòng)化測(cè)試平臺(tái)”的加入成為可能，真正實(shí)現(xiàn)了對(duì)代碼的掌控。

　　圖 1 Jenkins 管控頁(yè)面 Release

　　代碼已經(jīng) OK，功能也已完備，接下來(lái)就是接受千萬(wàn)用戶檢驗(yàn)的時(shí)刻了。在此，“發(fā)布”這個(gè)看起來(lái)最尋常、最微乎其微的功能服務(wù)，卻是發(fā)揮極大作用的功臣。我們前面提到，由于用戶量巨大，99.99%的 Crash 率也能給成千上萬(wàn)的用戶帶來(lái)困擾。為了最大限度地減少這種困擾，一個(gè)具備“灰度發(fā)布”的服務(wù)被賦予了非凡的意義。

　　圖 2 App 發(fā)布灰度配置信息

　　通過(guò)向特定的手機(jī)、城市甚至人群發(fā)送升級(jí)提醒，讓部分、少量的用戶升級(jí)至新 App（如圖 2 所示），以觀察這部分用戶的 Crash 率成為了我們防止大規(guī)模 Crash 最主要的解決方案之一。在灰度的過(guò)程中，一旦發(fā)現(xiàn) Crash 率快速上升，則可通過(guò)關(guān)閉“發(fā)布”渠道來(lái)防止事態(tài)的進(jìn)一步升級(jí)，讓“能用”這一用戶體驗(yàn)等級(jí)得到掌控。

　　看到這里，一定有讀者會(huì)產(chǎn)生疑問(wèn)，對(duì)于 Android 操作系統(tǒng)而言，以上方案或許可行，但對(duì)于 iOS 是否有更加可行的方案？

　　的確如此，對(duì)于 iOS 平臺(tái)而言，由于 App Store 的存在，往往很難達(dá)到灰度控制的目的。事實(shí)上，如果有條件的話，可以適當(dāng)?shù)夭捎?iOS 企業(yè)版來(lái)做灰度。不過(guò)這種方案并不被推薦，企業(yè)版也不是為該種目的而生，所以我們也并未完全采取這種方案。

　　另一種 iOS 的灰度渠道方案，則是在各大越獄社區(qū)進(jìn)行分發(fā)，同樣可以繞過(guò)某些監(jiān)管。當(dāng)然，由于安全性原因，也具備一定風(fēng)險(xiǎn)。因此，如何取舍還是得看讀者自己衡量。

　　HotPatch