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 {
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 within 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 截取部分源码，可以看到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 void updateProps(T node, ReactStylesDiffMap props) {
ShadowNodeSetter 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同理）
非常感谢阅读