- (instancetype)initWithFrame:(CGRect)frame bridge:(RCTBridge *)bridge moduleName:(NSString *)moduleName initialProperties:(nullable NSDictionary *)initialProperties;

其中最重要的參數(shù)是bridge和moduleName，moduleName前面提到過，它是JavaScript代碼中使用AppRegistry.registerComponent注冊的組件名。我們的重點(diǎn)是bridge，它是React Native中最核心的東西。bridge顧名思義就是“橋”的意思，它發(fā)揮的作用也恰恰和橋一樣：它是JavaScript和Objective-C之間的一座橋，用來實(shí)現(xiàn)JavaScript和Objective-C之間的相互調(diào)用。

這里不深究bridge。但是我們需要知道，bridge創(chuàng)建時，需要去加載和執(zhí)行JavaScript代碼。沒錯，就是上面打包的400多kb，400多行的JavaScript代碼。bridge會創(chuàng)建一個JavaScriptCore上下文，然后從頭到尾執(zhí)行這份JavaScript代碼，執(zhí)行完畢后，React Native中的各種變量就存在這個上下文中了（例如AppRegistry對象），就準(zhǔn)備好隨時被Objective-C調(diào)用。

RCTRootView的源碼比較簡單，它主要做的事情是：

1. 創(chuàng)建并持有bridge;
2. 監(jiān)聽JavaScript的執(zhí)行情況；
3. 當(dāng)監(jiān)聽到JavaScript代碼執(zhí)行完畢后，通過bridge調(diào)用JavaScript中的AppRegistry模塊的runApplication方法，隨后就開始進(jìn)行用戶界面構(gòu)建了。

bridge淺析

React Native目前是通過bridge來實(shí)現(xiàn)JavaScript和Objective-C之間相互調(diào)用的，所以bridge是React Native的核心。但是bridge比較復(fù)雜，而且新的架構(gòu)已經(jīng)發(fā)布了，目前的bridge（React Naitve 0.68.1）將會被淘汰，所以這里只會簡單分析一下當(dāng)前bridge的特點(diǎn)。

批量處理的bridge

RCTRootView的bridge是一個RCTBridge對象。RCTBridge的實(shí)際功能是由其內(nèi)部變量batchedBridge實(shí)現(xiàn)的（目前batchedBridge是一個RCTCxxBridge對象）。batchedBridge，可以翻譯為“批量處理的橋”，通過閱讀源碼可以知道，在當(dāng)前的bridge設(shè)計(jì)中，JavaScript和Objective-C的相互調(diào)用是批量處理的。

批量處理，就是說JavaScript和Objective-C的相互調(diào)用不會馬上執(zhí)行，而是攢夠一批，然后再一起處理。例如當(dāng)用戶的手指在屏幕上滑動時，會在短時間內(nèi)產(chǎn)生大量的觸摸事件，根據(jù)當(dāng)前的bridge的設(shè)計(jì)，這些觸摸事件是成批傳遞給JavaScript的，而不是每一個觸摸事件單獨(dú)實(shí)時進(jìn)行傳遞。

加載并執(zhí)行JavaScript代碼

bridge在創(chuàng)建時，最重要的任務(wù)是加載并執(zhí)行JavaScript代碼。JavaScript代碼就是前面我們說的通過npx react-native bundle命令打包的JavaScript代碼，在前面我們的RedBlock項(xiàng)目中，打包后的代碼大概是400多kb，共400多行代碼。這400多行代碼執(zhí)行完畢后，React Native的環(huán)境就準(zhǔn)備就緒了（React Native需要的各種變量已創(chuàng)建完畢），就可以準(zhǔn)備好被Objective-C調(diào)用。

JavaScript是一種沒有多線程能力的語言。在當(dāng)前bridge的設(shè)計(jì)中，會創(chuàng)建一個名為"com.facebook.react.JavaScript"的線程，然后讓所有JavaScript都在這個線程中執(zhí)行。

Objective-C和JavaScript相互調(diào)用的方式

JavaScript代碼被執(zhí)行后，會創(chuàng)建一個MessageQueue變量。MessageQueue是bridge的重要組成部分，因?yàn)镴avaScript和Objective-C相互調(diào)用的兩個重要方法都在MessageQueue里。

首先，Objective-C對JavaScript的調(diào)用，都是通過調(diào)用MessageQueue的callFunctionReturnFlushedQueue方法來實(shí)現(xiàn)的：

  callFunctionReturnFlushedQueue(
    module: string,
    method: string,
    args: mixed[],
  ): null | [Array<number>, Array<number>, Array<mixed>, number] {
    this.__guard(() => {
      this.__callFunction(module, method, args);
    });

    return this.flushedQueue();
  }

callFunctionReturnFlushedQueue方法需要傳入module、method和args三個參數(shù)，通過這三個參數(shù)就可以確定Objective-C需要調(diào)用JavaScript的哪個模塊（類），哪個方法和傳入的參數(shù)。

而JavaScript對Objetive-C的調(diào)用也和callFunctionReturnFlushedQueue方法有關(guān)，因?yàn)樵摲椒▓?zhí)行后會返回一個flushedQueue，這個flushedQueue存放的是JavaScript需要調(diào)用的Objective-C的內(nèi)容。Objective-C拿到這個flushedQueue后，就會執(zhí)行JavaScript需要調(diào)用的內(nèi)容。

而這個flushedQueue的內(nèi)容，是通過MessageQueue的enqueueNativeCall方法來添加的：

// 為了方便理解，已剔除調(diào)試和打印代碼
enqueueNativeCall(
    moduleID: number,
    methodID: number,
    params: mixed[],
    onFail: ?(...mixed[]) => void,
    onSucc: ?(...mixed[]) => void,
  ) {
  // 處理回調(diào)方法
    this.processCallbacks(moduleID, methodID, params, onFail, onSucc);
    // 將要調(diào)用的Objective-C內(nèi)容保存到隊(duì)列，體現(xiàn)了批處理的特點(diǎn)
    this._queue[MODULE_IDS].push(moduleID);
    this._queue[METHOD_IDS].push(methodID);
    this._queue[PARAMS].push(params);

    // 如果距離上一次調(diào)用超過MIN_TIME_BETWEEN_FLUSHES_MS（5ms）
    // 立即讓Objective-C執(zhí)行隊(duì)列內(nèi)容
    // 所以JavaScript對Objective-C的調(diào)用最多是5ms一批
    const now = Date.now();
    if (
      global.nativeFlushQueueImmediate &&
      now - this._lastFlush >= MIN_TIME_BETWEEN_FLUSHES_MS
    ) {
      const queue = this._queue;
      this._queue = [[], [], [], this._callID];
      this._lastFlush = now;
      global.nativeFlushQueueImmediate(queue);
    }
  }

enqueueNativeCall方法需要傳入moduleID、methodID和params等參數(shù)，代表著要調(diào)用的Objective-C哪個模塊（類），哪個方法，和傳入?yún)?shù)。

所以JavaScript和Objective-C的相互調(diào)用，是通過MessageQueue的callFunctionReturnFlushedQueue和enqueueNativeCall兩個方法來實(shí)現(xiàn)的。

知道Objetive-C和JavaScript相互調(diào)用的渠道后，很容易將相互調(diào)用的內(nèi)容打印出來。在上面的項(xiàng)目中，為了構(gòu)建紅色方塊用戶界面，JavaScript和Objetive-C相互調(diào)用的情況如下（已省略部分無關(guān)調(diào)用）：

OC->JS AppRegistry runApplication 
JS->OC UIManager createView
JS->OC UIManager createView
JS->OC UIManager setChildren
JS->OC UIManager createView
JS->OC UIManager setChildren
JS->OC UIManager setChildren

可以看到，Objective-C首先調(diào)用JavaScript的AppRegistry模塊的runApplication方法。然后，JavaScript通過調(diào)用Objective-C的UIManager模塊的createView和setChildren方法來創(chuàng)建用戶界面。

如果你用手指在React Native構(gòu)建的用戶界面上滑動，你會發(fā)現(xiàn)：

OC->JS RCTEventEmitter receiveTouches
OC->JS RCTEventEmitter receiveTouches
OC->JS RCTEventEmitter receiveTouches
...

Objective-C通過調(diào)用JavaScript的RCTEventEmitter模塊的receiveTouches方法，將大量的觸摸事件傳遞給JavaScript進(jìn)行處理。

跨線程調(diào)用

上面提到，JavaScript是在自己專有的線程中運(yùn)行的。所以O(shè)bjective-C和JavaScript的相互調(diào)用，是要跨線程的。

每個可以被調(diào)用的Objective-C模塊都是RCTBridgeModule，RCTBridgeModule會指定自己的methodQueue，所以JavaScript調(diào)用Objective-C時也是跨線程調(diào)用的。

例如，“點(diǎn)擊一個按鈕，按鈕產(chǎn)生一個被點(diǎn)擊的動畫效果”，這個動作需要跨越的線程有：

主線程---->JavaScript線程---->動畫模塊線程---->主線程
 （傳遞觸摸事件）    （調(diào)用OC動畫模塊）  (啟動動畫) 

性能損耗

React Native的性能是接近原生的。到底有多接近原生，要看連接JavaScript和Objective-C的bridge的性能。

目前的bridge存在如下幾個地方的性能損耗：

1. JavaScript代碼的加載和執(zhí)行。目前400kb左右的JavaScript代碼加載和執(zhí)行大概需要100ms左右?？傊甁avaScript代碼越多，執(zhí)行的越久。100ms是用戶可感知的等待了；
2. 批處理機(jī)制。JavaScript和Objective-C之間的相互調(diào)用都是批量處理的。例如在MessageQueue的enqueueNativeCall方法的實(shí)現(xiàn)中，一個調(diào)用最多有5ms的等待；
3. 跨線程調(diào)用。上面一節(jié)提到，點(diǎn)擊一個按鈕這樣簡單的動作，都需要跨越三個線程的調(diào)用。

除了bridge的性能損耗外，React Native還有一個問題：所有的用戶界面都是在一個RCTRootView上面構(gòu)建的，這意味著這一個RCTRootView上面渲染的視圖可能會非常多，這也是會影響性能的因素。我們知道，在原生開發(fā)的時候，一個app會有很多個UIViewController，每個UIViewController承載不同的用戶界面。但是在React Native中，RCTRootView承載著所有的用戶界面（就算使用React Navigation進(jìn)行所謂的頁面跳轉(zhuǎn)，實(shí)際還是在一個RCTRootView上面渲染內(nèi)容）。

React Native的前景

至此，React Native的原理分析完畢。React Native的原理就是JavaScript和Objetive-C的相互調(diào)用，相互調(diào)用的效率決定其性能。

React Native是Facebook開源的一個項(xiàng)目，F(xiàn)acebook自家的產(chǎn)品，包括Facebook、Instagram和Oculus都在使用。另外的一些大廠，例如騰訊QQ、京東和特斯拉也在使用。可以說只要Facebook沒有倒閉，React Native就會一直維護(hù)和更新，會越來越好。

React Native最大的優(yōu)勢當(dāng)然是跨平臺，一套代碼解決Android和iOS兩個平臺app的開發(fā)，這簡直太棒了！另外，React Native使用Flexbox布局，并支持熱調(diào)試，開發(fā)用戶界面的效率非常高。最后，React Native支持熱更新，可以繞過上架審核的過程，快速部署新內(nèi)容。

但是目前在國內(nèi)，Google開源的flutter其實(shí)比React Native更受歡迎，因?yàn)閾?jù)說flutter的性能更好？但是我認(rèn)為它們的差距其實(shí)可以忽略不計(jì)，它們都只是一個工具，真正重要的是使用工具的人：你能把這個工具用的多好？

最后，如果你是一個JavaScript全棧工程師，恰好你又懂React，那么React Native豈不是美滋滋？