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

　　另一方面，手機型號與操作系統版本增多，也給移動端開發者造成了不少困擾。特別是 Android 平臺，由于其開放性，導致了大量專項開發與優化，增加了代碼管控的難度與復雜度，這也給移動開發者提出了更高的挑戰。

　　面對這一系列技術挑戰，餓了么開啟了移動基礎設施的建設工程，以應對未來在移動端所面臨的變化以及更多挑戰。本文將從以下幾個方面細談餓了么移動基礎設施建設的實踐：

　　移動端用戶體驗的分級；

　　移動基礎設施的概念；

　　餓了么移動基礎設施的建設實踐。

　　移動端用戶體驗的分級

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

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

　　Level 1 能用

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

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

　　Level 2 可用

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

　　因此，如何最大限度地保障網絡數據的穩定性，讓我們的 App“可用”，是每天都在面臨的挑戰。

　　Level 3 好用

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

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

　　“好用”是對產品經理以及應用開發者在頁面性能優化上的極致挑戰，是一個長期追求，并不斷努力的終極目標。

　　移動基礎設施的概念

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

　　為了更好地應對這樣一系列與 App 相關的問題，我們提出了建設移動基礎設施的構想。本節先來談談什么是移動基礎設施。

　　我們都知道，一款 App 的研發流程大致可以總結為：

　　產品提出設計原型，UED 設計好視覺效果稿；

　　工程師針對設計稿件進行編碼、Debug，完成開發；

　　工程師將開發好的程序進行打包、發布；

　　App 產品正式上線并發布。

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

　　再簡單一點，可以直接歸納為：產品→開發→發布→線上→修復。

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

　　餓了么移動基礎設施建設的實踐

　　餓了么移動技術團隊在面對以上流程時，搭建了名為“Grand”的總體管控平臺，并分別建立相應的管控模塊來進行保障工作。接下來將分模塊談談每個流程的具體細節。

　　持續集成

　　持續集成是每個互聯網公司基本都會部署的一道開胃菜，通過代碼倉庫的“Webhook”操作來自動觸發一次編譯構造，從而快速定位該代碼集成是否會導致整個項目崩潰。這一步，是一項“掌控代碼”的操作。

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

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

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

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

　　圖 1 Jenkins 管控頁面 Release

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

　　圖 2 App 發布灰度配置信息

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

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

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

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

　　HotPatch

相關電子資料下載

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