加入咱们一块儿学习,每天进步前端
编者按:本文转载自知乎专栏前端酱爆,做者章伟东,网易云音乐 前端工程师。
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源创计划”,欢迎正在阅读的你也加入,一块儿分享。