React Native團隊宣布新架構將于2022年推出。點擊??這里[1??]查看他們的完整博客。

“2022 is going to be the year of the New Architecture in open source”(2022將會是新架構開源之年)

由于新版本發布在即，現在是個很好的機會去了解它的底層發生了哪些改變，以及這些改變會對我們的React Native App造成什么影響

本文主要介紹這次重構變化最多的地方：

1. JavaScript Interface(JSI)
2. Fabric
3. Turbo Modules
4. CodeGen

當前架構

在學習新架構之前，讓我們先回顧下當前的架構。

此次僅列舉一些和本文相關的知識點，如果想了解更多關于當前架構的內容，閱讀Bianca Dragomir的??這篇文章[2]??

簡而言之：

當我們運行RN應用時，所有的 javascript 代碼會被打包到 JS Bundle，Native代碼則被單獨保存。

RN有以下三個線程：

1. JS thread：JS引擎使用該線程運行JS Bundle。
2. Native/UI thread:  運行原生能力(Native Modules)，處理UI渲染，用戶手勢事件等操作。
3. shadow thread：在元素渲染之前先計算布局。

JS和Native thread通過bridge進行通信，當通過bridge發送數據時，bridge會將數據排隊批處理(優化)，并序列化成JSON，并且該通信只能是異步的。

current

重要術語：

JavaScriptCore：JavaScript引擎，用于執行JS代碼。

Yoga：UI引擎，用于計算元素在用戶屏幕上展示的位置。

1. JavaScript Interface (JSI)

當前架構中，JS和Native thread通過bridge實現通信，每次傳輸數據時，需要先將數據序列化為JSON，接收時，再解析回來。

這意味著JS和Native相互獨立。(JS thread無法直接調用Native thread的方法)

另一個需要注意的點是，bridge傳輸的數據本質上是異步的，在大多數用例中沒有問題，但在某些情況下，我們也需要JS和native代碼同步執行。

舉個例子：

當JS thread需要使用原生模塊時(如：藍牙)，需要發送信息給Native thread。首先JS thread會發送一條序列化后的JSON數據給bridge，之后bridge將數據優化后發送給Native thread，Native thread解析JSON數據，最后再運行所需的native代碼。

bridge

1)JS thread 準備data

2)在發送給bridge前將data序列化為JSON

3)在bridge傳輸的另一端解析data

4)Native thread執行所需native代碼

然而，在新架構中，bridge將被JavaScript Interface替代，這是一個輕量的，通用的層，使用C++編寫，JS引擎可以用它直接調用native的方法。

什么是通用？

當前的架構使用的是JavaScriptCore引擎，bridge只兼容該引擎。而JSI并非如此，它將JavaScript接口與引擎解耦，這意味著新架構可以使用其他JavaScript引擎，如Chakra，v8，Hermes等，因此它是“通用”的。

JSI怎么讓JavaScript直接調用native方法？

在JSI中，native方法通過C++宿主對象暴露給JavaScript。JavaScript會將這些對象的引用保存下來，并通過這些引用直接調用方法。類似于在web中，JavaScript保存DOM元素對象的引用，并調用其方法。例如：

const container = document.createElement(‘div’);

在這段代碼中，JavaScript變量container指向DOM元素的引用，DOM元素則可能是C++初始化的。當我們調用container的任何方法時，container會調用DOM元素內的方法。JSI以類似的方式工作。

與bridge不同，JSI允許JavaScript保存對Native Modules的引用，JavaScript可以通過JSI直接調用這個引用的方法。

jsi

1)JavaScript持有native module的引用

1)它通過JavaScript Interface調用native module的方法

總而言之，JSI允許使用其他的JavaScript引擎，并且實現了線程間的互相操作，JavaScript可以在JS thread中直接與native端通信。以后不再需要將data序列化為JSON，同時避免了bridge的堵塞以及異步問題。

JSI的另一個巨大優勢是，它是由C++編寫的，借助C++，React Native可以在大量的系統中運行，如智能電視、智能手表等。

2.Fabric

Fabric是渲染系統，它會取代當前的UI Manager。

為了理解Fabric的優勢，我們先看看當前React Native是如何渲染UI的：

app運行時，React執行代碼，在JavaScript中創建ReactElementTree，Renderer會基于它在C++中創建ReactShadowTree。

布局引擎根據虛擬樹計算UI元素在屏幕上的位置，計算完成后，虛擬樹會被轉換成由Native Elements組成的HostViewTree。*(例如：ReactNative中的元素在Android和iOS中會分別轉換為ViewGroup和UIView)*

fabric

ReactElementTree (JavaScript) -> ReactShadowTree(C++) -> HostViewTree(Native)

這種方式的問題：

正如我們所知，線程間的通信都通過bridge來實現，這意味著緩慢的傳輸速率以及非必要的數據復制。

例如：ReactElementTree中的節點，在ReactShadowTree中也是image，但是兩份數據必須在兩個節點中都復制一份。

并且，由于JS和UI的線程不是同步的，在某些情況下甚至會因為丟幀導致app卡頓。(例如：滾動一個包含大量數據的FlatList)

Fabric是什么？

根據ReactNative的官方文檔[3]，

"Fabric is React Native’s new rendering system, a conceptual evolution of the legacy render system"（Fabric是ReactNative新的渲染系統，它的概念從傳統渲染系統進化而來）

正如我們在本文中JSI部分所看到的，JSI將native方法直接暴露給JavaScript，這也包括了UI方法，由此使得JS和UI線程能夠同步，這會提高列表，導航，手勢處理等的性能。

Fabric會帶來什么好處?

在新的渲染系統中，滾動，用戶手勢等用戶交互可以優先在主線程或native線程中同步執行，而其他任務，比如接口請求等會異步執行。

并且，新的Shadow Tree是不可變的，JS和UI線程中共享該tree，以允許來自兩端的直接交互。

在當前的架構中，React Native 必須維護兩個層次結構/DOM 節點。而新架構中，只需維護shadow tree，并且是線程間共享的，這也將有助于減少內存消耗。

3.Turbo Modules

在當前的架構中，所有JavaScript使用的的原生模塊(如藍牙，地理位置，文件存儲等)必須在app打開前初始化。這意味著即使用戶不需要某個模塊，它還是會在啟動時被初始化。

Turbo Modules基本上是對老的Native Modules的增強。我們在上文看到的，現在JavaScript可以保留這些模塊的引用，這可以讓我們的JS按需加載模塊，大大提高ReactNative app的啟動速度。

4.CodeGen

Fabric和Turbo Modules聽起來很有前途，但是JavaScript是一門動態語言，而JSI是用C++寫的，C++是一門靜態語言，因此需要保證兩者間的順利通信。

這就是新架構還包括一個名為CodeGen的靜態類型檢查器的原因。

CodeGen使用類型確定后的JavaScript來為Turbo Modules和Fabric定義供他們使用的接口元素，并且它會在構建時生成更多的native代碼，而非運行時。

總結

將所有的變化結合起來，新架構如圖所示：

new

主要亮點為：

• Bridge會被JSI取代
• 可以用其他引擎替代JavaScriptCore
•  所有線程間可以完全互相操作
• Web式的渲染系統
• 對時間敏感的任務可以同步執行
• Turbo Modules實現模塊懶加載
• JS端和Native端的靜態類型檢查

我們可以確信，新架構會給React Native帶來強大的提升。