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

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

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

　　移動端用戶體驗的分級；

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

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

　　移動端用戶體驗的分級

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

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

　　Level 1 能用

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

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

　　Level 2 可用

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

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

　　Level 3 好用

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

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

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

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

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

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

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

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

　　工程師針對設(shè)計稿件進(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ù)”。

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

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

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

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

　　持續(xù)集成

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

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

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

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

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

　　圖 1 Jenkins 管控頁面 Release

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

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

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

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

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

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

　　HotPatch

相關(guān)電子資料下載

• iOS17.1可能明天發(fā)布，iOS17.1主要修復(fù)哪些問題？ 380
• 講一講Apple Macintosh處理器過渡的故事 200
• 為什么使用KT6368A藍(lán)牙芯片用app連接，基本都在5分鐘左右后斷開 17
• 易云系統(tǒng)搭建智慧檔案室打造“數(shù)字化+標(biāo)準(zhǔn)化”檔案管理新模式 504
• 智能檢測、輕松操作—In-Sight SnAPP視覺傳感器 297
• 基于MacroBenchmark的性能測試量化指標(biāo)方案 77
• STM32WB如何一次性燒寫FUS+STACK+APP？ 1310
• 應(yīng)用筆記 | STM32WB如何一次性燒寫FUS+STACK+APP 102
• Netapp數(shù)據(jù)恢復(fù)—Netapp存儲數(shù)據(jù)恢復(fù)案例 76
• SpringBootApplication是什么 201