Facebook在2018年6月官方宣布了大规模重构React Native的计划及重构路线图。目的是为了让React Native更加轻量化、更适应混合开发,接近甚至达到原生的体验。(也有可能是React Native团队感受到了Google Flutter的追赶压力,必须从架构上做出重大革新,未来才有可能和Flutter进行全面的竞争)。
\n从Facebook公布的官方信息来看,这是一次革命性的架构重构,主要的重构内容如下:
\n1.改变线程模式。UI 更新不再同时需要在三个不同的线程上触发执行,而是可以在任意线程上同步调用 JavaScript 进行优先更新,同时将低优先级工作推出主线程,以便保持对 UI 的响应。
\n2.引入异步渲染能力。允许多个渲染并简化异步数据处理。
\n3.简化JSBridge,让它更快、更轻量。
\n目前业内React Native框架已经有了广泛的应用。京东在这个方面起步比较早,相对来说整体解决方案也比较成熟。目前京东深度定制和扩展的JDReact解决方案已经累计接入了200+个RN业务和20+的独立APP,并且承担了千万级的DAU。从业务实际开发中还是遇到了不少坑,其中性能问题比较明显,具体有以下几类问题:
\n加载性能偏慢,因为系统或者自定义的原生UI组件和API的注册加载过程中需要验证所有属性和JS API的一致性,影响加载性能,甚至直接导致主UI线程很容易阻塞。
\n\nJSBridge,React Native整体生命周期和JSBridge绑定太紧,所有的原生和JS之间操作全部是通过这个Bridge,而且每次的事件通讯是有时间间隔的,导致整体渲染过程是异步的。
\n\n手势问题,React Native目前的架构,从JS侧很难解决很多复杂的手势问题,需要重新定制SDK来解决问题。
\n\n返回事件的处理,目前的返回事件不能像原生一样,在组件中监听。
\n\nLayout的计算,整体的UI计算必须要在shadow layout中完成,没有办法在整体的平台框架中计算。
\n\n现有的Native \u0026amp; JS Component组件如下,通过这些组件可以完成原生UI渲染和API调用。这些组件都是通过packageManger注册到系统的,当RN业务启动后,需要对整体的属性和方法做一些校验,存在性能损失;另外RN是允许多个packagemanger同时注册的,当API数量偏大时,导致的问题需要循环遍历,调用过程也存在性能损耗。
\n1.Native Modules ,原生端API接口。
\n2.ViewManager,原生UI组件。
\n3.Native Navigation,原生导航组件。
\n4.ComponentKit \u0026amp; Litho,原生端基于yoga UI组件。
\n5.RCTSurface,原生端Surface实现。
\n加载过程中首先需要加载初始化React Native Core Bridge,包含以上的一些组件功能,然后才能运行业务的JS Code,只有这步完成后,React Native才能将JS的组件渲染成原生的组件:
所以目前的架构下这些组件和API太过依赖JSBridge的初始化,而且通讯能力也局限于这一条通道。从渲染的层次来看,React Native是多线程运行的,最常见的是JS线程和原生端的线程,一旦线程间异常,JSBridge整体将会阻塞,我们经常也能看到JS运行异常了,实际JS线程已经无响应了,但原生端还能响应滚动事件。
\n针对先有框架的一些问题Facebook在最近的版本中尝试过很多优化工作,从2013年发布到目前已经更新到了V0.58,去年一年发布了10多个版本。从版本更新可以看出,除了一些组件的更新和BUG修复外,Facebook做了性能优化方面的尝试,让其在加载和渲染性能上尽可能的达到原生。
\n0.33 Lazy module
\n\n0.40 RAM bundle/unbundle
\n\n0.43 FlatList/SectionList/VirtualizedList
\n\n0.50 SwipeableFlatList/Fiber
\n\n以下是目前官方建议的一些优化性能的方案:
\n1.组件的懒加载注册,原生端可以采用懒注册,在业务使用到该组件时注册。
\n2.按需打包,直接减少业务包大小,去掉一些不需要的module,提高渲染速度。
\n3.业务的懒加载,直接减少业务渲染过程中require各个组件的时间。
\n4.UNBundle,将业务分解成小的模块,提供性能。
\n5.移走初始化过程中不必要的JS module模块。
\n6.提供prepack工具优化JS代码。
\n最新的架构又提出了Fibe/Relay Modern架构,整体渲染性能相比以前有了很大的提高,最新的JDReact SDK已经升级到这个架构,目标是将加载JSBridge的开销降到最低,但是文章前面提到的瓶颈问题还是没有突破。
\n我们和跨端平台框架Flutter启动和渲染做了对比,在启动性能上React Native稍微优于Flutter,但渲染方面明显不如Flutter,也就是我们说的瓶颈问题,对比如下图:
\n \n所以,我们的结论是,在现有架构下的各种优化都很难彻底解决性能问题。
\n在最近的开发者大会中,Facebook对下一代架构重构的进展进行了介绍,我们也对master分支上提交的部分源码进行了分析,可以了解新架构的一些雏型设计,整体架构还在不断优化中,相信还会有更多惊喜。从现有的信息和代码来看,JS层业务的影响较小,不会因此次大规模架构重构后需要大量适配业务代码。这次的重构主要是JSBridge及原生架构的重构,下面我们从几个层面对比介绍整体框架:
\nUI的渲染过程分为三层:JS业务层、shadow tree、原生UI层。其中JS和shadow tree是通过JSBridge来同步数据的,JS层会将所有UI node生成一串JSON数据,传递到原生shadow层,原生shadow层通过传入node数据,新增新UI或者删除一些不需要的UI组件,这就完成了下图这三个层次之间的驱动关系:
\n \n带来的问题是整体UI渲染异步且太过于依赖JSBrige,很容易出现阻塞而影响整体UI体验,从JDReact的业务开发经验来看,比如初始化过程中UI复杂度过高,点击UI时响应时间会很长,就是因为UI被阻塞了很难响应touch事件,另外UI大小计算JS framework没有办法直接计算,需要依赖原生计算完成后的回调。
\n再看看SrollView的例子,这是业务或者社区反馈性能和体验问题最大的组件。最初版本的ScollView是一次渲染的不作任何回收,所以启动性能慢且内存占用较大。后续版本Flatlist作了组件的回收,内存基本稳定了,但是快速滑动过程中出现了体验问题,容易白屏且容易卡顿。大家看下面的流程图就能明白为什么Flatlist(基于ScollView实现)/ScrollView 快速滑动下会有长时间的白屏或者卡顿。
\n \n在Flatlist快速滑动过程中JS层会根据滑动的事件,触发Flatlist item的render渲染每一条数据,但是因为JSBridge的异步关系导致了shadow层最终呈现到原生的UI是异步的,而且滑动太快后会有大量的UI事件会阻塞在JSBridge,也导致了长时间的白屏出现,同时当部分item滑出可视区域一定的范围后UI内容会被回收等待下次滑到该区域后重新渲染。
\n回到之前ScrollView的例子,看看Fabric是怎么解决快速滑动过程中的性能问题的。
\n \n1.初始化:JS到Shadow层已经是同步操作了,而shadow层到原生UI变成了可以异步也可以同步操作了,组件可以根据自己的业务场景来适配不同的操作。
\n2.滑动过程:原生端直接控制JS层渲染,同时创建shadow层的node节点,node节点会采用同步的方式渲染原生UI,整个过程中滑动的渲染是采用的同步操作,所以不会出现旧架构下白屏的问题。
\n1.React Fabric Renderer (JS) ,JS端的Render架构。
\n2.FabricUIManager (JS, C++) ,JS端和原生端UI管理模块。
\n3.ComponentDescriptor (C++) ,原生端组件的唯一描述及组件属性定义。
\n4.Platform-specific Component Impl (ObjC++, Java) ,原生端组件。
\nRCTSurface (ObjC++, Java),Surface组件。
从这些组件的结构描述来看,新的Fabric架构大致如下:
\n1.shadow层从原有的Java层,挪到了C++层。
\n2.由C++层来管理整体的UI组件,原有的Java层UIManager换到C++层,管理这些C++层到虚拟组件。
\n3.而原生的组件透过JNI层会在C++层生成对应的实例,绑定一些属性和方法。
\n4.JS层FabricUIManager透过JSI,唤起C++层去生产node节点,并最终对应到我们的ComponentDescriptor。
\n从整体来看JS端的node节点可以完整的和C++端的node节点一一对应,透过JSI可以完成同步的调用和属性同步,同样C++到原生java层到组件是通过JNI来完成的,而且也是同步操作。
\n下面我们参考下目前Facebook开放出来的部分代码:
\n1.ComponentDescriptor,原生和原生UI对应的一层抽象层,这边实现了原生端组件的属性和事件,并通过唯一标示注册到comonentRegister中,以下是已经开放出来的switch组件的代码架构。
\n \n整体的Fabric的UIManger 组件和消息通道是怎么建立的呢?大家可以参考文件Scheduler.cpp,JS会通过JSI调用该接口来初始化。
\n1.Fabric component 注册。
\n2.消息通道注册。
\n3.初始化UIManager和UIManagerbinding,其中UIManager提供了创建node、clone node,添加shadow node、关闭surface等功能,而UIManagerbinding是基于JSI接口直接实现了和JS端UIManger的直接调用,大家可以参考源码JS端是通过JSI的get方法,通过属性的方式通知UIManagerbinding执行C++层的UIManger,而UImanger最终会根据生成的shadow node生成对应的UI。
\n \n下面我们看看JS端是如何生成原生组件的,大家可以对照源码,在JS端我们有FabricUIManager,在初始化UIManagerBinding过程中,注册到运行的JS环境,因为UIManagerBinding是JSI实现的,所以可以理解为我们创建了一个Host代理对象,注册到了JS,而JS侧也对应同样的数据结构来一一对应。
\n \n \n下面是创建一个node的列子:
\n \n从目前的结构来看,后续Fabric UI开发,需要从C++ component层、shadow层、原生Java层,三个层次开发,而且创建的shadow层也是通过JSI的方式和JS层的node节点一一对应的。
\n \n \n上面介绍Fabric架构时提到了JSI,那到底什么是JSI呢?如何能做到更原子级的控制每个模块和API呢?他是架起JS和原生java或者Objc的桥梁,类似于现有架构的JSBridge,但是采用的是内存共享、代理类的方式,JSI所有的运行环境都是在JSCRuntime环境下的,为了实现和JS端直接通讯,我们需要在C++层实现一个JSI::HostObject,该数据结构只有get、set两个接口,通过prop来区分不同接口的调用。
\n \n然后通过JSI接口生成一个JSObject,可以看到生成的代理对象和我们的HostObjectProxy是共享内存的,并且proxy中也实现了set和get方法。以下是具体的流程:
\n \n \n \n \n \n在JS端对应的是LazyObject,通过对这些Object的set、get,来完成对应C++实现的hostobject方法的调用:
\n \n \n这是基于新的JSI架构实现的Native module架构。JS层通过JSI获取到对应的C++层的module对象的代理,最终通过JNI回调Java层module。
\nC++层NativeMoudleProxy是通过JSI实现的对象,可以通过它传入module的名字获取C++层注册的module,已经这个module封装的所有的API method name。所以在JS业务加载的时候,会将这个proxy生成JS object代理对象到JS层。
\n \n \nJS层通过getNativeModule API并传递prop到JSI,最终会通过JSI接口找到Host object NativeModuleProxy,因NativeModuleProxy主要作用是将注册在C++层的JSI module通过名字生成JS Object传递的JS层调用, 所以其get方法中只有一个属性,就是通过JSINativeModules获取对应的module,而JSINativeModules是有缓存机制的,如果没有缓存的就直接解析该module中所有的API,如果有直接读取缓存的module信息。
\n \n大家可以看到在解析过程中,新版本增加了同步和异步的方法,也就是promise和sync。所以JSI module实际是可以同步操作API的,不像之前JSBridge的API都是异步操作的,同步操作的好处就是能做到线程间的同步。
\n \n所有的JSI module都是通过JSIMoudleregistry来注册的,当然这里注册的都是C++层的moulde,而所有的C++module最终是通过descriptor绑定到java层的turbomoudle中注册的Java层module,也就是我们最终在原生端实现的API,所以C++层module会通过对应的method prop来触发Java层的方法调用。
\n \n而C++层Native module是在java层instance manger初始化过程中注册的,遍历并注册java层和C++module。
\n \n \n所有理解Native Module的调用实际就是JSI的调用,而运行返回结果是基础的数据类型或者JSI object的,所以一个turbo module的method调用,返回值是可以是JSI object。开发者可以根据自己业务需要,将一些完整的数据结构封装成JSI host object,这样就可以做到,JS端同样可以获取到该对象,并同原生端对象形成了代理关系,可以同步完成一系列该Object porp功能操作,举个例子:
\n以前的调用方式通过JSBridge获取到一个picture,这个数据类型对应到JS端只能是一些基础的数据类型,比如我们参见的图片地址String类型,所以如果现在要上传这个图片的话,我们将JS端的数据再回传到原生端,如下图:
\n \n但有了JSI后就不一样了,我们在JS端透过JSI获取到的是JS Object,也就是picture,但是这个picture不再是简单的数据类型,而是和原生端形成绑定关系的结构,能够支持很多属性的同步设置,如改变alpha值等等,会直接触发host object的属性和函数调用,所以我们不再需要像之前一样改变alpha需要很多的JSBridge的调用,同样上传过程可以直接操作c++层的Object执行上传操作。
\n \n下面简单列举一下相关层次的调用关系:
\n \n \nReact Native 目前有52个直接依赖包,然后这些包间接递归依赖了589个包,大家可以在http://npm.anvaka.com/#/view/2d/react-native网站看看整体的依赖关系,是一个非常复杂的关系图。
\n从目前React Native开源的代码来看,整体是个很大的repo工程,包含了各种各样的Native组件、API、JS module,如何让这些组件和API维护更简单,让接入React Native架构的APP能将API或者组件快速裁剪变小也成了这次架构重构的目标。
\n删除掉一些不需要的modules,将所有的module分离成小的repo,类似于组件化模块。
\n\n减小业务开发的bundle代码的大小(按需引入和编译需要的component),进而提升业务的渲染和启动速度。
\n\n分离后将这些组件或API开放给社区,社区可以贡献自己的资源,这样可以让组件的维护和迭代更快,帮助减少组件维护成本。
\n\n减少目前React Native SDK开发的依赖,简化代码结构,让SDK升级起来更轻量、更快速。
\n\n增加了社区的贡献让PR的修复加快,让更多的开发者集中在更合理的位置,减少重复开发,降低开放的复杂度。
\n\n未来facebook计划:
\n1.删除所有觉得使用率低或者无价值的组件或者API。
\n2.将现有维护的模块移到外部的repo,单独维护。
\n具体组件的规划和归类,大家可以同步参考Facebook提供的列表,有很多组件已经明确要删掉或者移到开源社区来,比如WebView。
\n以下是React Native组件社区的规划图:
\n \n以后原生端Native组件主要分三部分,一部份会放到系统的SDK,一部分移到开源社区维护,开发者再贡献一部分组件。对开发者而言带来的影响:
\n1.所有组件不能像之前一样一次就同步下来了,需要根据拆分的repo由开发者自己按需安装repo,碎片化比较严重。
\n2.因为社区运营后开发者贡献会越来越快,版本迭代也会加速,所以版本的控制和代码的安全性也是一个重要的问题。
\n3.很多社区化的组件是对原生Native module是有依赖的,所以增加了前端开发人员的集成开发难度。
\n我们通过源码分析给大家简单介绍了Facebook的React Native下一代框架的设计,相信不管从性能体验和功能上都会有很大的变化。虽然整体变化很大但对于前端开发者而言JS的变化微乎其微,而重点改造在原生端组件和API架构,封装起来变得更加复杂,需要封装C++ shadow层,所以从以前的JAVA开发扩展到了C++和JAVA开发,对于开发者知识结构和储备要求更高,但对于提升性能而言,这些都是值得的。
\n社区化运营后Facebook官方可以从以前的组件和框架一起开发,简化到只需关注整体框架能力和性能了,让开发者贡献维护现在组件,大大提高了框架的迭代周期。
\n京东多端融合技术团队也会持续保持关注,待React Native新架构稳定后也会对渲染引擎进行升级并引入新的架构和特性。未来也会打通JDReact和JDFlutter双引擎的底层和组件,提供更为全面的跨端解决方案。
\n更多内容,请关注前端之巅。
\n \n