CodeHub#1 回顧 | 敏捷開發與動態更新在支付寶 App 內的實踐

做者介紹：古塘，目前主要負責支付寶框架和各個組件經過移動開發平臺 mPaaS 對外輸出工做，今天給你們分享的主題是敏捷開發與動態更新在支付寶 App 內的深度實踐。

活動推薦：CodeDay#1 線下沙龍杭州站已上線，具體活動信息及報名地址見文章尾部。

支付寶App的架構演進

首先來快速看一下支付寶的架構演進，支付寶在移動端躬耕多年，從簡單的工具型 App 到平臺型、到如今的超級 App。與目前市面上大部分 App 的發展路線相似，目前咱們構建平臺的同時，作了更多服務化、模塊化的工做。

針對支付寶在超級 App 方面方向下的架構優點，咱們總結了以下特色：

• 多應用的生態：不限於形式，原生模塊、離線包、小程序。 開放：底層同一個架構，業務很方便的遷移。
• 動態化：業務能夠隨時在線更新，無需發版，隨時響應線上活動，好比雙11、雙十二，春節掃福等活動
• 高可用、高性能、高靈敏度：完善的監控運維體系、發現問題後多層次的修復技術、客戶端良好的性能啓動體驗，強大的網絡性能，防刷抗流量等。

工程化挑戰

從工程化的角度來看，業務和團隊的快速發展也會帶來巨大的挑戰。支付寶的業務量在 1五、16 年後有一個指數級的增加，包括團隊人數、模塊數量，你們看如今的支付寶也不只僅是一個簡單的支付工具了，而是包含了各類各樣的業務，服務咱們的生活的方方面面。因此咱們須要一個靈活開放的架構來支撐多團隊的快速協同開發，須要創建超級 App 的運維體系。

業務複雜性帶來的技術挑戰 下面咱們快速看一下業務複雜性會帶來怎樣的技術挑戰，整體來講，分爲 4 個方面。

一、基礎能力要求更高：

好比支付寶的核心場景掃碼支付，有更好的識別率和識別速度，push 就是你們聽到的萌妹子語音：「支付寶到帳多少多少元」，這就涉及到要求咱們的框架怎麼作保活，怎麼提升推送到達率。 移動安全方面，做爲金融級的App，要作到防範黑產，各類羊毛黨。 應急和快速修復方面，這是咱們已經提到過的，框架須要快速響應線上問題，並提供相應的修復方案，能作到動態更新，最大程度的保證線上的穩定性。

2&三、性能和環境方面：

隨着業務體量的不斷增大，若是業務同窗無腦的把初始化放到啓動過程當中，必然會形成啓動時間的不斷增長，在使用過程當中，也很容易會產生電量、流量、內存、存儲等各類問題，形成線上輿情，網絡環境也是同樣，由於如今還在一些偏遠地區可能網絡不太好，弱網優化也是須要的，同時咱們也須要對千元機、低端機器保持友好，保證低端機的用戶體驗，因而乎，咱們急需良好的框架運維機制來支撐業務的快速發展和敏捷發佈

四、多 App 生態

這也正是咱們基於 mPaaS 作的對外輸出。支付寶這套框架不止是支付寶本身用，也須要快速賦能咱們的合做夥伴，你們都是統一的架構底層，支持業務之間的靈活聯動和快速擴張，這也是前面提到的超級 App 的技術特色。

架構現狀

接下來咱們來具體看一下支付App的架構現狀：

從下到上，分別是「容器層、組件層、框架層、服務層和應用層」

• 容器層：最底層的基礎層，管理這每一個模塊 bundle 的加載和資源的處理，在 Android 上和如今流行的插件化框架相似
• 組件層：是咱們抽離出來的通用組件，提供一些通用能力，好比網絡、緩存、日誌、圖像加載等等
• 框架層：這層和原生的 Android,iOS 系統 SDK 相似，是咱們定製的用來作每一個模塊 bundle 之間解耦、交互和通訊的基礎層，有 Native,H5 和圖上沒提到的小程序
• 服務層：咱們基於框架封裝的一些業務服務層，提供登陸、支付、LBS 等服務
• 最上面的就是應用層了：即用戶可見的具體業務，對於支付寶來講就是掃碼、轉帳、餘額寶等 因此說支付寶的框架有着明顯的分層結構，除了支付寶自己，螞蟻系內部的 App 也都是依託於此，好比網商銀行、螞蟻財富、口碑等，你們的 App 是底下這 4 層能夠作到幾乎同樣，惟一區別就是在應用層搭建不一樣的業務，並且由於是一樣的架構底層，同一個業務很方便的作多端遷移，好比你們比較喜好的餘額寶業務在支付寶裏有，在螞蟻財富App 裏也能看到，這套框架也依託於 mPaaS 平臺對外輸出，也歡迎你們體驗。

多種框架支撐

正如剛纔所說的，在支付寶內部會有多種框架支撐不一樣業務的併發開發和快速發佈，大體可分爲「Native 開發框架」、「Kylin H5 開發框架」以及「小程序開發框架」，具體的內容咱們會在後續展開。

靈活的開發框架

咱們認爲在支付寶內部開發業務，就像搭積木同樣輕鬆，具備不少特色：靈活性、擴展性等等

整體來講，你們都是並行開發，互相不影響，誰的版本有問題，能夠隨時回滾到穩定版本：所以積木和積木之間能夠作到很好的解耦，之間的交互就是經過前面講到的定製的框架層來通訊，一樣你也很方便地增長一塊新積木，自由擴展業務。

OSGI

OSGI 是 Java 作動態化模塊化的一系列思想規範，支付寶的框架設計也是借鑑了這個思想。

整體來講，在支付寶內部的每一個模塊工程咱們都稱之爲 bundle，在 Android 上的產物其實已是一個完整的 APK 安裝包了，只不過不能獨立運行，須要依賴底層框架和其餘模塊，在 iOS 上的產物也是一個具體的二進制 Framework 包，這樣打最終安裝包的過程其實就是前面提到的把各個積木搭起來的過程，只是二進制級別的合併，比較耗時的編譯的過程已經分散到各類積木的產生過程當中了，這樣作也能大大加快整個安裝包的打包速度。

以支付寶爲例，打完整的安裝包包含幾百個 bundle 的，在我這臺 14 年版的 Mac 上耗時也在 1 分鐘以內。

微應用和 service

接下來咱們來看看積木和積木之間，業務上是怎樣作交互的。咱們經過封裝 MicroApplication 和 service 來實現。

• MicroApplication：咱們認爲每個獨立的 bundle 其實就是一個小的 App，因此咱們也賦予了和系統 SDK 相似的生命週期代理方法，相似於 iOS 的應用 delegate 和 Android 的 application，經過 AppId 標識，能夠隨意跳轉到不一樣業務的 App，MicroApplication 相關的生命週期事件也會有相應的回調，不一樣的 bundle 之間徹底不用知道你有什麼 Activity 或者 viewController，只須要告訴我你的 AppId 標識，就能夠跳轉過去，就是說框架提供了全局的路由管理功能。
• Service：這個不一樣於 Android 上原生的 service 組件，經過框架中接口包的概念思想，很方便的實現對外暴露功能接口，有點相似於單例類的感受，區別是框架提供了完整的加載和調用管理，不用開發本身重複寫單例類造輪子。

Nebula

和市面上流行的 phoneGap (cordova)相似，都是 H5 混合開發解決方案，特色如圖所示：

除了提供基本的 H5 頁面的加載管理、和 Native 作通訊的 JSAPI 機制，還具有一些他們可能不具有的特色

• 1.離線包機制，解決 H5 加載的性能問題
• 2.統一的 UC 內核，解決 Android 上噁心的兼容性問題

體驗改善

首先，咱們來看H5加載，傳統意義上的H5，在進入的時候上面會有進度條或者轉菊花，體驗會不太好，咱們的容器是怎麼解決這個問題的呢？

離線包

離線包是將 HTML、JavaScript、CSS 等頁面內的靜態資源打包到一個壓縮包內，Nebula 使用一套基於 AppId 維度的本地文件管理方式，對離線包進行管理。這和前面提到的框架「積木的概念」一模一樣，每個離線包都是一個小積木，這個小積木能夠很方便的作到熱插拔，實現動態更新。

小程序

接下來讓咱們來看看小程序，看看標題仍是很唬人的，面向將來的研發方式。

你們有沒有想過這樣一個問題，爲何 H5 技術已經發展的相對來講比較成熟了，咱們還要推出小程序技術？

由於小程序能夠完美解決如今 H5 存在的一些問題：安全、性能、開發效率等各個方面。

• 拿性能舉例，雖然已經有了離線包技術能夠大大提高 H5 的加載性能，可是始終渲染出來的仍是 H5 頁面，受限於 webView，而小程序就徹底不同了，最終渲染的頁面，能夠是 H5，也能夠是 Native 頁面，能夠集成 RN、weex 相似的技術，實現原生渲染，並且小程序有本身的框架，能夠實現報活、資源預加載等各類優化手段，這些都是 H5 很難辦到的

你們能夠看如今支付寶裏的螞蟻森林，搶能量種樹那個，你們應該都玩過吧，當前的版本就是小程序實現，能夠體驗一下頁面的加載速度和滑動的效率等等，這已是一個比較複雜的帶動畫的業務了，均可以作到很好的用戶體驗。

小程序 IDE

同時小程序還有本身的 IDE，幫助開發者可以實現「編碼實時預覽、自動補全、語法提示」等，從而大大提高了開發效率：

研發流程

所以，基於前面介紹的各類開發框架，這裏能夠分享一下支付寶的研發流程，分爲「開發、測試、集成發佈」這些過程：

• 開發：建立本身的小積木
• 測試：驗證，經過和不經過
• 發佈：會有發佈經理這個角色，簡單的理解就是最終搭積木的那我的，會審批每一個積木到底能不能進最終的大架子，而後再進行各類灰度和發佈流程

高效交付：並行研發流程 + 動態更新

從大版本集中發佈到每一個小產品迭代開發，每一個小產品線維護本身的小版本，能夠控制本身的研發和發佈流程。

打包平臺

內部也會有 CI/CD 打包平臺的支撐，支撐着內部完成「多模塊並行開發、業務功能動態部署、線上問題熱修復」。

對於發佈平臺，咱們是怎麼作的呢？

• 不一樣的業務，能夠建立不一樣的發佈任務，能夠發佈到不一樣的版本
• 發佈產物：支持原生的升級包、熱修復包、離線包、小程序
• 發佈類型：內部灰度、外部灰度、正式發佈的維度展開灰度測試？
• 人羣過濾：支持不一樣維度的人羣過濾，按白名單、機型、rom 版本等

這裏還能夠說一下的是，咱們對於離線包這種發佈產物是支持差分機制。舉個例子，咱們有一個業務原先是 200K，改個背景邏輯變 210K 了，不必由於這 210K 去完整下發覆蓋，經過差分獲得補丁。固然，這裏的補丁大小不是 210K-200K 這樣簡單，但至少咱們能夠經過補丁機制從而達到最大程度地減小數據冗餘，提升總體覆蓋率。

總結：技術架構升級驅動研發方式轉變

總結來講，技術升級驅動研發方式產生轉變，從 Native 爲主的研發方式向動態化的研發方式進行轉變：

• 技術選型：原先咱們以 Native 爲主，少許獨立頁面使用 H5；如今咱們更推薦核心組件使用 Native（用戶高頻使用的場景），二級業務儘可能使用 H5 或者小程序；
• 發佈方式：目前基於「小步迭代」的選擇，不依賴客戶端發佈點，從而達到隨時發佈的能力；
• 研發效率：目前使用 Web 技術可以達到更開放的效果，一套 Web 代碼便可實現跨平臺的能力；
• 安裝包大小：相較於 Native，H5 可以有效地控制安裝包的大小。

敏捷發佈、保障穩定性

那麼總結一下，支付寶是怎麼敏捷發佈，並保障穩定性的呢？

• 開發測試：經過接口解耦與業務解耦，開發者只需關心本身的業務作好業務迭代和測試，集成以後驗證跑通便可。
• 灰度發佈：提供多方位的灰度策略：白名單、時間窗、應用版本號、系統版本號、手機型號等。
• 監控：監控主要聚焦穩定性的問題，包括「閃退、卡頓、卡死、業務異常」等狀況，當問題產生後咱們會基於動態修復的手段進行快速修復。相關的埋點監控模塊近期也在支付寶開放平臺開放出來，歡迎體驗。
• 動態修復：進行 Native 熱修復和配置下發。具體內容見後續展開。

超級 App 運維體系

所以咱們經過發佈、監控、診斷協同做戰，支持體系化運維，造成了所謂的超級 App 運維體系。

接下來咱們針對「診斷」展開，前面咱們提到的「監控」更多的是發現問題，而如何定位問題發生的緣由，是須要經過診斷來進行覈驗的。

診判定位

參考這張圖，咱們可以清晰地瞭解支付寶內部是如何進行問題診斷與定位：從「端到端的信息打通」到「全鏈路輔助到人」，「詳細信息拉取」後在進行相應的「診斷分析」，同時會配備具體的診斷策略。

所以，咱們能夠實現一鍵診斷用戶 App 日誌，具體界面以下：

AndFix

發現問題後，怎麼去修復問題，就要用到一些熱修復的手段了，好比這裏提到的 AndFix。

在 Android 上，AndFix 徹底是支付寶同窗自研的一套 Android 熱修復技術，15 年的時候已經在 GitHub 上開源。如今 star 數大概有 6000 多個，相信應該有同窗也接觸瞭解過，不過開源的版本略老，可是原理不變。

AndFix 能夠認爲是開創了 Android 熱修復 2 個流派之一的 Native 修復，原理是經過在 Native 端方法指針替換實現，修復的粒度是針對於方法，這樣從原理上來講至少有 2 大好處：

• 1 是補丁包比較小，由於是方法粒度；
• 2 是能夠作到實時生效，比較適合修復緊急 bug 這種熱修復場景；

另外一種比較流行的技術是經過類加載的機制，由於粒度是類級別，因此補丁包會相對來講大一點，且可能存在 dex 合併的性能損耗，並且由於 Android 虛擬機沒有類卸載機制，因此沒法作到實時生效，必定要重啓。

固然，沒有一種技術是萬能的，咱們內部也會存在着 dexPatch、instantRun 這種原理的修復技術，應對不一樣的場景

在 iOS 上，從最先的lua腳本到大名鼎鼎的 JSPatch，咱們內部都會有相似的方案，這個在 iOS 上其實最重要的我以爲不是技術問題，而是蘋果爸爸的政策問題，這裏就很少說了，你懂的。

多層次的修復技術

最後總結一下，必定要有多層次的修復技術，適應不一樣的業務場景。如圖所示：

移動開發平臺 mPaaS：對外輸出

最後，到了 One More Thing 的時候。前面咱們分享所涉及的全部技術手段目前都經過 mPaaS 平臺對外輸出：

「移動分析、消息推送、熱修復」三款組件近期在支付寶開放平臺上已獨立放出。若是你是移動開發者，且對 mPaaS 感興趣，趕忙上手試用吧：t.cn/ExXJGkP

| mPaaS 第一期線下沙龍 CodeDay#1 開放報名中：

• 活動主題：移動端高性能架構演進與跨平臺開發實踐

  本期邀請支付寶移動端技術專家，與你們面對面一同探討在跨平臺開發下的高可用、高性能架構演進與跨平臺開發、動態化更新實踐。

• 報名方式：進入活動頁進行報名；沒法到現場的同窗可經過釘釘搜索羣號「23124039」當即加入技術交流羣，屆時獲取直播地址，並有機會與講師在羣內深度交流。

期待你的參與。