--- theme: smartblue --- 最近跨平台的热度又起来了，我们今天来聊聊比较有名的跨平台方案ReactNative相关的话题，从第一版ReactNative到现在，也接近10年了，10年的漫长岁月整个框架也发生了不少变化。我们也迎来了很多概念，比如新架构、Turbomodule等等，这不免让我产生好奇，为什么RN团队需要朝着这个方向迭代？在翻遍全网文章后，发现并没有我要的答案，因此就有了今天这个系列文章，希望能给还不太了解或者还在观望的技术团队带来更多的认识。本系列将从**旧架构起源到新架构的设计**做一系列的演化过程进行讲解，也算是记录自己对类RN框架发展认知！源码的阅读总是枯燥的，很多情况下我们都知道一件事情是怎么做的，源码解析就是这样，但是为什么这么做其实很少有人探究，这是因为所处的“Context”不一样，因为如果不站着设计者的角度上看，其实无法看出整齐全貌。当然我也无法让ReactNative的设计者来跟我讲述为什么要这么设计，不过有趣的是，曾经我也作为一个跨平台框架的开发者，“操盘”着公司内部的跨平台框架的设计，在设计整体框架时，其中碰到的困难与RN团队是一样的，经过两个多月断断续续的代码阅读，我相信自己的一些认知可以帮助大家更加全面的掌握ReactNative框架的本质。当然，目前ReactNative在移动端上支持Android、iOS、鸿蒙系统，为了时间节约，大部分Native设计代码我都会从Android展开，但是在总体平台思路是一致，这点需要大家注意 # UI与事件回到第一版ReactNative代码时，在2015年，此时正是移动互联网繁荣与机遇的年代，android 与iOS操作系统霸占整体手机市场进90%以上，移动端技术正是兴起的时候，此时ReactNative项目在Facebook孕育下正式开业，而开源的初衷并不是为了解决多端系统人力的问题，（比较有趣，杀手级跨平台框架一开始并不是纯为了解决多端代码编写问题）而是希望把强大的前端设计框架React.js带到移动端，“Bringing modern web techniques to mobile” 因为自身业务的特性，Facebook本身就具备了庞大的前端设计基础建设，面对着相对不那么成熟的移动端界面的编写体系，于是乎，为什么不把React也带到移动端呢？这种想法也孕育而生。第一版React到移动端的方案整体，其实是先在iOS平台上实现的，把React带到移动端，其实主要面临的是以下两个问题，对没错，只有两个，他们分别是UI与事件 ## UI 想要达成用React.js写出的界面能在移动端侧保持一致，就需要满足一种映射关系的转化，因为Native侧比如Android，他们对于UI的描述语言是不一样的，比如React.js表述文本是Text组件，Android是TextView，各自的设计表述都是存在差别的，但是表述的东西却是一致的，文本其实就是文本我们把其称为UI描述与UI实现，UI实现有很多种，但是UI的描述却是唯一的 ![](https://p6-xtjj-sign.byteimg.com/tos-cn-i-73owjymdk6/4d3af0a7a9854825935e3b5d2454cec7~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAgUGlrYQ==:q75.awebp?rk3s=f64ab15b&x-expires=1768381384&x-signature=nsb80ClK3zswHVsrzbrs0RJzncw%3D) 因此RN团队第一步需要解决的，是如何打通UI的描述与UI实现，这也是所有跨平台框架需要解决的第一步。这就需要一个媒介，能够承担起把UI描述功能。 ### UI描述我们如何描述一个页面呢？其实换算成自然语言的话，其实也就两部，**第一个这个页面有什么**，比如一个文本在一个容器里面，这其实是对于页面父子关系的描述，**第二个页面的某个具体控件长什么样**，这里其实描述的就是单独个体的属性。通过父子关系的描述与个体属性的**组合**，我们就能够把一个复杂的**静态页面**描述起来。有趣吧，其实把问题拆解下来就是这两个，接下来我们就得思考了，我们怎么去实现这两个。（注意：这里我们还是先以**旧架构思路**讲，后面也有**新架构**的实现）最简单的实现就是，我们可以定义一个协议呀，比如我们就可以定义以下json数据，一个json就能够包含以上两个概念，比如描述一个容器里面有什么，我们可以设定一个协议， | subView | 如果当前容器存在子控件，那么这个属性就有值，这里就描述了父子关系 | | ------- | -------------------------------------------------------------------------------------------------- | | prop | 这里就表示一个属性，可以有位置信息，比如距离父亲控件左上角的位置，x，y，也可以添加描述自身的属性，这里也分为两种一种是通用属性：比如描述背景色等一种是特殊属性：比如只有文本控件才可以有的文本属性 | 其实换算下来，就如同类似的json { "viewid" : "container" , "subView" : [ { "viewid" : "View1" , "prop":{ x:100 y:100, color:xxxx xxxx:xxx } "subView" : [ { "viewid" : "View1-1" , "subView" : [ ] }, { "viewid" : "View1-2" , "subView" : [ ] } ] }, ] } 是不是非常简单，我们就已经把关键的两部解决了，没错ReactNative的旧架构就是通过json的方式去表示一个UI的描述 ![](https://p6-xtjj-sign.byteimg.com/tos-cn-i-73owjymdk6/1eba99943a514e88a74d1e8d8c888031~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAgUGlrYQ==:q75.awebp?rk3s=f64ab15b&x-expires=1768381384&x-signature=vqzDJRv9%2BBkMXEQHMpNQcMrMxoQ%3D) 相当于React.js通过“解析器”把数据React.js涉及的代码转换为了Json，即“序列化”过程（当然这里并不是数据传输的序列化，这是一个类比概念），然后再把Json通过“反序列化”过程转化为了原生控件 #### 如何进行UI描述的“序列化”过程如何把用React.js编写的内容反序列化是一个重要过程，通过上文，我们可以得到最终的产物，其实就是UI的属性与UI父子关系描述。UI的父子关系在这个过程转化较为简单，因为在开发人员编写一个控件时，本身就会自己声明控件的父子关系，这个过程中最难的是UI属性解析阶段。在这个过程会遇到如何把JS侧的规则转化为通用UI描述，同时位置关系也非常重要，我们熟知的Yoga其实就是为了解决ReactNative中解析位置等关键属性而引入的。因为本篇关键分析React.js相关内容，就请允许我暂且掠过，我们直接看UI的创建过程吧，当UI数据解析后，JS侧会调用*UIManager*.createView进行UI的创建过程 const {UIManager} = NativeModules; .... createInstance: function(type, props, rootContainerInstance, hostContext, internalInstanceHandle) { var tag = ReactNativeTagHandles_1.allocateTag(), viewConfig = ReactNativeViewConfigRegistry_1.get(type); for (var key in viewConfig.validAttributes) props.hasOwnProperty(key) && deepFreezeAndThrowOnMutationInDev(props[key]); var updatePayload = ReactNativeAttributePayload_1.create(props, viewConfig.validAttributes); UIManager.createView(tag, viewConfig.uiViewClassName, rootContainerInstance, updatePayload); var component = new ReactNativeFiberHostComponent_1(tag, viewConfig); return precacheFiberNode$1(internalInstanceHandle, tag), updateFiberProps$1(tag, props), component; }, UIManager是一个NativeModules（这里我们遇到一个叫NativeModule的概念，不过没关系，我们之后的NativeModule小结还会讲，这里大家知道它其实是一个桥梁的封装，用于JS调用原生方法） *，* createView方法的实现其实并不在JS侧，而是通过一个中间层统一调用，这个中间层callNativeModules，其实现在C++，后面我们也会继续分析为什么设计这个中间层，以及为什么新架构又拿掉它 void JSCExecutor::callNativeModules(Value&& value) { .... try { //这里进行了序列化 auto calls = value.toJSONString(); m_delegate->callNativeModules(*this, folly::parseJson(calls), true); } catch (...) { . ... } } 在这里我们终于看到了，JS侧的数据通过toJSONString方法完成了序列化，之后数据通过JNI调用会再回到Java层 #### 如何进行UI描述的“反序列化”过程回到上文，通过C++侧调起的函数，最终就会到invoke 方法进行反序列化解析数据，并调用对应的方法 public class JavaMethodWrapper implements NativeModule.NativeMethod @Override public void invoke(JSInstance jsInstance, ReadableNativeArray parameters) { .... int i = 0, jsArgumentsConsumed = 0; try { for (; i < mArgumentExtractors.length; i++) { mArguments[i] = mArgumentExtractors[i].extractArgument( jsInstance, parameters, jsArgumentsConsumed); jsArgumentsConsumed += mArgumentExtractors[i].getJSArgumentsNeeded(); } } catch (UnexpectedNativeTypeException e) { throw new NativeArgumentsParseException( e.getMessage() + " (constructing arguments for " + traceName + " at argument index " + getAffectedRange(jsArgumentsConsumed, mArgumentExtractors[i].getJSArgumentsNeeded()) + ")", e); } try { mMethod.invoke(mModuleWrapper.getModule(), mArguments); } catch (IllegalArgumentException ie) { .... } 最终，NativeModule会调用UIManagerModule走到UI相关创建的过程。在ReactNative中，有一个最关键的基类，就是ViewManager，ViewManager就承担着“反序列化”构建UI大部分的能力，比如如何创建一个View，即createView方法，如何更新当前View的属性等最基础的方法 public abstract class ViewManager extends BaseJavaModule { ... /** Creates a view with knowledge of props and state. */ public @NonNull T createView( int reactTag, @NonNull ThemedReactContext reactContext, @Nullable ReactStylesDiffMap props, @Nullable StateWrapper stateWrapper, JSResponderHandler jsResponderHandler) { T view = createViewInstance(reactTag, reactContext, props, stateWrapper); if (view instanceof ReactInterceptingViewGroup) { ((ReactInterceptingViewGroup) view).setOnInterceptTouchEventListener(jsResponderHandler); } return view; } .... public void updateProperties(@NonNull T viewToUpdate, ReactStylesDiffMap props) { final ViewManagerDelegate delegate = getDelegate(); if (delegate != null) { ViewManagerPropertyUpdater.updateProps(delegate, viewToUpdate, props); } else { ViewManagerPropertyUpdater.updateProps(this, viewToUpdate, props); } onAfterUpdateTransaction(viewToUpdate); } .... ViewManager 定义了如何创建一个控件的流程以及更新一个View的过程，那么它是如何知道我们该创建哪个View呢？比如我是创建Text文本控件呢？还是Switch 控件呢？没错，还是协议，它可以是一个数字标识，也可以是文本标识，这里ReactNative采取的就是文本标识className，通过序列化阶段传递的className 找到最终需要创建的ViewManager。 public synchronized void createView( ThemedReactContext themedContext, int tag, String className, @Nullable ReactStylesDiffMap initialProps) { ... 通过className 找到我需要创建什么控件 try { ViewManager viewManager = mViewManagers.get(className); View view = viewManager.createView(tag, themedContext, initialProps, null, mJSResponderHandler); mTagsToViews.put(tag, view); mTagsToViewManagers.put(tag, viewManager); } finally { Systrace.endSection(Systrace.TRACE_TAG_REACT_VIEW); } } ViewManager 其实就是承担了如何完成UI描述的过程，这个通过也有很多其他的叫法，比如鸿蒙的Node树也是类似的概念，其实就是完成控件创建以及（父子关系绑定过程，可选，因为可以没有父子关系的叶子控件）当然，我们如果想要描述父子控件关系，那么也有一个**ViewGroupManager**，它继承自ViewManager基础上添加如何添加子View的描述关系 public abstract class ViewGroupManager extends BaseViewManager implements IViewGroupManager { .... @Override public void addView(T parent, View child, int index) { parent.addView(child, index); } /** 有了ViewManager基础概念之后呢，每个控件就可以定义自己的实现以及自己管理类的实现。 ![](https://p6-xtjj-sign.byteimg.com/tos-cn-i-73owjymdk6/525d32e6cfc24f53bae54e234b4fad90~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAgUGlrYQ==:q75.awebp?rk3s=f64ab15b&x-expires=1768381384&x-signature=l4U9BWTzb5qyOsziJdUDpYPFUxs%3D) 至此，我们就完成了静态页面构建中最后一步，UI就完美化成了Native侧的UI表示！ ## 事件 UI的渲染已经完成了，但是到这一步还只是一个普通页面，它只能看并不能相应任何东西，比如点击事件。UI的展示需要事件的驱动去修改对应的展示。如果我们说UI描述是JS侧打通Native侧，那么事件的处理就是Native侧打通JS侧事件的驱动，我们拿点击事件来举例子，比如有一个按钮，通过我们对UI的描述的理解，点击事件的编写肯定也是绑定在UI侧