快來了，React Native 新架構
本文大部分內容轉載自知乎專欄前端醬爆，作者章偉東，網易雲音樂 前端工程師。前端晚間課進行修改，根據現在發展情況增加了內容。
2021年7月14日，React Native 核心團隊的 Joshua Gross 在 Twitter 說，RN 的新架構已經在 Facebook 內部落地了，並且 99%的代碼已經開源。這次的架構升級“蓄謀已久”，Joshua 說他們從 2018 年 1 月就開始規划了。
2021年尾聲， React Native 新架構所依賴的 React 18 發了 beta 版，React Native 新架構面向生態庫和核心開發者的文檔也正式發布，React Native 團隊成員 Kevin Gozali 也在最近一次訪談中談到新架構離正式發版還差最后一步延遲初始化，而最后一步工作大約會在 2022 年上半年完成。種種跡象表明，React Native 新架構真的要來了。
本文主要介紹FB團隊正在重構的ReactNative(下面稱RN)新架構，主要當前架構（以下稱舊架構），Bridge帶來的問題，新架構，JSI，Fabric，TurboModules，CodenGen及LeanCore等概念。
舊架構
舊RN主要有3個線程
JS thread。JS代碼執行線程，負責邏輯層面的處理。Metro（打包工具）將React源碼打包成一個單一JS文件(就是圖中JSBundle)。然后傳給JS引擎執行，ios和android統一用的是JSC。
UI Thread(Main Thread/Native thread)。這個線程主要負責原生渲染（Native UI）和調用原生能力(Native Modules)比如藍牙等。
Shadow Thread。這個線程主要是創建Shadow Tree來模擬React結構樹。Shadow Tree可以類似虛擬dom。RN使用Flexbox布局，但是原生是不支持，所以Yoga就是用來將Flexbox布局轉換為原生平台的布局方式。
Bridge的問題
首先回顧一下早前版本Bridge的運行過程。
當我們寫了類似下面的React源碼。
<View style={{ backgroundColor: 'pink', width: 200, height: 200}}/> JS thread會先對其序列化,形成下面一條消息，
UIManager.createView([343,"RCTView",31,{"backgroundColor":-16181,"width":200,"height":200}]) 通過Bridge發到ShadowThread。Shadow Tread接收到這條信息后，先反序列化，形成Shadow tree，然后傳給Yoga，形成原生布局信息。
接着又通過Bridge傳給UI thread。
UI thread 拿到消息后，同樣先反序列化，然后根據所給布局信息，進行繪制。
從上面過程可以看到三個線程的交互都是要通過Bridge，因此瓶頸也就在此。
Bridge三個特點：
- 異步。這些消息隊列是異步的，無法保證處理事件。
- 序列化。通過JSON格式來傳遞消息，每次都要經歷序列化和反序列化，開銷很大。
- 批處理。對Native調用進行排隊，批量處理。
異步設計的好處是不阻塞，這種設計在大部分情況下性能滿足需求，但是在某些情況下就會出問題，比如瀑布流滾動。
當瀑布流向下滑動的時候，需要發請求給服務端拿數據進行下一步渲染。
滾動事件發生在UI thread，然后通過Bridge發給JS thread。JS thread 監聽到消息后發請求，服務端返回數據，再通過Bridge返回給Native進行渲染。由於都是異步，就會出現空白模塊，導致性能問題。
從上面可以看出，性能瓶頸主要是存在JS線程和Native有交互的情況，如果不存在交互，RN的性能良好。
因此，對於RN的優化，主要集中在Bridge上，有下面3個原則：
- JS和Native端不通信。最徹底的方式，消息不走Bridge。
- JS和Native減少通信。在兩端無法避免的情況下，盡量通信減少次數。比如多個請求合並成一個。
- 較少JSON的大小。比如圖片轉為Base64會導致傳輸數據變大，用網絡圖片代替。
RN里面可以通過MessageQueue來監聽Bridge通信，主要代碼如下:
import MessageQueue from 'react-native/Libraries/BatchedBridge/MessageQueue.js'; const spyFunction = (msg) => { console.log(msg); }; MessageQueue.spy(spyFunction); 下面是監聽到的信息:
新架構
FB團隊逐漸意識到了這些問題，同時也受到Flutter的壓力，在2018年提出了新架構，並開始實施，
主要有JSI、Fabric、TurboModules、CodeGen、LeanCode組成。
JSI
JSI是整個架構的核心和基石，所有的一切都是建立在它上面。
JSI是Javascript Interface的縮寫，一個用C++寫成的輕量級框架，它作用就是通過JSI，JS對象可以直接獲得C++對象(Host Objects)引用，並調用對應方法。
另外JSI與React無關，可以用在任何JS 引擎（V8,Hermes)。
有了JSI，JS和Native就可以直接通信了,調用過程如下：
JS->JSI->C++->ObjectC/Java(關鍵)
自此三個線程通信再也不需要通過Bridge，可以直接知道對方的存在，讓同步通信成為現實。具體的用法可以看 官方例子。
另外一個好處就是有了JSI，JS引擎不再局限於JSC，可以自由的替換為V8,Hermes，進一步提高JS解析執行的速度。（RN官方宣布：Hermes將成為React Native默認的JS引擎）
Fabric
Fabric是整個架構中的新UI層，包括了新架構圖中的renderer和shadow thread。
下圖是舊的通信模型。
三個線程通過Bridge異步通信，數據需要拷貝多份。
有了JSI以后，JS可以直接掉調用其他線程，實現同步通信機制。另外數據可以直接引用，不需要拷貝，於是就變成了下面新的通信模式.
除了同步能力，直接引用，另外一個好處是Fabric現在支持渲染優先級比如React的Concurrent和Suspense模式
下面兩張圖是從啟動到渲染階段，加入Fabric前后的變化。
改造為Fabric之后
TurboModules
TurboModules主要和原生應用能力相關，對應新架構圖上的Native Modules，這部分的優化是：
通過JSI，可以讓JS直接調用Native模塊，實現一些同步操作。比如調用攝像頭能力。Native模塊懶加載。之前RN框架啟動的時候會加載所有Native模塊，導致啟動慢，時間久。現在有了TurboModules后，可以實現按需加載，減少啟動時間，提高性能。
CodeGen
通過CodeGen，自動將Flow或者Ts等有靜態類型的JS代碼翻譯成Fabric和TurboModules使用的原生代碼。
Lean Core
這部分主要是包的瘦身，以前所有的包都放在RN核心工程里面。現在RN核心只保留必要的包，其他都移到react-native-community 或者拆出單獨的組件，比如Webview和AsyncStore。
結語
該文章是時間較早發布的文章，但是整體方向個人覺得是不會變的（有誤請指出），最晚下半年，React Native 新架構應該可以到來，這次升級過后，RN 在性能上應該能夠追平 Flutter（InfoQ 記者采訪了 58 同城資深前端工程師，58RN、Hybrid 框架的負責人蔣宏偉，紀要上面蔣宏偉的觀點），首先，JavaScript 和 Dart 語言上都支持了 AOT 預編譯，打個平手。其次，JavaScript 和 Dart 和底層交互都是通過 C++ 進行的，也是打個平手。最后，RN 原生組件繪制有平台的優化加成， 相對於 Flutter 自繪引擎繪制，可能還會好上一些。
2021年上半年，自己也用過RN做了一個個人項目ReadIT（算是學習，用的是v0.61），感觸就是升級異常麻煩，使用第三方庫的話出問題難找，好在最后還是完成，也學習了一些技術（當然呢，忘關了，哈哈），參考了一些RN優秀項目的目錄組織結構，所以覺得代碼還是比較漂亮的。
客戶端（react-native、@react-navigation、react-native第三方庫、typescript、mobx、marked等技術）
中台后管系統（antd4、react、redux、react-router4、hook等技術）
后端程序（koa、mongoDb、jsonwebtoken、ali-oss等技術）
web版（vue3、vite、vue-router、vuex）
github，https://github.com/xiaobinwu/readIt
效果， https://read-it.oss-cn-shenzhen.aliyuncs.com/e2b822229c4f47000689c4d7b2209b1a.mp4
感興趣可以看一下，別忘了打賞star，感覺越講越遠，對於RN新架構，我們拭目以待吧。