責編：陳秋歌，關注前端開發領域，尋求報道或者投稿請發郵件chenqg#csdn.net。
歡迎加入“CSDN前端開發者”微信群，參與熱點、難點技術交流。請加群主微信「Rachel_qg」,申請入群，務必註明「公司+職位」。另可申請加入CSDN前端開發QQ群：465281214。

SDCC 2016 中國軟體開發者大會將於11月18日在北京京都信苑飯店召開，本屆大會彙集100＋講師，設定了12大專題論壇。本文作者QQ音樂&全民K歌高階工程師袁聰，已受邀擔任SDCC 2016前端開發專題演講嘉賓，分享全民K歌React Native最佳實踐。

以下內容為會前袁聰給大家帶來的營養小餐，技術大餐即將在

React Native（以下用RN簡稱代替）的開源是App開發的一個里程碑式的事件，它為App開發提供了新的開發模式和思路。RN既有傳統Hybrid框架的優勢，又提供了統一的Native體驗，吸引著越來越多的專案去實踐。

全民K歌去年十月份完成了RN的接入實踐，至此已經有一年多了。現在的我們已經不再滿足簡單的接入和優化，我們開始大膽嘗試，做一點不一樣的RN，今天我們來就聊一聊全民K歌不一樣的RN。

這裡先給大家上兩份小菜，

P.S. RN的程式碼已經被分析來分析去太多遍了，相關資料很多，為避免冗長枯燥，本文只提示基於0.35版本的關鍵程式碼。

Bundle拆分——業務分包

為什麼要分包？

• 避免執行大量JS程式碼帶來的效能瓶頸
• 減少更新時的流量消耗
• 業務分離，按需載入

關於效能瓶頸，我們先來看一張圖：

JS Init + Require的時間在整個RN的啟動過程中佔了約一半，隨著業務的增多以及複雜度的增加，這個比例還會上升。

流量消耗一直是使用者關注的重點，使用者關注的重點就是我們關注的重中之重，RN基礎的Bundle有1.5M，即使壓縮後也有300多K，業務Bundle的更新，往往只有幾K或者幾十K，帶上基礎Bundle這個大尾巴不太合適，分包可以為使用者節省不必要的流量消耗，而且在複雜的外網環境下，包越小越有利於更新成功率的提高。

業務分離，按需載入，非純RN的應用往往入口在不同的地方，不必一股腦的把所有業務模組一起載入，分包載入可以提升載入速度以及減少不必要的資源浪費。

RN自己提供了一個unbundle的方案，Android端把除了polyfill和startup部分之外的所有模組拆成大量的單獨js檔案，在引用到js檔案的時候通過NativeRequire方法去載入對應的js檔案，大量頻繁的I/O，Android表示已哭暈。。。而iOS端則是在頭部新增一堆index table用來做索引，反而會增大檔案。可能是還不成熟的原因，RN還沒有正式公開這個方案。而且這個方案不能區分業務，不能滿足我們的需求。

那麼全民K歌如何去實踐根據業務分包的？來看下前端同學馬鋮（Calvinma）的方案：

首先我們看到RN自帶的react-packager打包原始碼比較輕量簡潔，保持輕量和對RN特性關注也是RN不使用webpack和broswerify而是自己實現打包的原因。因此我們的方案主要是通過增強 react-packager的打包原始碼來實現分包（不造輪子）。

RN的打包結果是一套類似CommonJS的輕量require/define模組系統。要做到上面的檔案分離和不重複打包，就是要做到依賴引用（業務包去require基礎包中的模組）, 因此我們要把基礎包中包含的模組列表匯出來給業務包打包時使用，類似webapc中DllPlugin的實現。

所以分包的主要邏輯如下：

打包（Compile time）：

用一個base.js做Entry（包含認為是基礎庫的內容，比如RN核心、元件、React）打包出基礎包，並匯出包含的模組列表
根據基礎包模組列表打包業務包，過濾業務包的依賴：去掉重複的模組，require 時使用列表裡的模組id

客戶端執行（Run time）：

適當的時機在JSContext執行基礎包（比如App launch ready或者使用者進入某些場景、下一步可能開啟RN時)
使用者進入RN的部分，執行業務包，然後runApplication，適當的機制從 CDN 拉取更新業務包。我們學習一下webpack，把這份模組列表稱為manifest 。

一圖概括之：

這個方案的主要優點在於易施行，在本地打包時做文章，分離的包可以分開前後執行（不需要再在終端做合併）
分包靈活，自己通過Entry去控制基礎包裡要有什麼。不用單獨再寫構建
降低客戶端工作量，不用引入複雜的Diff和合並，只要實現可分開執行（runJSInContext和runApplication分離）就可以，RN的原始碼裡都有介面。

舉個栗子：

拿官方Hello World來演示下，先把所有公開的元件和API打到個基礎包裡：

base.android.js

輸出來的manifest.json大概長這個樣子:

再帶上這份manifest來打包原版的Hello World，最終生成的檔案如下：

surprise，業務Bundle就是這麼小。是不是等不及來看看怎麼實現的了？

下面分析一下分包涉及的原始碼修改和實現（原始碼根據0.35版本）：

首先我們在local-cli添加了兩個引數:

–manifest-output: 打包時把bundle包含的模組匯出生成為一個manifestFile(打基礎包)

–manifest-file : 打包時傳入指定的manifestFile進行過濾(打業務包)

local-cli/bundle/bundleCommandLineArgs.js

在打包生成時（拿到所有依賴模組列表後），如果有傳入manifestOutput，把模組列表按固定格式輸出一份JSON檔案(模組名: 模組id)

local-cli/bundle/output/bundle.js

packager/react-packager/src/Bundler/Bundle.js

在依賴解析中require模組時，如果有傳入manifestFile，require 已有的模組時使用manifestFile中對應的id。比較方便就是在getModuleId()中做一個處理。

packager/react-packager/src/Bundler/index.js

最後在打包前，如果有傳入manifestFile，從resolutionResponse按照其過濾掉已存在的模組。

packager/react-packager/src/Bundler/index.js

主要的原始碼涉及就是Bundler和Bundle部分，其次還有cli的新增，過濾掉polyfill的重複插入等。

需要注意的問題：

id重複：

目前的RN打包模組使用遞增數字id，分開打包時id就會重複。我的做法是把基礎包的最大id輸出來接著遞增，或者多個業務包時給id加字首（–id-prefix）。增強方案也可學習webpack使用filename hash做id。

好了，前端同學已經幫我們拆出來的多個Bundle，那麼客戶端怎麼去載入呢？

先來看下一個簡單的JavaScript VM模型：

JSContext是JavaScript執行的上下文，由GlobalObject管理。我們在同一個GlobalObject對應的同一個JSContext中執行JavaScript程式碼，執行一個和執行多個JavaScript是沒有區別的，所以上面多個包的載入完全沒有問題。

這裡不贅述RN的Bundle載入流程，最終用到了JSC的一個API——JSEvaluateScript去執行Bundle，我們只需要針對API封裝，提供一個方法給上層呼叫即可，當然注意執行順序，在基礎Bundle載入完再去執行業務Bundle，iOS和Android實現基本類似。

Native元件動態載入

聽說RN支援隨時發版，這麼好？先來一斤需求！

一開始聽到這種提問，第一反應是去解釋，RN提供了基礎的Native元件（這裡我們把Native Module和封裝的View統稱為Native元件），RN的動態釋出是基於已有的Native元件的動態釋出，我們可以根據業務的需要去擴充套件Native元件，但是不可能在一個版本里面把所有可能用到的Native元件都封裝好。後來原始碼讀得多了，也開始思考，是不是真的可以隨時無限制的去做需求？如何在不更新版本的基礎上如何讓RN真正的實現需求快速迭代開發，放飛產品同學們的想象力呢？

動態新增Native元件並將其動態載入。

動態新增Native元件，這對於iOS來說可能有點難度，但是對於Android，外掛和熱補丁大家都玩了這麼多年了，這只是個小問題，很容易解決。

那麼如何去動態載入Native元件呢？有幾種方法可以實現，

• 方法一：構建一個通用的代理NativeModule，傳遞需要執行的類名、方法名以及引數列表，通過反射去呼叫；
• 方法二：去了解NativeModule的註冊和呼叫流程，動態向其中新增新的Native元件。

方法一簡單易於實現，但是需要自己維護物件和構建引數，同時對JS非透明，應用Native版本升級時若想合入則需要多套JS程式碼對應於不同的呼叫方式，版本控制比較麻煩。

方法二實現難度稍大，沿用RN的設計，對JS透明，應用Native版本升級可以隨之合併進最新APK中。

鑑於以上原因，我們更傾向於方法二。下面就讓我們來看看RN是如何完成Native Module的註冊以及JS如何去呼叫Native Module的（這裡不帶大家走一遍完整的啟動流程和Native、JS互調的原始碼邏輯了，大家可以在網上搜到很多這類的文章，已經被解釋得都很詳盡）。

1.JNI層中ModuleRegistryHolder的建構函式中傳入了Java層用JavaModuleWrapper封裝過的NativeModule列表，將其構造JavaNativeModule容器物件傳入ModuleRegistry的建構函式中，儲存在其成員變數modules_中。

//ModuleRegistryHolder.cpp

ModuleRegistryHolder::ModuleRegistryHolder(
    CatalystInstanceImpl* catalystInstanceImpl,
    jni::alias_ref<jni::JCollection<JavaModuleWrapper::javaobject>::javaobject> javaModules,
    jni::alias_ref<jni::JCollection<CxxModuleWrapper::javaobject>::javaobject> cxxModules) {
  std::vector<std::unique_ptr<NativeModule>> modules;
  ...
  for (const auto& jm : *javaModules) {
    modules.emplace_back(folly::make_unique<JavaNativeModule>(jm));
  }
  ...

  registry_ = std::make_shared<ModuleRegistry>(std::move(modules));
}

//ModuleRegistry.cpp

ModuleRegistry::ModuleRegistry(std::vector<std::unique_ptr<NativeModule>> modules)
    : modules_(std::move(modules)) {}

這裡需要留意的是ModuleRegistry中的moduleNames()函式，這是一個關鍵的方法，返回值是所有NativeModule方法的名字，這在後面向JS中註冊NativeModule時舉足輕重。

//ModuleRegistry.cpp

std::vector<std::string> ModuleRegistry::moduleNames() {

  std::vector<std::string> names;
  for (size_t i = 0; i < modules_.size(); i++) {
    std::string name = normalizeName(modules_[i]->getName());
    modulesByName_[name] = i;
    names.push_back(std::move(name));
  }
  return names;
}

2.initializeBridge是一個複雜的過程，它構建了Native和JS相互呼叫的通道。Native通過NativeToJsBridge中呼叫JSC的API去執行JS方法，而JS則呼叫在JavaScript VM中註冊的JNI方法，通過JsToNativeBridge去執行Native方法。這裡我們要去JSCExecutor的建構函式裡面去看看NativeModule註冊的相關邏輯。

//JSCExecutor.cpp

JSCExecutor::JSCExecutor(std::shared_ptr<ExecutorDelegate> delegate,
                         std::shared_ptr<MessageQueueThread> messageQueueThread,
                         const std::string& cacheDir,
                         const folly::dynamic& jscConfig) throw(JSException) :
    m_delegate(delegate),
    m_deviceCacheDir(cacheDir),
    m_messageQueueThread(messageQueueThread),
    m_jscConfig(jscConfig) {
  initOnJSVMThread();

  SystraceSection s("setBatchedBridgeConfig");

  folly::dynamic nativeModuleConfig = folly::dynamic::array();

  {
    SystraceSection s("collectNativeModuleNames");
    std::vector<std::string> names = delegate->moduleNames();
    for (auto& name : delegate->moduleNames()) {
      nativeModuleConfig.push_back(folly::dynamic::array(std::move(name)));
    }
  }

  folly::dynamic config =
    folly::dynamic::object
      ("remoteModuleConfig", std::move(nativeModuleConfig));

  SystraceSection t("setGlobalVariable");
  setGlobalVariable(
    "__fbBatchedBridgeConfig",
    folly::make_unique<JSBigStdString>(detail::toStdString(folly::toJson(config))));
}

initOnJSVMThread()函式去建立了JavaScript VM、JSContext、Global物件以及向其中註冊了JNI方法。

在initOnJSVMThread()之後，出現了一個我們熟悉的方法moduleNames()，這裡拿到所有的NativeModule的名字之後，構建JSON，賦值給Global中的__fbBatchedBridgeConfig物件，完成了NativeModule向JS的初步註冊。

3.JS中新建MessageQueue物件，通過在JSCExecutor寫入的__fbBatchedBridgeConfig物件去構建remoteModules，這樣就把NativeModule對映到JS中了，但這還遠遠沒有結束。

 //BatchedBridge.js

const BatchedBridge = new MessageQueue(() => global.__fbBatchedBridgeConfig);

//MessageQueue.js

type Config = {
  remoteModuleConfig: Object,
};

class MessageQueue {
  constructor(configProvider: () => Config) {
    ...
    lazyProperty(this, 'RemoteModules', () => {
      const {remoteModuleConfig} = configProvider();
      const modulesConfig = remoteModuleConfig;
      return this._genModules(modulesConfig);
    });
  }
  ...
  }

function lazyProperty(target: Object, name: string, f: () => any) {
  Object.defineProperty(target, name, {
    configurable: true,
    enumerable: true,
    get() {
      const value = f();
      Object.defineProperty(target, name, {
        configurable: true,
        enumerable: true,
        writeable: true,
        value: value,
      });
      return value;
    }
  });
}

_genModules(remoteModules) {
    const modules = {};
    remoteModules.forEach((config, moduleID) => {
      // Initially this config will only contain the module name when running in JSC. The actual
      // configuration of the module will be lazily loaded (see NativeModules.js) and updated
      // through processModuleConfig.
      const info = this._genModule(config, moduleID);
      if (info) {
        modules[info.name] = info.module;
      }
      ...
    });
    return modules;
  }

4.NativeModules是不是很熟悉？JS就是通過NativeModules.類名.方法名去呼叫NativeModule的。這裡通過去remoteModules中查詢NativeModule並且呼叫JNI方法去獲取到NativeModule的方法等資訊，完成構建NativeModules物件。

//NativeModules.js

const NativeModules = {};
Object.keys(RemoteModules).forEach((moduleName) => {
  Object.defineProperty(NativeModules, moduleName, {
    configurable: true,
    enumerable: true,
    get: () => {
      let module = RemoteModules[moduleName];
      if (module && typeof module.moduleID === 'number' && global.nativeRequireModuleConfig) {
        const config = global.nativeRequireModuleConfig(moduleName);
        module = config && BatchedBridge.processModuleConfig(config, module.moduleID);
        RemoteModules[moduleName] = module;
      }
      Object.defineProperty(NativeModules, moduleName, {
        configurable: true,
        enumerable: true,
        value: module,
      });
      return module;
    },
  });
});

看到這裡想必大家都已經明白了，想要去動態載入NativeModule，只需要：

• 1）在ModuleRegistry的modules_變數中增加新的NativeModule
• 2）呼叫moduleNames更新modulesByName_同時得到moduleID
• 3）執行程式碼向JS中MessageQueue物件的RemoteModules中新增新的NativeModule描述
• 4）執行程式碼向JS中的NativeModules物件新增新的NativeModule描述

主要程式碼：

在NativeModules.js中為global添加了新的function，以便在JNI中呼叫該方法去動態向NativeModules物件中新增新的NativeModule描述：

//NativeModules.js

global.__UPDATE_NATIVE_MODULE__=function(moduleName){
Object.defineProperty(NativeModules,moduleName,{
configurable:true,
enumerable:true,
get:function get(){
var module=RemoteModules[moduleName];
if(module&&typeof module.moduleID==='number'&&global.nativeRequireModuleConfig){
var config=global.nativeRequireModuleConfig(moduleName);
module=config&&BatchedBridge.processModuleConfig(config,module.moduleID);
RemoteModules[moduleName]=module;
}
Object.defineProperty(NativeModules,moduleName,{
configurable:true,
enumerable:true,
value:module});

return module;
}});

};

在JSCExecutor中增加函式，向JS中的RemoteModules新增元素以及執行JS方法去更新NativeModules，此處要注意在JS執行緒中去操作：

//JSCExecutor.cpp

void JSCExecutor::addNativeModuleDynamically(){
          std::vector<std::string> names = m_delegate->moduleNames();
          int index = (int)names.size() - 1;
          const char* moduleName = names[index].c_str();
          m_messageQueueThread->runOnQueue([this, moduleName, index] () {
              auto global = Object::getGlobalObject(m_context);
              auto batchedBridgeValue = global.getProperty("__fbBatchedBridge");
              auto batchedBridge = batchedBridgeValue.asObject();
              auto remote = batchedBridge.getProperty("RemoteModules").asObject();
              auto empty = JSObjectMake(m_context, NULL, NULL);
              JSObjectSetProperty(m_context, empty, String("moduleID"),
                                  JSValueMakeNumber(m_context, index), 0, NULL);
              remote.setProperty(moduleName, Value(m_context, empty));
              auto nativemodules = global.getProperty("__UPDATE_NATIVE_MODULE__").asObject();
              nativemodules.callAsFunction(
                      {Value(m_context, JSStringCreateWithUTF8CString(moduleName))});
          });
        }

以上就是在RN原始碼讀完後的一點思考，一點拙見，在構建更快更易擴充套件的RN應用的實踐。如有不足之處歡迎大家斧正。

相關文章：

目前SDCC 2016前端開發專題的所有演講嘉賓已全部確定，以下為嘉賓名單及演講議題（排名不分先後），詳情請見：SDCC 2016前端開發專題講師、議題大揭底。

• Stackla前端團隊Leader蔣定宇
  
  • 演講主題：不斷歸零的前端人生
• QQ音樂&全民K歌高階工程師袁聰
  
  • 演講主題：全民K歌React Native最佳實踐
• 餓了麼Node Team負責人黃鼎恆
  
  • 演講主題：純手工搭建一個高效能實時監控系統
• 360奇舞團前端工程師鍾恆
  
  • 演講主題：使用Vue.js 2.0開發高互動Web應用
• Ruff架構師、JavaScript專家周愛民
  
  • 演講主題：有前端思想的物聯網系統架構
• 58到家高階前端工程師周俊鵬
  
  • 演講主題：基於webpack的前端工程解決方案

想與這些專家現場面對面進行技術探討嗎？目前SDCC 2016大會門票8折銷售中，團購更有優惠，是給辛勤工作一年的你，年終最好的禮物，或許這樣，SDCC才能更真切地服務好開發者。【註冊參會】