ReactNative是如何让JS代码『变成』Android控件的？

ReactNative是如何让JS代码『变成』Android控件的？

编写的JS代码是如何『变』成一个个Android的控件的呢？JS的FlexBox布局是如何『转译』成Android的布局的呢？

在找到这两个问题答案前，先介绍下RN的渲染引擎——Yoga。

Yoga

随着这几年前端技术的崛起，作为前端UI骨架的布局系统也在其中占据了越来越重要的位置。不管是在移动端、桌面端还是Web端，特别是不同设备的屏幕大小和分辨率千变万化，如何构建良好的布局系统以便应付这些变化已经变得越来越重要。

目前，各个平台都有自己的一套解决方案。iOS平台有自动布局系统，Android有容器布局系统，而Web端有基于CSS的布局系统。多种布局系统共存所带来的弊端是很明显的，平台间的共享变得很困难，而每个平台都需要专人来开发维护，增加了开发成本。

Facebook在这个问题上没有少下功夫。首先，Facebook在React Native里引入了一种跨平台的基于CSS的布局系统，它实现了Flexbox规范。基于这个布局系统，不同团队终于可以走到一起，一起解决缺陷，改进性能，让这个系统更加地贴合Flexbox规范。

随着这个系统的不断完善，Facebook决定对它进行重启发布，并取名Yoga。

Yoga是基于C实现的。之所以选择C，首先当然是从性能方面考虑的。基于C实现的Yoga比之前Java实现在性能上提升了33%。其次，使用C实现可以更容易地跟其它平台集成。到目前为止，Yoga已经有以下几个平台的绑定：Java（Android）、Objective-C（UIKit）、C#（.NET）。

Yoga使用方式

目前Yoga的1.5.0在Android上已经支持直接使用xml布局了，但接下来我要追踪的View渲染原理肯定不会在Android上生成静态xml布局。所以这里还得看下如何使用Java代码编写Yoga布局。
这里我直接引用官网的代码示例。

YogaNode root = new YogaNode();
root.setWidth(500);
root.setHeight(300);
root.setAlignItems(CENTER);
root.setJustifyContent(CENTER);
root.setPadding(ALL, 20);

YogaNode text = new YogaNode();
text.setWidth(200);
text.setHeight(25);

YogaNode image = new YogaNode();
image.setWidth(50);
image.setHeight(50);
image.setPositionType(ABSOLUTE);
image.setPosition(END, 20);
image.setPosition(TOP, 20);

root.addChildAt(text, 0);
root.addChildAt(image, 1);

简而言之，创建子节点并设置显示属性后放入根节点即完成了Yoga的布局。

渲染原理

如何布局

我的思路是要找到这个问题的答案，首先要先搞清楚View如何被创建？

之前看到过一篇文章React-Native 源码分析二-JSX如何渲染成原生页面，这里作者直接把我引导到UIManagerModule，帮我少走了不少弯路。这个类里有好多被声明为@ReactMethod的方法。

public class UIManagerModule extends ReactContextBaseJavaModule {

    ···    @ReactMethod
    public void createView()
    @ReactMethod      public void updateView()
    @ReactMethod      public void manageChildren()
      @ReactMethod      public void measure()
    ···
}

以上我只列举了一部分，但通过方法名称即可了解这里是JS和Native关于页面渲染的切口。跟踪createView()方法，发现了ShaowNode的创建。

public void createView(int tag, String className, int rootViewTag, ReadableMap props) {
    ReactShadowNode cssNode = createShadowNode(className);
    ReactShadowNode rootNode = mShadowNodeRegistry.getNode(rootViewTag);
    cssNode.setReactTag(tag);
    cssNode.setViewClassName(className);
    cssNode.setRootNode(rootNode);
    cssNode.setThemedContext(rootNode.getThemedContext());

    mShadowNodeRegistry.addNode(cssNode);
    ···
  }

这里只是把创建好的ShaowNode放到ShadowNodeRegistry里。ShadowNodeRegistry的核心是一个存放ReactShadowNode的列表。

SparseArray<ReactShadowNode>

那么肯定会有逻辑来遍历这个列表来处理单个ReactShadowNode。

接下来我用JS写了一个简单的布局来跟踪具体布局流程。

<View style={{flex:1}}>
    <View style={{flex:1}}>
        <Text style={{flex:1}}>显示1</Text>
    </View>
    <View style={{flex:1}}>
        <Text style={{flex:1}}>显示2</Text>
    </View></View>

按照之前上面createView()里的逻辑，ShadowNodeRegistry里会有所有View的ReactShadowNode。

但是发现里面有10个ReactShadowNode。多出来的几个我们后面分析，继续跟踪布局流程。

接下来会通过递归的方式将各个ReactShadowNode以树的方式连接起来。

这里要说的一点是RCTRawText仅包含Text的文案，和RCTText是一一绑定的，但在创建View的过程中也会被封装成一个ReactShadowNode。后来经过测试，发现2-RCTView和3-RTCView除了承载要显示的内容之外，还会承载一些框架自己的View，比如经常看到的黄色提示框。所以去除2、3、7和10之后，整个树状结构和JS代码里的布局结构就一一对应起来了。

本以为在Native的View层级也是这样，但通过Layout Inspector发现比这个简单。

那么4、5和8去哪了？这个问题我后面再跟踪，继续看View是怎样布局的。

我觉得这里要简要说明下Native对于View的处理流程。Native接收到JS的渲染请求后，会将其封装为类型为ViewOperation的操作原子类。这些原子类会被暂时缓存到一个列表中。当UIManagerModule的onBatchComplete()被调用才会轮询缓存列表执行操作。简单来说onBatchComplete()是Native和JS完成一次通讯后才会被调用，这块流程可以参阅Native和JS通讯原理了解。

View的创建，尺寸计算、更新坐标等细节操作均被封装成了不同的ViewOperation。在UIViewOperationQueue里可以看到详细类型。这里我只列举几个。

private final class UpdateLayoutOperation extends ViewOperation {

    ···    @Override
    public void execute() {
      Systrace.endAsyncFlow(Systrace.TRACE_TAG_REACT_VIEW, "updateLayout", mTag);
      mNativeViewHierarchyManager.updateLayout(mParentTag, mTag, mX, mY, mWidth, mHeight);
    }
  }  private final class CreateViewOperation extends ViewOperation {

     ···    @Override
    public void execute() {
      Systrace.endAsyncFlow(Systrace.TRACE_TAG_REACT_VIEW, "createView", mTag);
      mNativeViewHierarchyManager.createView(
          mThemedContext,
          mTag,
          mClassName,
          mInitialProps);
    }
  }  private final class ManageChildrenOperation extends ViewOperation {
      ···    @Override
    public void execute() {
      mNativeViewHierarchyManager.manageChildren(
          mTag,
          mIndicesToRemove,
          mViewsToAdd,
          mTagsToDelete);
    }
  }

回到刚才的问题，发现View的布局最终由UpdateLayoutOperation执行。从execute()一路跟下去，最终发现在NativeViewHierarchyManager的updateLayout()方法里找到了View的布局逻辑。

private void updateLayout(View viewToUpdate, int x, int y, int width, int height) {
    ···
    viewToUpdate.layout(x, y, x + width, y + height);
    ···
  }

至于x和y是怎样被计算的，暂且不去研究，但追踪到这里可以明确，View的布局并没有使用Android视图容器组件的特性，而是通过计算View的x、y坐标后，直接使用layout()方法在父控件里定位，这也就变相解释了ReactRootView的父类是FrameLayout的用意。

接下来要弄明白的一个问题是那些最终没有展示在屏幕上的ReactShadowNode去哪了？猜测应该有类似『过滤器』的逻辑在某个环节把他们过滤掉了。

带着这个问题继续研究。既然View的布局是由任务队列中的UpdateLayoutOperation执行，那么也许跟踪UpdateLayoutOperation被放进队列的逻辑能找到答案。

顺着这个思路跟踪到在NativeViewHierarchyOptimizer的applyLayoutRecursive()方法。UpdateLayoutOperation被放进任务队列果然有『前置条件』。

private void applyLayoutRecursive(ReactShadowNode toUpdate, int x, int y) {    if (!toUpdate.isLayoutOnly() && toUpdate.getNativeParent() != null) {      int tag = toUpdate.getReactTag();
      mUIViewOperationQueue.enqueueUpdateLayout(
          toUpdate.getNativeParent().getReactTag(),
          tag,
          x,
          y,
          toUpdate.getScreenWidth(),
          toUpdate.getScreenHeight());      return;
    }
    ···
}

问题焦点进入到ReactShadowNode的isLayoutOnly()方法里。这个方法只是返回了一个布尔值。

public final boolean isLayoutOnly() {    return mIsLayoutOnly;
  }

那么就搜一下mIsLayoutOnly什么时候被赋值的。

/**
   * Sets whether this node only contributes to the layout of its children without doing any
   * drawing or functionality itself.
   */
  public final void setIsLayoutOnly(boolean isLayoutOnly) {
          ···
       mIsLayoutOnly = isLayoutOnly;
  }

这个方法的注释正是我要找的问题的表象。继续搜这个方法被调用的地方，被带到了NativeViewHierarchyOptimizer的handleCreateView()。

public void handleCreateView(
      ReactShadowNode node,
      ThemedReactContext themedContext,
      @Nullable ReactStylesDiffMap initialProps) {

    ···    boolean isLayoutOnly = node.getViewClass().equals(ViewProps.VIEW_CLASS_NAME) &&
        isLayoutOnlyAndCollapsable(initialProps);
    node.setIsLayoutOnly(isLayoutOnly);
    ···
  }

ViewProps.VIEW_CLASS_NAME的值为RCTView，这也就是我一直在找的被弄丢的4、5和8的节点类型。到此，这个问题的答案就找到了。

但是还有个小问题，总不能所有的RCTView都被过滤掉吧？

为了验证这个问题，我在JS代码里给第二个Text的父View设置一个背景色。

<View style={{flex:1}}>
    <View style={{flex:1}}>
        <Text style={{flex:1}}>显示1</Text>
    </View>
    <View style={{flex:1,backgroundColor:'#223344'}}>
        <Text style={{flex:1}}>显示2</Text>
    </View></View>

然后再次进入handleCreateView()里，发现『8-RCTView』的isLayoutOnly这次变成了false。原因就是『&&』后面的isLayoutOnlyAndCollapsable()。

这个方法的返回值是根据View的属性判断的，核心逻辑是ViewProps的isLayoutOnly()。ViewProps里保存了一个名为LAYOUT_ONLY_PROPS的静态属性列表，具体值可以到这个类里详细看，这里我就简单概括下，里面包括了设置margin、padding、position等一系列属性。isLayoutOnly()会判断View的属性所有的key都是LAYOUT_ONLY_PROPS里的属性的话，返回true。我刚才添加的backgroundColor不属于这个列表里的属性，自然这个方法返回false，所以『8-RCTView』就会被绘制到屏幕上。

综上，RN会将所有JS编写的View封装成ShaowNode，并自动过滤不需要显示的View以减少嵌套层级。最终计算View的坐标值然后绘制到ReactRootView封装的FrameLayout上。

怎样给View分配ID

前面跟踪了View的绘制流程，众所周知，Android上所有的View都有一个ID。那么RN是怎样给View分配ID的呢？

一路跟进创建View的方法，终于在在NativeViewHierarchyManager的createView()方法中发现了设置id的代码。

public void createView(
      ThemedReactContext themedContext,      int tag,
      String className,
      @Nullable ReactStylesDiffMap initialProps) {

     ···
     ViewManager viewManager = mViewManagers.get(className);
     View view = viewManager.createView(themedContext, mJSResponderHandler);
     view.setId(tag);
     ···
 }

接下来把焦点放到tag是怎样传进来的。一层层网上扒代码，跟踪到UIManagerModule的createView()方法后，发现了非常熟悉的@ReactMethod，这就说明View的id并不是在Native生成的，看来得到JS代码里寻找答案。

根据ReactMethod的映射规则，通过在JS代码里全局搜索『createView』，发现ReactNativeBaseComponent调用了createView。

var tag = ReactNativeTagHandles.allocateTag();
UIManager.createView(
      tag,      this.viewConfig.uiViewClassName,
      nativeTopRootTag,
      updatePayload,
    );

这里发现ReactNativeTagHandles负责生成tag，通过方法名allocateTag猜测难道tag是自动递增生成的？进去一看，果不其然。

var INITIAL_TAG_COUNT = 1;var ReactNativeTagHandles = {
  tagsStartAt: INITIAL_TAG_COUNT,
  tagCount: INITIAL_TAG_COUNT,

  allocateTag: function(): number {    // Skip over root IDs as those are reserved for native
    while (this.reactTagIsNativeTopRootID(ReactNativeTagHandles.tagCount)) {
      ReactNativeTagHandles.tagCount++;
    }    var tag = ReactNativeTagHandles.tagCount;
    ReactNativeTagHandles.tagCount++;    return tag;
  },

  reactTagIsNativeTopRootID: function(reactTag: number): boolean {    // We reserve all tags that are 1 mod 10 for native root views
    return reactTag % 10 === 1;
  },
};module.exports = ReactNativeTagHandles;

整个类逻辑比较简单，就是每次通过++的方式将tag的值递增，而且发现ReactRootView的tag恒定为1，那么在Native是不是这样呢？我用JS编写一个简单的页面。

<View style={{flex:1}}>
    <View style={{flex:1}}>
        <Text style={{flex:1}}>点击显示</Text>
    </View>
    <View style={{flex:1}}>
        <Text style={{flex:1}}>点击显示</Text>
    </View></View>

然后用工具Layout Inspector来验证。

可以看到ReactRootView的id果然为1，然后两个ReactTextView的id分别为6和9。

怎样给View设置属性

为了跟踪属性设置流程，我修改了JS代码，给第一个Text背景和文字添加了颜色。

<View style={{flex:1}}>
    <View style={{flex:1}}>
        <Text style={{flex:1,color:'#661100',backgroundColor:'#998800'}}>点击显示</Text>
    </View>
    <View style={{flex:1}}>
        <Text style={{flex:1}}>点击显示</Text>
    </View></View>

发现在UIManagerModule的createView()接收到了tag为5，props值为{{"allowFontScaling":true,"ellipsizeMode":"tail","accessible":true,"backgroundColor":-6715392,"color":-10088192,"flex":1} }的调用。通过backgroundColor和color即可判定这是我要跟踪的View。

根据刚才是跟踪View绘制流程的思路，背景色的绘制肯定会被封装成某个ViewOperation，然后等待任务队列轮询。顺着这个思路，发现背景色的更改会被CreateViewOperation的execute()执行，最终会进入ViewManagerPropertyUpdater的updateProps()。

public static <T extends ReactShadowNode> void updateProps(T node, ReactStylesDiffMap props) {
    ShadowNodeSetter<T> setter = findNodeSetter(node.getClass());
    ReadableMap propMap = props.mBackingMap;
    ReadableMapKeySetIterator iterator = propMap.keySetIterator();    while (iterator.hasNextKey()) {
      String key = iterator.nextKey();
      setter.setProperty(node, key, props);
    }
  }

这里的propMap即为JS传进来的View的属性。

updateProps()会遍历这个Map，将Key传进setter里进一步处理。那么继续跟进去看setProperty()。

@Override
    public void setProperty(T manager, V v, String name, ReactStylesDiffMap props) {
      ViewManagersPropertyCache.PropSetter setter = mPropSetters.get(name);      if (setter != null) {
        setter.updateViewProp(manager, v, props);
      }
    }

这里根据Key获取其对应的ViewManagersPropertyCache.PropSetter来处理View的属性。那么mPropSetters应该是类似静态注册表的存在。那么就看看mPropSetters是怎样初始化的。

mPropSetters = ViewManagersPropertyCache.getNativePropSettersForViewManagerClass(viewManagerClass);

继续跟进getNativePropSettersForViewManagerClass()

static Map<String, PropSetter> getNativePropSettersForViewManagerClass(
      Class<? extends ViewManager> cls) {
      ···
        props = new HashMap<>(
        getNativePropSettersForViewManagerClass(
            (Class<? extends ViewManager>) cls.getSuperclass()));
    extractPropSettersFromViewManagerClassDefinition(cls, props);
    CLASS_PROPS_CACHE.put(cls, props);    return props;
  }

核心逻辑是extractPropSettersFromViewManagerClassDefinition()方法，因为源码较长，就简要介绍下。这个方法里会递归扫描ViewManager及其父类中声明了ReactProp的方法，然后将其放到mPropSetters中。现在我跟踪的是Text组件，对应的是ReactTextViewManager。

public class ReactTextViewManager extends BaseViewManager<ReactTextView, ReactTextShadowNode> {
···@ReactProp(name = ViewProps.ELLIPSIZE_MODE)@ReactProp(name = ViewProps.TEXT_ALIGN_VERTICAL)@ReactPropGroup(names = {
          ViewProps.BORDER_RADIUS,
          ViewProps.BORDER_TOP_LEFT_RADIUS,
          ViewProps.BORDER_TOP_RIGHT_RADIUS,
          ViewProps.BORDER_BOTTOM_RIGHT_RADIUS,
          ViewProps.BORDER_BOTTOM_LEFT_RADIUS
  }, defaultFloat = YogaConstants.UNDEFINED)@ReactPropGroup(names = {          "borderColor", "borderLeftColor", "borderRightColor", "borderTopColor", "borderBottomColor"
  }, customType = "Color")
···
}

但我并没有找到backgroundColor和Color对应的声明。别急，不是还会递归父类么？果然在父类BaseViewManager找到了。

@ReactProp(name = PROP_BACKGROUND_COLOR, defaultInt = Color.TRANSPARENT, customType = "Color")  public void setBackgroundColor(T view, int backgroundColor) {
    view.setBackgroundColor(backgroundColor);
  }

其根本逻辑还是Native的View的setBackgroundColor()方法。

那么还有一个问题，我始终没有找到color的声明。猜测color应该也是以@ReactProp声明的，只不过没有在ViewManager的类里。突然想到所有JS的View都会在Native被封装为ShadowNode，每个ViewManager都会有个createShadowNodeInstance()方法来建立和ShadowNode的关系。ReactTextViewManager对应的是ReactTextShadowNode。在这个类里不仅找到了color的声明，还找到了非常熟悉的fontSize属性的声明。

public class ReactTextShadowNode extends LayoutShadowNode {
···@ReactProp(name = ViewProps.FONT_SIZE, defaultFloat = UNSET)public void setFontSize(float fontSize) {
        mFontSizeInput = fontSize;        if (fontSize != UNSET) {
            fontSize = mAllowFontScaling ? (float) Math.ceil(PixelUtil.toPixelFromSP(fontSize))
            : (float) Math.ceil(PixelUtil.toPixelFromDIP(fontSize));
            }
        mFontSize = (int) fontSize;
        markUpdated();
    }@ReactProp(name = ViewProps.COLOR)public void setColor(@Nullable Integer color) {
        mIsColorSet = (color != null);        if (mIsColorSet) {
            mColor = color;
        }
        markUpdated();
    }
···
}

但是说好的调用setTextColor()的，别只赋值给mColor就不管了~

好吧，那就全局搜一下mColor是怎么用的。在ReactTextShadowNode的这个方法里找到了答案。

private static void buildSpannedFromTextCSSNode(
      ReactTextShadowNode textShadowNode,
      SpannableStringBuilder sb,
      List<SetSpanOperation> ops) {
      ···
          ops.add(new SetSpanOperation(start, end, new ForegroundColorSpan(textShadowNode.mColor)));
          ops.add(new SetSpanOperation(start, end, new AbsoluteSizeSpan(textShadowNode.mFontSize)));
      ···
      }

原来并没有按照我猜测的调用setTextColor()套路出牌，而是使用SpannableString来实现文本效果。

总结以上结论，Native保存了一份JS属性和Native控件属性设置的映射表，所有flexbox的属性设置都是由Native控件的属性设置API实现。

通过跟踪源码，发现渲染流程及原理远不止本文所述，所以本文可能有理解误差，欢迎指正。