RN，view创建过程浅析

本文分析的源码版本：
“react”: “16.3.1”,
“react-native”: “0.55.3”,
如何能快速的分析view的创建过程呢？
有个好方法，通过打断点来打印createInstance和render的调用栈，从而帮助我们分析出RN创建view的过程。
先看createInstance和render的调用栈与时序图：




页面启动的时候，RN会调用AppRegistry的runApplication方法，然后会调用renderApplication的renderApplication方法，之后会调用ReactNativeRenderer的renderd，这个接口是render的总入口，之后就是整个页面的render过程。
之后我们可以观察到createInstance和render的前半段过程都是一样的，从performUnitOfWork开始不同，让我们看看performUnitOfWork函数：

function performUnitOfWork(workInProgress) {
    // The current, flushed, state of this fiber is the alternate.
    // Ideally nothing should rely on this, but relying on it here
    // means that we don't need an additional field on the work in
    // progress.
    var current = workInProgress.alternate;

    // See if beginning this work spawns more work.
    startWorkTimer(workInProgress);
    {
      ReactDebugCurrentFiber.setCurrentFiber(workInProgress);
    }

    if (true && replayFailedUnitOfWorkWithInvokeGuardedCallback) {
      stashedWorkInProgressProperties = assignFiberPropertiesInDEV(
        stashedWorkInProgressProperties,
        workInProgress
      );
    }
    var next = beginWork(current, workInProgress, nextRenderExpirationTime);
    {
      ReactDebugCurrentFiber.resetCurrentFiber();
      if (isReplayingFailedUnitOfWork) {
        // Currently replaying a failed unit of work. This should be unreachable,
        // because the render phase is meant to be idempotent, and it should
        // have thrown again. Since it didn't, rethrow the original error, so
        // React's internal stack is not misaligned.
        rethrowOriginalError();
      }
    }
    if (true && ReactFiberInstrumentation_1.debugTool) {
      ReactFiberInstrumentation_1.debugTool.onBeginWork(workInProgress);
    }

    if (next === null) {
      // If this doesn't spawn new work, complete the current work.
      next = completeUnitOfWork(workInProgress);
    }

    ReactCurrentOwner.current = null;

    return next;
  }

从这里我们可以看到，调用beginWork()函数获取next节点，next就是下一个view容器，这个函数其实就是父render遍历view树的过程，过程中还会执行每一个子view的render。
再看调用performUnitOfWork的函数workLoop就一目了然了，先看源码：

  function workLoop(isAsync) {
    if (!isAsync) {
      // Flush all expired work.
      while (nextUnitOfWork !== null) {
        nextUnitOfWork = performUnitOfWork(nextUnitOfWork);
      }
    } else {
      // Flush asynchronous work until the deadline runs out of time.
      while (nextUnitOfWork !== null && !shouldYield()) {
        nextUnitOfWork = performUnitOfWork(nextUnitOfWork);
      }
    }
  }

在performUnitOfWork返回next不为空的时候，执行while循环，就是遍历view树的过程，也就是render的遍历过程了！
再看completeUnitOfWork的调用源码：

    if (next === null) {
      // If this doesn't spawn new work, complete the current work.
      next = completeUnitOfWork(workInProgress);
    }

当next===null时，也就是一个父view下的所有子view都已经遍历过的时候，此时所有view信息都保存在workInProgress中，执行completeUnitOfWork（workInProgress），会再执行一个循环，如果这些view没有被创建原生view的话，就会调用到createInstance创建原生view了（具体源码可以自己看下，比较简单）
至此，程序加载页面时，是如何调用到各个view的render，以及是如何调用createInstance的过程就已经清晰了。

接下来，以最基础的View组件为例，分析基础组件render的具体过程。

node_modules/react-native/Libraries/Components/View/View.js

class View extends ReactNative.NativeComponent<Props> {
  static propTypes = ViewPropTypes;
  static childContextTypes = ViewContextTypes;

  viewConfig = {
    uiViewClassName: 'RCTView',
    validAttributes: ReactNativeViewAttributes.RCTView,
  };

  getChildContext(): ViewChildContext {
    return {
      isInAParentText: false,
    };
  }

  render() {
    invariant(
      !(this.context.isInAParentText && Platform.OS === 'android'),
      'Nesting of <View> within <Text> is not supported on Android.',
    );

    // WARNING: This method will not be used in production mode as in that mode we
    // replace wrapper component View with generated native wrapper RCTView. Avoid
    // adding functionality this component that you'd want to be available in both
    // dev and prod modes.
    return <RCTView {...this.props} />;
  }
}

const RCTView = requireNativeComponent('RCTView', View, {
  nativeOnly: {
    nativeBackgroundAndroid: true,
    nativeForegroundAndroid: true,
  },
});

截取部分源码，可以看到viewConfig中有个uiViewClassName: ‘RCTView’,这个RCTView就是View控件在原生代码中映射的控件类名。
render返回的RCTView是通过requireNativeComponent生成的，再看requireNativeComponent
node_modules/react-native/Libraries/ReactNative/requireNativeComponent.js
源码：

  return createReactNativeComponentClass(viewName, getViewConfig);

这个部分最终返回上面函数的执行，所以再看看createReactNativeComponentClass
node_modules/react-native/Libraries/Renderer/shims/createReactNativeComponentClass.js

'use strict';

const {
  __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED,
} = require('ReactNative');

module.exports =
  __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED.createReactNativeComponentClass;

可以看到createReactNativeComponentClass是在ReactNative中定义的
另外说下：
__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED
从字面理解估计是未来要废弃的方法。
再看：
node_modules/react-native/Libraries/Renderer/shims/ReactNative.js

'use strict';

import type {ReactNativeType} from 'ReactNativeTypes';

let ReactNative;

if (__DEV__) {
  ReactNative = require('ReactNativeRenderer-dev');
} else {
  ReactNative = require('ReactNativeRenderer-prod');
}

module.exports = (ReactNative: ReactNativeType);

我们可以发现ReactNative原来就是ReactNativeRenderer-dev或ReactNativeRenderer-prod，区别是啥程序员都懂得，至于ReactNativeType，这是类似一个简化的接口，不做赘述了。现在看ReactNativeRenderer-dev，看名字就知道这个类是Render的具体实现者代码行数将近一万五，只能截取着看了。

__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED: {
    // Used as a mixin in many createClass-based components
    NativeMethodsMixin: NativeMethodsMixin,
    // Used by react-native-github/Libraries/ components
    ReactNativeBridgeEventPlugin: ReactNativeBridgeEventPlugin, // requireNativeComponent
    ReactNativeComponentTree: ReactNativeComponentTree, // ScrollResponder
    ReactNativePropRegistry: ReactNativePropRegistry, // flattenStyle, Stylesheet
    TouchHistoryMath: TouchHistoryMath, // PanResponder
    createReactNativeComponentClass: createReactNativeComponentClass, // RCTText, RCTView, ReactNativeART
    takeSnapshot: takeSnapshot
  }

先看这段，找到
__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED下的createReactNativeComponentClass了，再看具体定义：

/**
 * Creates a renderable ReactNative host component.
 * Use this method for view configs that are loaded from UIManager.
 * Use createReactNativeComponentClass() for view configs defined within JavaScript.
 *
 * @param {string} config iOS View configuration.
 * @private
 */
var createReactNativeComponentClass = function(name, callback) {
  return register(name, callback);
};

再看register：

var viewConfigCallbacks = new Map();
var viewConfigs = new Map();
/**
 * Registers a native view/component by name.
 * A callback is provided to load the view config from UIManager.
 * The callback is deferred until the view is actually rendered.
 * This is done to avoid causing Prepack deopts.
 */
function register(name, callback) {
  invariant(
    !viewConfigCallbacks.has(name),
    "Tried to register two views with the same name %s",
    name
  );
  viewConfigCallbacks.set(name, callback);
  return name;
}

这样就把这个view注册到viewConfigCallbacks中去了，而viewConfigCallbacks是在下面函数中被使用的

/**
 * Retrieves a config for the specified view.
 * If this is the first time the view has been used,
 * This configuration will be lazy-loaded from UIManager.
 */
function get$1(name) {
  var viewConfig = void 0;
  if (!viewConfigs.has(name)) {
    var callback = viewConfigCallbacks.get(name);
    invariant(
      typeof callback === "function",
      "View config not found for name %s",
      name
    );
    viewConfigCallbacks.set(name, null);
    viewConfig = callback();
    viewConfigs.set(name, viewConfig);
  } else {
    viewConfig = viewConfigs.get(name);
  }
  invariant(viewConfig, "View config not found for name %s", name);
  return viewConfig;
}

get$1是在createInstance函数中被调用，也正是在这个函数中调用了UIManager.createView，UIManager.createView则是直接调用原生的接口函数来创建原生view的。

createInstance: function(
    type,
    props,
    rootContainerInstance,
    hostContext,
    internalInstanceHandle
  ) {
    var tag = ReactNativeTagHandles.allocateTag();
    var viewConfig = get$1(type);

    {
      for (var key in viewConfig.validAttributes) {
        if (props.hasOwnProperty(key)) {
          deepFreezeAndThrowOnMutationInDev(props[key]);
        }
      }
    }

    var updatePayload = create(props, viewConfig.validAttributes);

    UIManager.createView(
      tag, // reactTag
      viewConfig.uiViewClassName, // viewName
      rootContainerInstance, // rootTag
      updatePayload
    );

    var component = new ReactNativeFiberHostComponent(tag, viewConfig);

    precacheFiberNode(internalInstanceHandle, tag);
    updateFiberProps(tag, props);

    // Not sure how to avoid this cast. Flow is okay if the component is defined
    // in the same file but if it's external it can't see the types.
    return component;
  },

函数的最后，生成了component返回给调用者使用。

另外，补充一个ReactNativeRenderer的主要变量的关系图，方便大家理解源码：

一下开始都是Java的代码了。
先给一个调用关系图：

原生的createView在UIManagerModule类中声明，而UIManagerModule类时每个控件都拥有的帮助管理控件的对象。createView源码如下：

  @ReactMethod
  public void createView(int tag, String className, int rootViewTag, ReadableMap props) {
    if (DEBUG) {
      String message =
          "(UIManager.createView) tag: " + tag + ", class: " + className + ", props: " + props;
      FLog.d(ReactConstants.TAG, message);
      PrinterHolder.getPrinter().logMessage(ReactDebugOverlayTags.UI_MANAGER, message);
    }
    mUIImplementation.createView(tag, className, rootViewTag, props);
  }

注解@ReactMethod的意思就是这个函数会由JS代码调用

我们可以看到个参数int tag, String className, int rootViewTag, ReadableMap props，正是JS代码中传入的参数
UIManager.createView(
tag, // reactTag
viewConfig.uiViewClassName, // viewName
rootContainerInstance, // rootTag
updatePayload
);
之后会调用UIImplementation的createView：

/**
   * Invoked by React to create a new node with a given tag, class name and properties.
   */
  public void createView(int tag, String className, int rootViewTag, ReadableMap props) {
    ReactShadowNode cssNode = createShadowNode(className);
    ReactShadowNode rootNode = mShadowNodeRegistry.getNode(rootViewTag);
    Assertions.assertNotNull(rootNode, "Root node with tag " + rootViewTag + " doesn't exist");
    cssNode.setReactTag(tag);
    cssNode.setViewClassName(className);
    cssNode.setRootTag(rootNode.getReactTag());
    cssNode.setThemedContext(rootNode.getThemedContext());

    mShadowNodeRegistry.addNode(cssNode);

    ReactStylesDiffMap styles = null;
    if (props != null) {
      styles = new ReactStylesDiffMap(props);
      cssNode.updateProperties(styles);
    }

    handleCreateView(cssNode, rootViewTag, styles);
  }

cssNode，rootNode分别存放着，css样式相关信息，和view本身的相关信息，此时真正我们view的style的相关属性通过props传入，通过 new ReactStylesDiffMap(props);生成一个map，也就是styles，然后通过cssNode.updateProperties(styles);设置给cssNode，过程如下，具体实现在ReactShadowNodeImpl的updateProperties：

  @Override
  public final void updateProperties(ReactStylesDiffMap props) {
    ViewManagerPropertyUpdater.updateProps(this, props);
    onAfterUpdateTransaction();
  }

再看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);
    }
  }

while循环里，所有样式设置被一个一个从props取出，设置给之前的cssNode
这些执行后，会调用handleCreateView：

  protected void handleCreateView(
          ReactShadowNode cssNode,
          int rootViewTag,
          @Nullable ReactStylesDiffMap styles) {
    if (!cssNode.isVirtual()) {
      mNativeViewHierarchyOptimizer.handleCreateView(cssNode, cssNode.getThemedContext(), styles);
    }
  }

再看NativeViewHierarchyOptimizer.handleCreateView：

  /**
   * Handles a createView call. May or may not actually create a native view.
   */
  public void handleCreateView(
      ReactShadowNode node,
      ThemedReactContext themedContext,
      @Nullable ReactStylesDiffMap initialProps) {
    if (!ENABLED) {
      int tag = node.getReactTag();
      mUIViewOperationQueue.enqueueCreateView(
          themedContext,
          tag,
          node.getViewClass(),
          initialProps);
      return;
    }

在这个会创建一个createview的任务，放入mUIViewOperationQueue队列中等待执行，
熟悉handler都懂得，不熟悉的请百度一下安卓handler，现在只讲最后的执行在CreateViewOperation的execute方法：

    @Override
      public void execute() {
      Systrace.endAsyncFlow(Systrace.TRACE_TAG_REACT_VIEW, "createView", mTag);
      mNativeViewHierarchyManager.createView(
          mThemedContext,
          mTag,
          mClassName,
          mInitialProps);
    }

再看mNativeViewHierarchyManager.createView：

public synchronized void createView(
      ThemedReactContext themedContext,
      int tag,
      String className,
      @Nullable ReactStylesDiffMap initialProps) {
    UiThreadUtil.assertOnUiThread();
    SystraceMessage.beginSection(
        Systrace.TRACE_TAG_REACT_VIEW,
        "NativeViewHierarchyManager_createView")
        .arg("tag", tag)
        .arg("className", className)
        .flush();
    try {
      ViewManager viewManager = mViewManagers.get(className);

      View view = viewManager.createView(themedContext, mJSResponderHandler);
      mTagsToViews.put(tag, view);
      mTagsToViewManagers.put(tag, viewManager);

      // Use android View id field to store React tag. This is possible since we don't inflate
      // React views from layout xmls. Thus it is easier to just reuse that field instead of
      // creating another (potentially much more expensive) mapping from view to React tag
      view.setId(tag);
      if (initialProps != null) {
        viewManager.updateProperties(view, initialProps);
      }
    } finally {
      Systrace.endSection(Systrace.TRACE_TAG_REACT_VIEW);
    }
  }

这里最终找到了ViewManager通过createView创建view：

  /**
   * Creates a view and installs event emitters on it.
   */
  public final T createView(
      ThemedReactContext reactContext,
      JSResponderHandler jsResponderHandler) {
    T view = createViewInstance(reactContext);
    addEventEmitters(reactContext, view);
    if (view instanceof ReactInterceptingViewGroup) {
      ((ReactInterceptingViewGroup) view).setOnInterceptTouchEventListener(jsResponderHandler);
    }
    return view;
  }

这正的创建工作交给了createViewInstance，这是个虚函数，ViewManager是虚基类，
所以这正的创建工作交给了最终实现他的类来完成了，譬如ReactTextViewManager会
@Override
public ReactTextView createViewInstance(ThemedReactContext context) {
return new ReactTextView(context);
}
new一个ReactTextView实例出来，也就是说会根据JS那边具体组件名称（譬如View，Text，Image），来创建相应的native的View来！
这时就最终创建出原生VIew了！（IOS同理）
非常感谢阅读