Package 

Class NativeViewHierarchyOptimizer


  • 
    public class NativeViewHierarchyOptimizer
    
                        

    Class responsible for optimizing the native view hierarchy while still respecting the final UI product specified by JS. Basically, JS sends us a hierarchy of nodes that, while easy to reason about in JS, are very inefficient to translate directly to native views. This class sits in between UIManagerModule, which directly receives view commands from JS, and , which enqueues actual operations on the native view hierarchy. It is able to take instructions from UIManagerModule and output instructions to the native view hierarchy that achieve the same displayed UI but with fewer views.

    Currently this class is only used to remove layout-only views, that is to say views that only affect the positions of their children but do not draw anything themselves. These views are fairly common because 1) containers are used to do layouting via flexbox and 2) the return of each Component#render() call in JS must be exactly one view, which means views are often wrapped in a unnecessary layer of hierarchy.

    This optimization is implemented by keeping track of both the unoptimized JS hierarchy and the optimized native hierarchy in ReactShadowNode.

    This optimization is important for view hierarchy depth (which can cause stack overflows during view traversal for complex apps), memory usage, amount of time spent during GCs, and time-to-display.

    Some examples of the optimizations this class will do based on commands from JS: - Create a view with only layout props: a description of that view is created as a ReactShadowNode in UIManagerModule, but this class will not output any commands to create the view in the native view hierarchy. - Update a layout-only view to have non-layout props: before issuing the updateShadowNode call to the native view hierarchy, issue commands to create the view we optimized away move it into the view hierarchy - Manage the children of a view: multiple manageChildren calls for various parent views may be issued to the native view hierarchy depending on where the views being added/removed are attached in the optimized hierarchy

    • Method Detail

      • handleUpdateView

         void handleUpdateView(ReactShadowNode node, String className, ReactStylesDiffMap props)

        Handles an updateView call. If a view transitions from being layout-only to not (or vice-versa)this could result in some number of additional createView and manageChildren calls. If the viewis layout only, no updateView call will be dispatched to the native hierarchy.

      • handleManageChildren

         void handleManageChildren(ReactShadowNode nodeToManage, Array<int> indicesToRemove, Array<int> tagsToRemove, Array<ViewAtIndex> viewsToAdd, Array<int> tagsToDelete)

        Handles a manageChildren call. This may translate into multiple manageChildren calls formultiple other views.

        NB: the assumption for calling this method is that all corresponding ReactShadowNodes havebeen updated **but tagsToDelete have NOT been deleted yet**. This is because we need to use themetadata from those nodes to figure out the correct commands to dispatch. This is unlike allother calls on this class where we assume all operations on the shadow hierarchy have alreadycompleted by the time a corresponding method here is called.

      • handleSetChildren

         void handleSetChildren(ReactShadowNode nodeToManage, ReadableArray childrenTags)

        Handles a setChildren call. This is a simplification of handleManagerChildren that only addschildren in index order of the childrenTags array

      • handleUpdateLayout

         void handleUpdateLayout(ReactShadowNode node)

        Handles an updateLayout call. All updateLayout calls are collected and dispatched at the end ofa batch because updateLayout calls to layout-only nodes can necessitate multiple updateLayoutcalls for all its children.

      • onBatchComplete

         void onBatchComplete()

        Processes the shadow hierarchy to dispatch all necessary updateLayout calls to the nativehierarchy. Should be called after all updateLayout calls for a batch have been handled.