More markers for view operations

Reviewed By: astreet

Differential Revision: D2679126

fb-gh-sync-id: 882e815a7551d23b4594fdc2dd257b4f1cdbbab7

ReactAndroid/src/main/java/com/facebook/react/uimanager/NativeViewHierarchyManager.java

@@ -34,6 +34,8 @@ import com.facebook.react.bridge.SoftAssertions;
 import com.facebook.react.bridge.UiThreadUtil;
 import com.facebook.react.touch.JSResponderHandler;
 import com.facebook.react.uimanager.layoutanimation.LayoutAnimationController;
+import com.facebook.systrace.Systrace;
+import com.facebook.systrace.SystraceMessage;
 
 /**
  * Delegate of {@link UIManagerModule} that owns the native view hierarchy and mapping between
@@ -128,40 +130,50 @@ public class NativeViewHierarchyManager {
       int width,
       int height) {
     UiThreadUtil.assertOnUiThread();
+    SystraceMessage.beginSection(
+        Systrace.TRACE_TAG_REACT_VIEW,
+        "NativeViewHierarchyManager_updateLayout")
+        .arg("parentTag", parentTag)
+        .arg("tag", tag)
+        .flush();
+    try {
+      View viewToUpdate = resolveView(tag);
 
-    View viewToUpdate = resolveView(tag);
+      // Even though we have exact dimensions, we still call measure because some platform views (e.g.
+      // Switch) assume that method will always be called before onLayout and onDraw. They use it to
+      // calculate and cache information used in the draw pass. For most views, onMeasure can be
+      // stubbed out to only call setMeasuredDimensions. For ViewGroups, onLayout should be stubbed
+      // out to not recursively call layout on its children: React Native already handles doing that.
+      //
+      // Also, note measure and layout need to be called *after* all View properties have been updated
+      // because of caching and calculation that may occur in onMeasure and onLayout. Layout
+      // operations should also follow the native view hierarchy and go top to bottom for consistency
+      // with standard layout passes (some views may depend on this).
 
-    // Even though we have exact dimensions, we still call measure because some platform views (e.g.
+      viewToUpdate.measure(
-    // Switch) assume that method will always be called before onLayout and onDraw. They use it to
+          View.MeasureSpec.makeMeasureSpec(width, View.MeasureSpec.EXACTLY),
-    // calculate and cache information used in the draw pass. For most views, onMeasure can be
+          View.MeasureSpec.makeMeasureSpec(height, View.MeasureSpec.EXACTLY));
-    // stubbed out to only call setMeasuredDimensions. For ViewGroups, onLayout should be stubbed
-    // out to not recursively call layout on its children: React Native already handles doing that.
-    //
-    // Also, note measure and layout need to be called *after* all View properties have been updated
-    // because of caching and calculation that may occur in onMeasure and onLayout. Layout
-    // operations should also follow the native view hierarchy and go top to bottom for consistency
-    // with standard layout passes (some views may depend on this).
 
-    viewToUpdate.measure(
+      // Check if the parent of the view has to layout the view, or the child has to lay itself out.
-        View.MeasureSpec.makeMeasureSpec(width, View.MeasureSpec.EXACTLY),
+      if (!mRootTags.get(parentTag)) {
-        View.MeasureSpec.makeMeasureSpec(height, View.MeasureSpec.EXACTLY));
+        ViewManager parentViewManager = mTagsToViewManagers.get(parentTag);
-
+        ViewGroupManager parentViewGroupManager;
-    // Check if the parent of the view has to layout the view, or the child has to lay itself out.
+        if (parentViewManager instanceof ViewGroupManager) {
-    if (!mRootTags.get(parentTag)) {
+          parentViewGroupManager = (ViewGroupManager) parentViewManager;
-      ViewManager parentViewManager = mTagsToViewManagers.get(parentTag);
+        } else {
-      ViewGroupManager parentViewGroupManager;
+          throw new IllegalViewOperationException(
-      if (parentViewManager instanceof ViewGroupManager) {
+              "Trying to use view with tag " + tag +
-        parentViewGroupManager = (ViewGroupManager) parentViewManager;
+                  " as a parent, but its Manager doesn't extends ViewGroupManager");
+        }
+        if (parentViewGroupManager != null
+            && !parentViewGroupManager.needsCustomLayoutForChildren()) {
+          updateLayout(viewToUpdate, x, y, width, height);
+        }
       } else {
-        throw new IllegalViewOperationException("Trying to use view with tag " + tag +
-            " as a parent, but its Manager doesn't extends ViewGroupManager");
-      }
-      if (parentViewGroupManager != null
-          && !parentViewGroupManager.needsCustomLayoutForChildren()) {
         updateLayout(viewToUpdate, x, y, width, height);
       }
-    } else {
+    } finally {
-      updateLayout(viewToUpdate, x, y, width, height);
+      Systrace.endSection(Systrace.TRACE_TAG_REACT_VIEW);
     }
   }
 
@@ -180,18 +192,28 @@ public class NativeViewHierarchyManager {
       String className,
       @Nullable CatalystStylesDiffMap initialProps) {
     UiThreadUtil.assertOnUiThread();
-    ViewManager viewManager = mViewManagers.get(className);
+    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);
+      View view = viewManager.createView(themedContext, mJSResponderHandler);
-    mTagsToViews.put(tag, view);
+      mTagsToViews.put(tag, view);
-    mTagsToViewManagers.put(tag, viewManager);
+      mTagsToViewManagers.put(tag, viewManager);
 
-    // Use android View id field to store React tag. This is possible since we don't inflate
+      // 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
+      // 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
+      // creating another (potentially much more expensive) mapping from view to React tag
-    view.setId(tag);
+      view.setId(tag);
-    if (initialProps != null) {
+      if (initialProps != null) {
-      viewManager.updateProperties(view, initialProps);
+        viewManager.updateProperties(view, initialProps);
+      }
+    } finally {
+      Systrace.endSection(Systrace.TRACE_TAG_REACT_VIEW);
     }
   }
 

ReactAndroid/src/main/java/com/facebook/react/uimanager/UIViewOperationQueue.java

@@ -113,10 +113,12 @@ public class UIViewOperationQueue {
       mY = y;
       mWidth = width;
       mHeight = height;
+      Systrace.startAsyncFlow(Systrace.TRACE_TAG_REACT_VIEW, "updateLayout", mTag);
     }
 
     @Override
     public void execute() {
+      Systrace.endAsyncFlow(Systrace.TRACE_TAG_REACT_VIEW, "updateLayout", mTag);
       mNativeViewHierarchyManager.updateLayout(mParentTag, mTag, mX, mY, mWidth, mHeight);
     }
   }
@@ -136,10 +138,12 @@ public class UIViewOperationQueue {
       mThemedContext = themedContext;
       mClassName = className;
       mInitialProps = initialProps;
+      Systrace.startAsyncFlow(Systrace.TRACE_TAG_REACT_VIEW, "createView", mTag);
     }
 
     @Override
     public void execute() {
+      Systrace.endAsyncFlow(Systrace.TRACE_TAG_REACT_VIEW, "createView", mTag);
       mNativeViewHierarchyManager.createView(
           mThemedContext,
           mTag,