加入咱們一塊兒學習,每天進步前端
編者按:本文轉載自知乎專欄前端醬爆,做者章偉東,網易雲音樂 前端工程師。
react
React Native 新架構
本文主要介紹FB團隊正在重構的ReactNative(下面稱RN)新架構,主要當前架構,Bridge帶來的問題,新架構,JSI,Fabric,TurboModules,CodenGen及LeanCore等概念。android
當前架構
RN如今主要有3個線程
webpack
-
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的運行過程。ios
當咱們寫了相似下面的React源碼。web
<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解析執行的速度。
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。
當前進度
-
JSI已經跟隨RN0.59(JSIExecuter.cpp)發佈,可是任然使用Bridge來通訊 -
Fabric和TurboModules還在開發,LeanCore已經完成 -
如今可使用C++跨平臺模塊。 -
對JS會實現向下兼容,對Native Modules不會兼容。 -
具體的進度能夠參考Fabric進度討論和 TurboModules進度討論和JSI進度討論和CodeGen進度討論,以及React官方源碼
目前RN的新架構正在緊張的重構中,比預約的時間表晚了一點,比較期待新框架的發佈和表現。
網易雲音樂前端開發工程師招聘
職位描述
一、負責或參與各種型項目(Web&Webview、RN、Hybrid Web、PC&MAC、小程序、創意活動、中後臺系統等)的前端開發工做,完成系統設計、技術選型、模塊開發工做。
二、以不斷提高質量、效率、體驗爲目的,封裝組件、沉澱文檔、生產工具、搭建系統, 享受工程師的平常
三、分享本身平常的所見所想,引導同事共同成長,營造積極健康的技術氛圍。
職位要求
一、精通各類Web前端技術和標準(Javascript、HTML、CSS),熟悉頁面佈局經常使用解決方案,對錶現與數據分離、Web語義化等有深入理解。
二、熟練掌握一個數據驅動視圖的框架( React,Angular,Vue...)。
三、熟練掌握經常使用的前端構建工具(webpack等),並具備成熟的模塊化開發思惟。
四、熟悉經常使用前端數據管理的解決方案(如Redux、Mobx、Rxjs等),並清楚它們的優劣和應用場景。
五、熟悉HTTP協議,並掌握相關網絡調試工具,有服務端開發的背景常識。
六、對重複性或不規範的工做容忍度低,能自發經過溝通或技術手段解決。
額外的加分項:
一、對一個較大型前端框架有超越文檔指南的原理性理解。
二、紮實的Node基礎,對 Node 異步編程、穩定性治理等有本身的實踐經驗,有大規模高可用的 Node 生產環境落地經驗。
三、豐富的跨端( PC & IOS & Android )開發經驗,有實際跨端技術融合的實踐經驗。
四、基於Web的爆款創意活動&遊戲實踐經驗,有相關框架或解決方案的產出。
五、有大廠成熟大前端團隊的工做經驗,參與開發或熟練應用內部沉澱的基礎設施,能清楚它們的改進點更好。
六、主導或以核心貢獻者角色參與過優質開源項目,對技術社區運營有深刻的思考看法。
聯繫方式
hzzhangweidong@corp.netease.com
參考資料
-
react-native-fabric-why-am-i-so-excited -
How React Native constructs app layouts -
React Native — A Bridge To Project Fabric -
Chen Feldman - React Native - Under the Bridge
最後
本文分享自微信公衆號 - 前端瓶子君(pinzi_com)。
若有侵權,請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」,歡迎正在閱讀的你也加入,一塊兒分享。