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

本文介紹了雲音樂引入 React Native 0.33 版本歷史，RN 自動部署平臺和離線包服務平臺實現，0.33 版本如何升級到 0.6 版本，業界首個 RN codemod 框架推出，三端方案落地，基礎設施完善，RN 現狀及將來規劃。前端

本文做者：章偉東（網易雲音樂大前端團隊）node

0.33 歷史

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

商城 RN 應用上線後，其餘團隊表示有興趣嘗試，但當時 RN 項目開發沒有腳手架，項目建立經過原始拷貝進行，缺乏 forweb 支持，RN 預加載只接入了 iOS 一端。android

種種緣由，致使 RN 開發效率低下，音樂人業務本來有興趣用 RN 來開發新應用，開發到一半改爲了 H5。ios

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

攪動歷史

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

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

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

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

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

到達率目標未完成。當初技術團隊定的是至少 90% 以上，差了一個百分點。
ROI 太差。H5 優化投入了先後端開發衆多人力，花了將近一個月。若是再去優化其餘頁面，目前方案自動化程度低，仍需大量人工操做。
0.33 RN 到達率爲 93%。咱們統計了商城 RN 版本的到達率，未作任何優化，輕鬆破 90。

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

在 H5 頁面上投入更多資源優化，突破 90% 完成任務。但這種方案耗費大量的人力物力，對優化其餘頁面用處不大，屬於一錘子買賣。
在 RN 0.33 版本上重置收銀臺頁面。這樣雖然能達到目標，可是 RN 基礎設施仍然停留在 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 自動部署平臺和離線包服務平臺整個流程圖

主要流程以下：

RN 自動部署平臺先構建出全量包，傳到 CDN 上，而後通知離線包服務平臺
離線包服務平臺收到全量包信息，用 diff 算法算出差量包，存儲相關的信息，發佈差量包。
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

其主流程以下：

利用框架先讀取 0.33 源碼
將 0.33 源碼轉爲 AST 樹。
對 0.33 AST 樹進行對應操做，轉化成 0.6 的 AST 樹。
把 0.6 的 AST 樹從新生成源碼。

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

此框架完成後，一天以內完成了全部 RN 應用升級，不只保證準確性，減小人力成本和時間，還爲從此升級提供了擴展。

3 端方案

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

直接轉換

由於 RN 與 React 只是渲染層面語法的不一樣，因此若是可以將 RN 的語法直接翻譯爲 React 語法，那麼就能夠將 RN 跑在瀏覽器上。

好比將 RN 的 View 轉爲 React 的 div，RN 的點擊事件 onPress 轉爲 React 的 onClick 等。

這種方案的缺點在於：

工做量太大。RN 裏面的View，Text，Image基礎組件很是多。
沒法作到一一對應。好比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 個問題：

用法不一致。須要寫 2 套語法分別支持 RN 和 web。
支持不一致。有的協議 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 部分。

拆包。將如今的完整 JSBundle 拆成基礎包和業務包，分別載入。
容器預加載。在 App 啓動的時候就預熱 RN 容器，這樣能夠大幅度減小容器啓動時間，提升載入速度。

其餘

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

結束語

寫到這裏，你是否好奇雲音樂 App 裏面 RN 的真實體驗如何，若是感興趣，請將雲音樂 App 版本升級至最新進行體驗。

網易技術熱愛者隊伍持續招募隊友中！咱們一直在招人，若是你剛好準備換工做，又剛好喜歡雲音樂，那就發送簡歷至grp.music-fe@corp.netease.com！加入咱們吧！