網易云音樂React Native體系建設與發展

本文作者：章偉東 （網易云音樂大前端團隊）

0.33 歷史

17 年 3 月份，為了解決商城性能和用戶體驗問題，云音樂技術團隊組建了一只 4 人 ReactNative 開發小分隊：我負責 RN 前端開發，安卓和 iOS 兩位開發負責在云音樂 App 里面嵌入 RN Native SDK，還有一位 Java 開發來負責部署平臺作業，

商城 RN 應用上線后，其他團隊表示有興趣嘗試，但當時 RN 專案開發沒有腳手架，專案創建通過原始拷貝進行，缺少 forweb 支持，RN 預加載只接入了 iOS 一端，

種種原因，導致 RN 開發效率低下，音樂人業務原本有興趣用 RN 來開發新應用，開發到一半改成了 H5，

從 17 年 3 月份到 19 年 9 月份，RN 版本始終為 0.33，核心開發團隊人員流失一半，部署平臺無人維護，專案開發缺少腳手架，缺少 forweb 支持，一共上線 RN 應用為 2.5 個（商城、音樂人、三元音箱），

攪動歷史

時間滾滾向前，新技術層出不窮，2 年半的時間對于前端發展來說，恍如隔世， 如果不出任何意外，RN 技術就會躺在歷史的塵埃里，無人問津，這種尷尬的局面，直到會員收銀臺到達率優化專案才被打破，

會員收銀臺頁面即下圖，是云音樂會員購買頁面，重要性不言而喻，這個頁面最開始是一個 React 服務端渲染開發的 H5 頁面，

為了能讓用戶更加順利購買會員，提高用戶體驗和到達率，整個技術團隊采用 web 通用優化技術結合云音樂自身技術設施，花了一個月對這個 H5 頁面進行優化，將到達率從 72% 提高到 89%，提高了 17 個百分點，與競品比較如下（單位是秒），

到達率計算公式= 收銀臺可視埋點/客戶端點擊埋點

雖然優化結果喜人，但是存在幾個問題：

1. 到達率目標未完成，當初技術團隊定的是至少 90% 以上，差了一個百分點，
2. ROI 太差，H5 優化投入了前后端開發眾多人力，花了將近一個月，如果再去優化其他頁面，目前方案自動化程度低，仍需大量人工操作，
3. 0.33 RN 到達率為 93%，我們統計了商城 RN 版本的到達率，未做任何優化，輕松破 90，

此時放在團隊面前有 3 條路：

1. 在 H5 頁面上投入更多資源優化，突破 90% 完成任務，但這種方案耗費大量的人力物力，對優化其他頁面用處不大，屬于一錘子買賣，
2. 在 RN 0.33 版本上重置收銀臺頁面， 這樣雖然能達到目標，但是 RN 基礎設施仍然停留在 3 年前，
3. 將 RN 基礎建設補齊，升級到最新 0.6 版本，實作三端方案，構建完整的 RN 開發體系，在此基礎上，基于 0.6 版本重置收銀臺，借助這個專案將 RN 整個技術堆疊更新換代，這種方案雖然收益大，但時間跨度長、困難大、復雜性高，

經過激烈討論和痛苦抉擇，團隊決定向更高目標發起沖擊，不滿足于只完成到達率目標，而是要重建整個 RN 技術體系，為以后的開發鋪平道路，一勞永逸解決整個前端開發的性能和體驗問題，

自動部署

舊部署平臺

原有 RN 部署平臺沒有實作自動部署，發布一個 RN 應用需要做以下事情

執行兼容性腳本

為了支持低版本如 iOS8，需要手動修改本地 node_modules 里面相關原始碼，

    sed -i -e 's/function normalizePrefix(moduleName: string)/const normalizePrefix = function(moduleName: string)/g' ./node_modules/react-native/Libraries/BatchedBridge/BatchedBridgedModules/NativeModules.js

    sed -i -e 's/function normalizePrefix(moduleName: string)/const normalizePrefix = function(moduleName: string)/g' ./node_modules/react-native/Libraries/Utilities/UIManager.js

    sed -i -e 's/function handleError(e, isFatal)/var handleError = function(e, isFatal)/g' ./node_modules/react-native/Libraries/JavaScriptAppEngine/Initialization/InitializeJavaScriptAppEngine.js

執行打包腳本

本地執行release.test.sh（測驗）和release.sh（線上），release 腳本分別呼叫 iOS 和 Android 打包腳本，然后打出對應的 bundle，

因為兩端 bundle 用同一個名字，所以很容易出現傳錯情況，每次上傳都小心翼翼，

上傳發布平臺

這里需要填寫相關內容，然后點擊發布，

可以看到上面三步有本地污染風險，操作繁瑣，容易遺漏步驟和填錯，

自動部署流程

針對上面手動部署缺陷，我們重新梳理和設計了整個自動部署流程

git 克隆 -> 依賴安裝 -> 自動腳本執行 -> 壓縮 -> 上傳檔案服務器 -> 保存版本資訊 -> 發布

然后用 Node 取代 Java 開發了新 RN 部署平臺

新 RN 部署平臺會自動處理兼容性、打包、上傳和發布作業，支持多環境，一鍵部署完成整個流程，

雙端預加載

RN 加載流程

• APP 先啟動 RN 容器，RN 容器從服務端請求 JSBundle，然后進行初步渲染，
• RN 頁面初始化完成后，向服務器發請求拿動態資料，完成剩下渲染邏輯

從上圖可以看出 JSBundle 請求是整個流程中性能瓶頸，
如果把加載 JSBundle 這個環節提前（在 App 初始化時觸發） ， 后續打開 RN 應用， App 會直接從本地加載資源包，極大提高用戶體驗和性能，

RN 離線包平臺

基于上述原因，我們設計了 RN 離線包服務平臺來負責 JSBundle 下發， 離線包服務和構建部署緊密相關，我們將 2 個平臺打通，在構建部署階段自動生成離線包，減少開發人員部署作業，

下面是 RN 自動部署平臺和離線包服務平臺整個流程圖

主要流程如下：

1. RN 自動部署平臺先構建出全量包，傳到 CDN 上，然后通知離線包服務平臺
2. 離線包服務平臺收到全量包資訊，用 diff 演算法算出差量包，存盤相關的資訊，發布差量包，
3. APP 啟動的時候訪問離線包服務，根據回傳的資訊來讀取本地快取還是去遠程取對應的全量包或差量包，

0.33 升級 0.6

升級作業主要分兩塊：RN Native SDK 升級 + RN 應用升級，

RN Native SDK 指的是集成在云音樂 App 里面 RN 相關原生代碼（iOS 和安卓原始碼）， 由于 0.33 版本和 0.6 版本無法同時兼容，所以我們對于老版本采取了只維護，不升級的策略，

RN 應用指的是例如商城、音箱這種業務應用，也可以等同于 JSBundle，應用升級必須趕在 SDK 升級之前完成，不然會出現 0.6 SDK 加載 0.3 應用的情況，導致 App 崩潰，所以，所有應用必須同時完成升級作業

升級面臨問題

依賴問題

RN 0.3 使用的是 React 15.3 版本，0.6 使用的是 16.8，除了 React 的依賴之外，還有其他依賴需要升級，我們根據官方提供 版本差異比較 創建了一個腳手架，讀取 package.json 里面資訊，一一比對，然后修改為對應版本，

廢棄組件

RN0.6 版本移除了 2 個組件：Listview 和 navigator-ios，

對于這種情況，如果我們用新組件比如 FlatList 重寫，不僅需要理解原來業務邏輯，還要修改原始碼，重新測驗，所以針對這種情況，團隊采取措施是：不改動現有代碼，從舊版本抽取對應組件，
最終，我們發布了@music/rn-deprecated-navigator-ios 和 @music/rn-deprecated-listview

語法兼容

RN 語法在 0.6 和 0.33 上不僅寫法不同，也不向下兼容，導致的結果就是 0.33 的 JSBundle 跑在 0.6 的 RN Native SDK 上會直接崩潰，下面以背景圖舉例說明，

在 0.33 中為了實作背景圖，是用Image包含一個View, 而到了 0.6 里面改成了ImageBackground，屬性也不同，

除了背景圖的語法需要修改之外，還有多少語法需要兼容修改我們不得而知，面對這種范圍不清楚，改動時間又非常緊張的情況，如果使用人工方式不僅效率低下進度也不可控，因此，我們采用了自動化的處理方式，推出了業界首個 RN codemod 框架 mrn-codemod

其主流程如下：

1. 利用框架先讀取 0.33 原始碼
2. 將 0.33 原始碼 轉為 AST 樹，
3. 對 0.33 AST 樹進行對應操作，轉化成 0.6 的 AST 樹，
4. 把 0.6 的 AST 樹重新生成原始碼，

整個框架一共處理了 12 條轉譯規則

此框架完成后，一天之內完成了所有 RN 應用升級，不僅保證準確性，減少人力成本和時間，還為今后升級提供了擴展，

3 端方案

當上面升級完成之后，團隊開始投入 3 端方案的研究，經調查主要有 3 種方式：直接轉換、橋接模式、底層構建，

直接轉換

因為 RN 與 React 只是渲染層面語法的不同，所以如果能夠將 RN 的語法直接翻譯為 React 語法，那么就可以將 RN 跑在瀏覽器上，

比如將 RN 的 View 轉為 React 的 div，RN 的點擊事件 onPress 轉為 React 的 onClick 等，

這種方案的缺點在于：

1. 作業量太大，RN 里面的View，Text，Image基礎組件非常多，
2. 無法做到一一對應，比如View里面有一個onStartShouldSetResponder方法，React 里面找不到對應事件，

橋接模式

對于 RN 應用，先找到一個支持 forweb 的 三方框架，然后把 RN DSL 轉為第三方框架的 DSL 達到最終目的，

這方面比較有代表性的就是 Taro 和 ReactXP，

Taro 根據 RN 規范自己實作了一套 DSL，對函式和事件做了自定義，

ReactXP 三端支持非常良好，但是組件非常少，也只好放棄，

底層構建

根據 RN 元素和組件定義，從最底層開始用 WEB 相關特性來實作整套 RN API，這個就是 react-native-web，這種方案也是目前業界主流模式，

我們對這個庫進行了封裝和擴展，添加了不支持的組件，修復了一些 bug，形成 @music/react-native-web-suffix，

新開發流程

我們在三端方案的基礎上開發了rn-cli腳手架，rn-util常用工具庫，rn-template工程初始化模板等配套工具，形成了一整套 RN 開發的基礎設施，目前新開發流程如下

rn-cli腳手架初始化的時候會呼叫 rn-template， rn-template 內置了 android，ios 和 web 開發容器及一些常用工程配置，集合了rn-util（處理請求，環境判斷，通用協議）和三端組件庫，

收銀臺 RN 重構結果

經過上述努力，收銀臺在 RN 0.6 版本上完成了重構，到達率從之前 H5（已優化） 89% 升至 99%，

現狀

隨著 RN 版本的提升，基礎建設完善，越來越多大前端開發人員在新專案中采用了 RN 技術堆疊，

目前已經上線了 10 多個 RN 應用，例如：

未來規劃

目前 RN 技術已經成為大前端重點發展方向，有專人專項來負責此事，后續的具體規劃圍繞性能、效率、監控三大方向展開，目標在這塊打造成業界第一梯隊，

現在有多個專項正在推進中

Native RPC

這個專項的主要目的是打通 RN bridge 和 JS bridge，可以讓一套資料通信機制同時支持 RN 和 web，

之前的 bridge 主要有 2 個問題：

1. 用法不一致，需要寫 2 套語法分別支持 RN 和 web，
2. 支持不一致，有的協議 web 有 RN 沒有，反之同樣，

所以，針對上面情況，大前端這邊統一了兩端 API，重構了底層協議來支持上面的功能，下面舉一個例子，

// 查看 net.nefetch 是否支持，
mnb.checkSupport({
    module: 'net',
    method: 'nefetch'
}).then(res => {

})

/* 手動添加方法 */
mnb.addMethod({
    schema: 'page.info',
    name: 'getPageInfo'
});

/* 添加之后即可呼叫 */
mnb.getPageInfo().then((result) => {
    // ...
}).catch((e) => {
    // ...
});

RN 和 web 兩端都是統一寫法，開發人員再也不用擔心兼容性問題，

RN 拆包

RN 應用在大部分主流機型上性能表現良好，但是在部分 Android 低端機出現卡頓現象，為了解決這個問題，啟動拆包專項，主要分成 2 部分，

1. 拆包，將現在的完整 JSBundle 拆成基礎包和業務包，分別載入，
2. 容器預加載，在 App 啟動的時候就預熱 RN 容器，這樣可以大幅度減少容器啟動時間，提高載入速度，

其他

除了上述專項之外還有 RN 大盤監控、RN 資源包定向下發、檔案規范等多個專項正在如火如荼的展開，

結束語

寫到這里，你是否好奇云音樂 App 里面 RN 的真物體驗如何，如果感興趣，請將云音樂 App 版本升級至最新進行體驗，

網易技術熱愛者隊伍持續招募隊友中！我們一直在招人，如果你恰好準備換作業，又恰好喜歡云音樂，那就發送簡歷至grp.music-fe@corp.netease.com！加入我們吧！