Android N中UI硬件渲染（hwui）的HWUI_NEW_OPS(基于Android 7.1)

原文地址：http://blog.csdn.net/jinzhuojun/article/details/54234354

• 背景

UI作为用户体验的核心之一，始终是Android每次升级中的重点。从Androd 3.0(Honeycomb)开始，Android开始支持 hwui（UI硬件加速）。到Android 4.0（ICS）时，硬件加速被默认开启。同时ICS还引入了 DisplayList的概念（不是OpenGL里的那个），它相当于是从View的绘制命令到GL命令之间的“中间语言”。它记录了绘制该View所需的全部信息，之后只要重放（replay）即可完成内容的绘制。这样如果View没有改动或只部分改动，便可重用或修改DisplayList，从而避免调用了一些上层代码，提高了效率。Android 4.3（JB）中引入了DisplayList的 defer操作，它主要用于对DisplayList中命令进行 Batch（批次）和 Merge（合并）。这样可以减少GL draw call和context切换以提高效率。之后，在Android 5.0（Lollipop）中又引入了 RenderNode（渲染节点）的概念，它是对DisplayList及一些View显示属性的进一步封装。代码上，一个View对应一个RenderNode（Native层对应同名类），其中管理着对应的DisplayList和OffscreenBuffer（如果该View为硬件绘制层）。每个向WindowManagerService注册的窗口对应一个RootRenderNode，通过它可以找到View层次结构中所有View的DisplayList信息。在Java层的DisplayListCanvas用于生成DisplayList，其在native层的对应类为RecordingCanvas（在Android N前为DisplayListCanvas）。另外Android L中还引入了 RenderThread（渲染线程）。所有的GL命令执行都放到这个线程上。渲染线程在RenderNode中存有渲染帧的所有信息，且还监听VSync信号，因此可以独立做一些属性动画。这样即便主线程block也可以保证动画流畅。引入渲染线程后ThreadedRenderer替代了Gl20Renderer，作为proxy用于主线程（UI线程）把渲染任务交给渲染线程。近期，在Android 7.0（Nougat）中又对hwui进行了小规模重构，引入了BakedOpRenderer, FrameBuilder, LayerBuilder, RecordingCanvas等类，用宏 HWUI_NEW_OPS管理。下面简单介绍下这些新成员：

• RecordingCanvas: 之前Java层的DisplayListCanvas对应native层的DisplayListCanvas。引入RecordingCanvas后，其在native层的对应物就变成了RecordingCanvas。和DisplayListCanvas类似，画在RecordingCanvas上的内容都会被记录在RenderNode的DisplayList中。
• BakedOpRenderer: 顾名思义，就是用于绘制batch/merge好的操作。用于替代之前的OpenGLRenderer。它是真正用GL绘制到on-screen surface上的。
• BakedOpDispatcher: 提供一系列onXXX（如onBitmapOp）和onMergedXXX（如onMergedBitmapOps）静态函数供replay时调用。这些dispatch函数最后一般都会通过GlopBuilder来构造Glop然后通过BakedOpRenderer的renderGlop()函数来用OpenGL绘制。
• LayerBuilder: 用于存储绘制某一层的操作和状态。替代了部分原DeferredDisplayList的工作。对于所有View通用，即如果View有render layer，它对应一个FBO；如果对于普通View，它对应的是SurfaceFlinger提供的surface。 其中的mBatches存储了当前层defer后（即batch/merge好）的绘制操作。
• FrameBuilder: 管理某一帧的构建，用于处理，优化和存储从RenderNode和LayerUpdateQueue中来的渲染命令，同时它的replayBakedOps()方法还用于该帧的绘制命令重放。一帧中可能需要绘制多个层，每一层的上下文都会存在相应的LayerBuilder中。在FrameBuilder中通过mLayerBuilders和mLayerStack存储一个layer stack。它替代了原Snapshot类的一部分功能。
• OffscreenBuffer: 用于替代Layer类，但是设计上更轻量，而且自带内存池（通过OffscreenBufferPool）。
• LayerUpdateQueue：用于记录类型为硬件绘制层的RenderNode的更新操作。之后会通过FrameBuilder将该layer对应的RenderNode通过deferNodeOps()方法进行处理。
• RecordedOp: 由RecordedCanvas将View中的绘制命令转化为RecordedOp。RecordedOp也是DisplayList中的基本元素，用于替代Android N之前的DisplayListOp。它有一坨各式各样的继承类代表各种各样的绘制操作。BakedOpState是RecordedOp和相应的状态的自包含封装（封装的过程称为bake）。
• BatchBase: LayerBuilder中对DisplayList进行batch/merge处理后的结果以BatchBase形式保存在LayerBuilder的mBatches成员中。它有两个继承类分别为OpBatch和MergingOpBatch，分别用于不可合并和可合并操作。

概括下它们和相关类的关系图如下，接下来从DisplayList(RenderNode)的构建和绘制两个阶段分析下具体有哪些改动。

• RenderNode构建

我们知道，通常情况下，App要完成一帧渲染，是通过ViewRootImpl的performTraversals()函数来实现。而它又可分为measure, layout, draw三个阶段。上面这些改动主要影响的是最后这步，因此我们就主要focus在draw这个阶段的流程。首先看DisplayList是怎么录制的。在ViewRootImpl::performDraw()中会调用draw()函数。当判断需要进行绘制时（比如有脏区域，或在动画中时），又如果硬件加速可用（通过ThreadedRenderer的isEnabled()），会进行下面的重绘动作。接下来根据是否有相关请求（如resize时）或offset是否有变化来判断是否要调用ThreadedRenderer的invalidRoot()来标记更新RootRenderNode。

扯个题外话。和Android M相比，N中UI子系统中加入了不少对用户进行窗口resize的处理，主要应该是为了Android N新增加的多窗口分屏模式。比如当用户拖拽分屏窗口边缘时，onWindowDragResizeStart()被调用。它其中会创建BackdropFrameRenderer。BackdropFrameRenderer本身运行单独的线程，它负责在resize窗口而窗口绘制来不及的情况下填充背景。它会通过addRenderNode()加入专用的RenderNode。同时，Android N中将DecorView从PhoneWindow中分离成一个单独的文件，并实现新加的WindowCallbacks接口。它主要用于当用户变化窗口大小时ViewRootImpl对DecorView的回调。因为ViewRootImpl和WindowManagerService通信，它会被通知到窗口变化，然后回调到DecorView中。而DecorView中的相应回调会和BackupdropFrameRenderer交互。如updateContentDrawBounds()中最后会调用到了BackupdropFrmeRenderer的onContentDrawn()函数，其返回值代表在下面的内容绘制后是否需要再发起一次绘制。如果需要，之后会调用requestDrawWindow()。

回到ViewRootImpl::performDraw()函数，接下来，最重要的就是通过ThreadedRenderer的draw()来进行绘制。在这个draw()函数中，比较重要的一步是通过updateRootDisplayList()函数来更新根结点的DisplayList。

652    private void updateRootDisplayList(View view, HardwareDrawCallbacks callbacks) {
653        Trace.traceBegin(Trace.TRACE_TAG_VIEW, "Record View#draw()");
654        updateViewTreeDisplayList(view);
655
656        if (mRootNodeNeedsUpdate || !mRootNode.isValid()) {
657            DisplayListCanvas canvas = mRootNode.start(mSurfaceWidth, mSurfaceHeight);
658            try {
659                final int saveCount = canvas.save();
660                canvas.translate(mInsetLeft, mInsetTop);
661                callbacks.onHardwarePreDraw(canvas);
662
663                canvas.insertReorderBarrier();
664                canvas.drawRenderNode(view.updateDisplayListIfDirty());
665                canvas.insertInorderBarrier();
666
667                callbacks.onHardwarePostDraw(canvas);
668                canvas.restoreToCount(saveCount);
669                mRootNodeNeedsUpdate = false;
670            } finally {
671                mRootNode.end(canvas);
672            }
673        }
674        Trace.traceEnd(Trace.TRACE_TAG_VIEW);
675    }

函数updateRootDisplayList()中的updateViewTreeDisplayList()会调到DecorView的updateDisplayListIfDirty()函数。这个函数主要功能是更新DecorView对应的RenderNode中的DisplayList。它返回的RenderNode会通过RecordingCanvas::drawRenderNode()函数将之作为RenderNodeOp加入到RootRenderNode的DisplayList中。函数updateDisplayListIfDirty()中首先判断当前View是否需要更新。如果不需要就调用dispatchGetDisplayList()让子View更新，然后直接返回。否则就是当前View的DisplayList需要更新。这里我们假设是第一次绘制，更新DisplayList的流程首先通过RenderNode的start()来获得一个用于记录绘制操作的Canvas，即DisplayListCanvas（在Android M中Java层由GLES20RecordingCanvas改为DisplayListCanvas，native层中的DisplayListRenderer改为DisplayListCanvas，Android N中native层中的DisplayListCanvas改为RecordingCanvas）。

接下去就是比较关键的步骤了。这里就要分几种情况了，一个View可以为三种类型（LAYER_TYPE_NONE, LAYER_TYPE_SOFTWARE, LAYER_TYPE_HARDWARE）中的一种。LAYER_TYPE_NONE为默认值，代表没有layer。LAYER_TYPE_SOFTWARE代表该View有软件层，以bitmap为back，内容用软件渲染。LAYER_TYPE_HARDWARE和LAYER_TYPE_SOFTWARE类似，区别在于其有硬件层，以FBO（Framebuffer object）为back，内容使用硬件渲染。如果硬件加速没有打开，它的行为和LAYER_TYPE_SOFTWARE是一样的。

16145            final DisplayListCanvas canvas = renderNode.start(width, height);
16146            canvas.setHighContrastText(mAttachInfo.mHighContrastText);
16147
16148            try {
16149                if (layerType == LAYER_TYPE_SOFTWARE) {
16150                    buildDrawingCache(true);
16151                    Bitmap cache = getDrawingCache(true);
16152                    if (cache != null) {
16153                        canvas.drawBitmap(cache, 0, 0, mLayerPaint);
16154                    }
16155                } else {
16156                    computeScroll();
16157
16158                    canvas.translate(-mScrollX, -mScrollY);
16159                    mPrivateFlags |= PFLAG_DRAWN | PFLAG_DRAWING_CACHE_VALID;
16160                    mPrivateFlags &= ~PFLAG_DIRTY_MASK;
16161
16162                    // Fast path for layouts with no backgrounds
16163                    if ((mPrivateFlags & PFLAG_SKIP_DRAW) == PFLAG_SKIP_DRAW) {
16164                        dispatchDraw(canvas);
16165                        if (mOverlay != null && !mOverlay.isEmpty()) {
16166                            mOverlay.getOverlayView().draw(canvas);
16167                        }
16168                    } else {
16169                        draw(canvas);
16170                    }
16171                }
16172            } finally {
16173                renderNode.end(canvas);
16174                setDisplayListProperties(renderNode);
16175            }

如果当前View是软件渲染层（类型为LAYER_TYPE_SOFTWARE）的话，则调用buildDrawingCache()获得Bitmap后调用drawBitmap()将该Bitmap记录到DisplayListCanvas中。现在Android中都默认硬件渲染了，为什么还要考虑软件渲染层呢?一方面有些平台不支持硬件渲染，或app不启用硬件加速，另一方面有些UI控件不支持硬件渲染 。在复杂的View（及子View）在动画过程中，可以被绘制成纹理，这样只需要画一次。显然，在View经常更新的情况下并不适用。因为这样每次都需要重新用软件渲染，如果硬件渲染打开时还要上传成硬件纹理（上传纹理是个比较慢的操作）。类似的，硬件渲染层（LAYER_TYPE_HARDWARE）也是适用于类似的复杂View结构进行属性动画的场景，但它与LAYER_TYPE_SOFTWARE的层的区别为它对应FBO，可以直接硬件渲染生成纹理。因此渲染的过程中不需要先生成Bitmap，从而省去了上传成硬件纹理的这一步操作。

如果当前View对应LAYER_TYPE_NONE或者LAYER_TYPE_HARDWARE，下面会考查是否为没有背景的Layout。这种情况下当前View没什么好画的，会走快速路径。即通过dispatchDraw()直接让子View重绘。否则就调draw()来绘制当前View及其子View。注意View中的draw()有两个重载同名函数。一个参数的版本用于直接调用。三个参数的版本用于ViewGroup中drawChild()时调用。这里调的是一个参数的版本。这个draw()函数中会按下面的顺序进行绘制（DisplayList的更新）：

17162        /*
17163         * Draw traversal performs several drawing steps which must be executed
17164         * in the appropriate order:
17165         *
17166         *      1. Draw the background
17167         *      2. If necessary, save the canvas' layers to prepare for fading
17168         *      3. Draw view's content
17169         *      4. Draw children
17170         *      5. If necessary, draw the fading edges and restore layers
17171         *      6. Draw decorations (scrollbars for instance)
17172         */

这些是通过drawBackground(), onDraw(), dispatchDraw()和onDrawForeground()等函数实现。这些函数本质上就是将相应内容绘制到提供的DisplayListCanvas上。由于View是以树形层次结构组织的，draw()中会通过dispatchDraw()来更新子View的DisplayList。dispatchDraw()为对每个子View调用drawChild()。然后调用子View的draw()函数（这次就是上面说的draw()的三个参数的版本了）。这个版本的draw()函数里会更新其View的DisplayList，然后调用DisplayListCanvas的drawRenderNode()将该子view对应的RenderNode记录到其父view的DisplayList中去。这样便根据View的树型结构生成了DisplayList的树型结构。

其中onDraw()用于绘制当前View的自定义UI，它是每个View需要自定义的成员函数。比较典型地，在View的绘制函数中会调用canvas的drawXXX函数。比如canvas.drawLine()，它会通过JNI最后调到RecordingCanvas.cpp中的RecordingCanvas::drawLines()：

284void RecordingCanvas::drawLines(const float* points, int floatCount, const SkPaint& paint) {
285    if (CC_UNLIKELY(floatCount < 4 || PaintUtils::paintWillNotDraw(paint))) return;
286    floatCount &= ~0x3; // round down to nearest four
287
288    addOp(alloc().create_trivial(
289            calcBoundsOfPoints(points, floatCount),
290            *mState.currentSnapshot()->transform,
291            getRecordedClip(),
292            refPaint(&paint), refBuffer(points, floatCount), floatCount));
293}

RecordingCanvas中绝大多数的drawXXX系函数都是类似于这样，通过addOp()将一个RecordedOp的继承类存到其成员mDisplayList中。RecordedOp家庭成员很多，有不少继承类，每个对应一种操作。操作的种类可以参照下这个表：

#define MAP_OPS_BASED_ON_TYPE(PRE_RENDER_OP_FN, RENDER_ONLY_OP_FN, UNMERGEABLE_OP_FN, MERGEABLE_OP_FN) \
76        PRE_RENDER_OP_FN(RenderNodeOp) \
77        PRE_RENDER_OP_FN(CirclePropsOp) \
78        PRE_RENDER_OP_FN(RoundRectPropsOp) \
79        PRE_RENDER_OP_FN(BeginLayerOp) \
80        PRE_RENDER_OP_FN(EndLayerOp) \
81        PRE_RENDER_OP_FN(BeginUnclippedLayerOp) \
82        PRE_RENDER_OP_FN(EndUnclippedLayerOp) \
83        PRE_RENDER_OP_FN(VectorDrawableOp) \
84        \
85        RENDER_ONLY_OP_FN(ShadowOp) \
86        RENDER_ONLY_OP_FN(LayerOp) \
87        RENDER_ONLY_OP_FN(CopyToLayerOp) \
88        RENDER_ONLY_OP_FN(CopyFromLayerOp) \
89        \
90        UNMERGEABLE_OP_FN(ArcOp) \
91        UNMERGEABLE_OP_FN(BitmapMeshOp) \
92        UNMERGEABLE_OP_FN(BitmapRectOp) \
93        UNMERGEABLE_OP_FN(ColorOp) \
94        UNMERGEABLE_OP_FN(FunctorOp) \
95        UNMERGEABLE_OP_FN(LinesOp) \
96        UNMERGEABLE_OP_FN(OvalOp) \
97        UNMERGEABLE_OP_FN(PathOp) \
98        UNMERGEABLE_OP_FN(PointsOp) \
99        UNMERGEABLE_OP_FN(RectOp) \
100        UNMERGEABLE_OP_FN(RoundRectOp) \
101        UNMERGEABLE_OP_FN(SimpleRectsOp) \
102        UNMERGEABLE_OP_FN(TextOnPathOp) \
103        UNMERGEABLE_OP_FN(TextureLayerOp) \
104        \
105        MERGEABLE_OP_FN(BitmapOp) \
106        MERGEABLE_OP_FN(PatchOp) \
107        MERGEABLE_OP_FN(TextOp)

各个View的DisplayList更新好后，回到udpateRootDisplayList()。如果发现RootRenderNode也需要更新，则先通过Java层的RenderNode::start()获得DisplayListCanvas，在这个Canvas上的动作都会被记录到DisplayList中，直到调用RenderNode.end()。然后为了防止对上下文状态的影响，用Canvas::save()和Canvas::restoreToCount()来生成临时的画布状态。再接下来就是通过drawRenderNode()将DecorView的RenderNode以RenderNodeOp的形式记录到RootRenderNode。

以上为DisplayList构建过程，列个大体流程图备忘。

• RenderNode绘制

在ThreadedRenderer的draw()函数中构建完DisplayList后，接下来需要准备渲染了。首先通过JNI调用nSyncAndDrawFrame()调用到native层的android_view_ThreadedRenderer_syncAndDrawFrame()。其中将参数中的FrameInfo数组传到RenderProxy的mFrameInfo成员中。它是Android M开始加入用来细化hwui性能统计的。同时调用RenderProxy的syncAndDrawFrame()函数，并将创建的TreeObserver作为参数。函数syncAndDrawFrame()中即调用DrawFrameTask（这是RenderThread的TaskQueue中的特殊Task实例）的drawFrame()函数。继而通过postAndWait()往RenderThread的TaskQueue里插入自身（即DrawFrameTask）来申请新一帧的渲染。在RenderThread的queue()函数中会按Task的运行时间将之插入到适当的位置。接着postAndWait()函数中会block UI线程等待渲染线程将之unblock。渲染线程在N中的改动不大，这里就不花太多文字介绍了，需要的时候把它当作跨线程调用即可。

另一边，渲染线程处理这个DrawFrameTask时会调用到其run()函数：

85void DrawFrameTask::run() {
86    ATRACE_NAME("DrawFrame");
87
88    bool canUnblockUiThread;
89    bool canDrawThisFrame;
90    {
91        TreeInfo info(TreeInfo::MODE_FULL, *mContext);
92        info.observer = mObserver;
93        canUnblockUiThread = syncFrameState(info);
94        canDrawThisFrame = info.out.canDrawThisFrame;
95    }
96
97    // Grab a copy of everything we need
98    CanvasContext* context = mContext;
99
100    // From this point on anything in "this" is *UNSAFE TO ACCESS*
101    if (canUnblockUiThread) {
102        unblockUiThread();
103    }
104
105    if (CC_LIKELY(canDrawThisFrame)) {
106        context->draw();
107    }
108
109    if (!canUnblockUiThread) {
110        unblockUiThread();
111    }
112}

其中首先通过DrawFrameTask::syncFrameState()函数将主线程的渲染信息（如DisplayList，Property和Bitmap等）同步到渲染线程。这个函数中首先会处理DrawFrameTask中的mLayers。它是DeferredLayerUpdater的vector，顾名思义，就是延迟处理的layer更新任务。这主要用于TextureView。TextureView是比较特殊的类。它通常用于显示内容流，生产者端可以是另一个进程。中间通过BufferQueue进行buffer的传输和交换。当有新的buffer来到（或者有属性变化，如visibility等）是，会通过回调设置标志位(mUpdateLayer)并通过invalidate()调度下一次重绘。当下一次draw()被调用时，先通过applyUpdate()->updateSurfaceTexture()->ThreadedRenderer::pushLayerUpdate()，再调到渲染线程中的 DrawFrameTask::pushLayerUpdate()，将本次更新记录在DrawFrameTask的mLayers中。这样，在后面调用DrawFrameTask::syncFrameState()是会依次调用mLayers中的apply()进行真正的更新。这里调用它的apply()函数就会取新可用buffer（通过doUpdateTexImage()函数），并将相关纹理信息更新到mLayer。在syncFrameState()函数中，接下来，通过CanvasContext的prepareTree()继而调用RenderNode的prepareTree()同步渲染信息。最后会输出TreeInfo结构，其中的prepareTextures代表纹理上传是否成功。如果为false，说明texture cache用完了。这样为了防止渲染线程在渲染过程中使用的资源和主线程竞争，在渲染线程绘制当前帧时就不能让主线程继续往下跑了，也就不能做到真正并行。在sync完数据后，DrawFrameTask::run()最后会调用CanvasContext::draw()来进行接下来的渲染。这部分的大体流程如下：

接下来瞄下CanvasContext::draw()里做了什么。先要小小准备下EGL环境，比如通过EglManager的beginFrame()函数，继而用eglMakeCurrent()将渲染context切换到相应的surface。然后EglManager的damageFrame()设定当前帧的脏区域（如果gfx平台支持局部更新的话）。接下来就是绘制的主体部分了。这也是N中改动比较大的部分。

405    auto& caches = Caches::getInstance();
406    FrameBuilder frameBuilder(dirty, frame.width(), frame.height(), mLightGeometry, caches);
407
408    frameBuilder.deferLayers(mLayerUpdateQueue);
409    mLayerUpdateQueue.clear();
410
411    frameBuilder.deferRenderNodeScene(mRenderNodes, mContentDrawBounds);
412
413    BakedOpRenderer renderer(caches, mRenderThread.renderState(),
414            mOpaque, mLightInfo);
415    frameBuilder.replayBakedOps(renderer);
416    profiler().draw(&renderer);
417    bool drew = renderer.didDraw();

先得到Caches的实例。它是一个单例类，包含了各种绘制资源的cache。然后创建FrameBuilder。该类用于当前帧的构建。FrameBuilder的构造函数中又会创建对应fbo0的LayerBuilder。fbo0即对应通过SurfaceFlinger申请来的on-screen surface，然后将之放入layer stack（通过mLayerBuilders和mLayerStack两个成员维护）。同时还会在initializeSaveStack()函数中创建和初始化Snapshot。就像名字一样，它保存了渲染surface的当前状态的一个“快照”。每个Snapshot有一个指向前继的Snapshot，从而形成一个"栈"。每次调用save()和restore()就相当于压栈和弹栈。

接下来deferLayers()函数处理LayerUpdateQueue中的元素。之前在渲染线程每画一帧前同步信息时调用RenderNode::prepareTree()会遍历DisplayList的树形结构，对于子节点递归调用prepareTreeImpl()，如果是render layer，在RenderNode::pushLayerUpdate()中会将该layer的更新操作记录到LayerUpdateQueue中。至于哪些节点是render layer。主要是根据之前提到的view类型（LAYER_TYPE_NONE/SOFTWARE/HARDWARE）。但会有一个优化，如果一个普通view满足promotedToLayer()定义的条件，它会被当做render layer处理。

76void FrameBuilder::deferLayers(const LayerUpdateQueue& layers) {
77    // Render all layers to be updated, in order. Defer in reverse order, so that they'll be
78    // updated in the order they're passed in (mLayerBuilders are issued to Renderer in reverse)
79    for (int i = layers.entries().size() - 1; i >= 0; i--) {
80        RenderNode* layerNode = layers.entries()[i].renderNode;
81        // only schedule repaint if node still on layer - possible it may have been
82        // removed during a dropped frame, but layers may still remain scheduled so
83        // as not to lose info on what portion is damaged
84        OffscreenBuffer* layer = layerNode->getLayer();
...
97
98            saveForLayer(layerNode->getWidth(), layerNode->getHeight(), 0, 0,
99                    layerDamage, lightCenter, nullptr, layerNode);
100
101            if (layerNode->getDisplayList()) {
102                deferNodeOps(*layerNode);
103            }
104            restoreForLayer();

回到deferLayers()函数。这里就是把LayerUpdateQueue里的元素按逆序拿出来，依次调用saveForLayer()，deferNodeOps()和restoreForLayer()。saveForLayer()为该render laye创建Snapshot和LayerBuilder并放进mLayerStack和mLayerBuilders。而restoreForLayer()则是它的逆操作。Layer stack和canvas state是栈的结构。saveForLayer() 和restoreForLayer()就相当于一个push stack，一个pop stack。这里核心的deferNodeOps()函数处理该layer对应的DisplayList，将它们按以下类型以batch的形式组织存放在LayerBuilder的mBatches成员中。其中同一类型中能合并的操作还会进行合并（目前只支持Bitmap, Text和Patch三种类型的操作合并）。Batch的类型有以下几种：

45    enum {
46        Bitmap,
47        MergedPatch,
48        AlphaVertices,
49        Vertices,
50        AlphaMaskTexture,
51        Text,
52        ColorText,
53        Shadow,
54        TextureLayer,
55        Functor,
56        CopyToLayer,
57        CopyFromLayer,
58
59        Count // must be last
60    };

下面看下deferNodeOps()函数里是怎么处理RenderNode的。

511void FrameBuilder::deferNodeOps(const RenderNode& renderNode) {
512    typedef void (*OpDispatcher) (FrameBuilder& frameBuilder, const RecordedOp& op);
513    static OpDispatcher receivers[] = BUILD_DEFERRABLE_OP_LUT(OP_RECEIVER);
514
515    // can't be null, since DL=null node rejection happens before deferNodePropsAndOps
516    const DisplayList& displayList = *(renderNode.getDisplayList());
517    for (auto& chunk : displayList.getChunks()) {
...
522        for (size_t opIndex = chunk.beginOpIndex; opIndex < chunk.endOpIndex; opIndex++) {
523            const RecordedOp* op = displayList.getOps()[opIndex];
524            receivers[op->opId](*this, *op);

DisplayList以chunk为单位组合RecordedOp。这些RecordedOp的opId代表它们的类型。根据这个类型调用receivers这个查找表（通过BUILD_DEFERABLE_OP_LUT构造）中的函数。它会调用FrameBuilder中相应的deferXXX函数（比如deferArcOp, deferBitmapOp, deferRenderNodeOp等）。这些deferXXX系函数一般会将RecordedOp用BakedOpState封装一下，然后会调用LayerBuilder的deferUnmergeableOp()和deferMergeableOp()函数将BakedOpState组织进mBatches成员。同时还有两个查找表mBatchLookup和mMergingBatchLookup分别用于不能合并的batch（OpBatch）和能合并的batch（MergingOpBatch）。它们分别用于查找特定类型的最近一个OpBatch或者MergingOpBatch。

先看下deferUnmergeableOp()函数。它会将BakedOpState按batch类型放进mBatches中。mBatches是指向BatchBase对象的vector，每个处理好的BakedOpState都会按类型放进来。如果还未有该类型的batch则创建OpBatch，并把它插入到mBatches的末尾。同时插入mBatchLookup这个查找表（batchId到最近一个该类型的OpBatch对象的映射）。这样之后处理同类型的BakedOpState时候，就会先搜索这个查找表。假如找到了，则进一步在mBatches数组中找到相应的OpBatch并通过它的batchOp()将该BakedOpState加入。

287void LayerBuilder::deferUnmergeableOp(LinearAllocator& allocator,
288        BakedOpState* op, batchid_t batchId) {
289    onDeferOp(allocator, op);
290    OpBatch* targetBatch = mBatchLookup[batchId];
291
292    size_t insertBatchIndex = mBatches.size();
293    if (targetBatch) {
294        locateInsertIndex(batchId, op->computedState.clippedBounds,
295                (BatchBase**)(&targetBatch), &insertBatchIndex);
296    }
297
298    if (targetBatch) {
299        targetBatch->batchOp(op);
300    } else  {
301        // new non-merging batch
302        targetBatch = allocator.create(batchId, op);
303        mBatchLookup[batchId] = targetBatch;
304        mBatches.insert(mBatches.begin() + insertBatchIndex, targetBatch);
305    }
306}

接下来看用于合并操作的deferMergeableOp()函数。它也是类似的，当没有可以合并的MergingOpBatch时会创建新的，并且插入到mBatches。因为可能存在情况这个batchId在mBatches中有但是mMergingBatchLookup中没找到（说明还没有可合并的MergingOpBatch对象）或者通过MergingOpBatch::canMergeWidth()判断不满足合并条件。这时候就要插入到mBatches中该类型所在位置。如果很顺利的情况下，前面已经有MergingOpBatch在mMergingBatchLookup中而且又满足合并条件，就通过MergingOpBatch::mergeOp()将该BakedOpState和已有的进行合并。

308void LayerBuilder::deferMergeableOp(LinearAllocator& allocator,
309        BakedOpState* op, batchid_t batchId, mergeid_t mergeId) {
310    onDeferOp(allocator, op);
311    MergingOpBatch* targetBatch = nullptr;
312
313    // Try to merge with any existing batch with same mergeId
314    auto getResult = mMergingBatchLookup[batchId].find(mergeId);
315    if (getResult != mMergingBatchLookup[batchId].end()) {
316        targetBatch = getResult->second;
317        if (!targetBatch->canMergeWith(op)) {
318            targetBatch = nullptr;
319        }
320    }
321
322    size_t insertBatchIndex = mBatches.size();
323    locateInsertIndex(batchId, op->computedState.clippedBounds,
324            (BatchBase**)(&targetBatch), &insertBatchIndex);
325
326    if (targetBatch) {
327        targetBatch->mergeOp(op);
328    } else  {
329        // new merging batch
330        targetBatch = allocator.create(batchId, op);
331        mMergingBatchLookup[batchId].insert(std::make_pair(mergeId, targetBatch));
332
333        mBatches.insert(mBatches.begin() + insertBatchIndex, targetBatch);
334    }
335}

回到CanvasContext::draw()函数，处理好layer后，下面得就是通过FrameBuilder::deferRenderNodeScene()函数处理FrameBuilder成员mRenderNodes中的RenderNode，其中包含了RootRenderNode（也可能有其它的RenderNode，比如backdrop和overlay nodes）。对于每个RenderNode，如果需要绘制则调用FrameBuilder的deferRenderNode()函数：

117void FrameBuilder::deferRenderNode(float tx, float ty, Rect clipRect, RenderNode& renderNode) {
118    renderNode.computeOrdering();
119
120    mCanvasState.save(SaveFlags::MatrixClip);
121    mCanvasState.translate(tx, ty);
122    mCanvasState.clipRect(clipRect.left, clipRect.top, clipRect.right, clipRect.bottom,
123            SkRegion::kIntersect_Op);
124    deferNodePropsAndOps(renderNode);
125    mCanvasState.restore();
126}

这里和前面类似，会为之创建独立的Snapshot（Canvas渲染状态），deferNodePropsAndOps()根据RenderNode中的RenderProperties通过CanvasState设置一堆状态。如果该RenderNode对应是一个render layer，则将它封装为LayerOp（绘制offscreen buffer）并通过deferUnmergeableOp()加入batch。如果该RenderNode对应RenderProperties有半透明效果且不是render layer，则可以将该RenderNode绘制到一个临时的layer（称为save layer）。这是通过BeginLayerOp和EndLayerOp来记录的。正常情况下，还是通过deferNodeOps()来将RenderNode进行batch/merge。这个函数前面已有说明。

再次回到CanvasContext::draw()函数，下面终于要真得进行渲染了。首先创建BakedOpRenderer，然后调用FrameBuilder::replayBakedOps()函数并将BakedOpRenderer作为参数传进去。注意这是个模板函数，这里模板参数为BakedOpDispatcher。在replayBakedOps()函数中会构造两个用于处理BakedOpState的函数查找表。它们将BakedOpState按操作类型分发到BakedOpDispatcher的相应静态处理函数（onXXX或者onMergedXXX，分别用于非合并和合并的操作） 。

87    template 
88    void replayBakedOps(Renderer& renderer) {
89        std::vector temporaryLayers;
90        finishDefer();
91        /**
92         * Defines a LUT of lambdas which allow a recorded BakedOpState to use state->op->opId to
93         * dispatch the op via a method on a static dispatcher when the op is replayed.
94         *
95         * For example a BitmapOp would resolve, via the lambda lookup, to calling:
96         *
97         * StaticDispatcher::onBitmapOp(Renderer& renderer, const BitmapOp& op, const BakedOpState& state);
98         */
99        #define X(Type) \
100                [](void* renderer, const BakedOpState& state) { \
101                    StaticDispatcher::on##Type(*(static_cast(renderer)), \
102                            static_cast(*(state.op)), state); \
103                },
104        static BakedOpReceiver unmergedReceivers[] = BUILD_RENDERABLE_OP_LUT(X);
105        #undef X
106
107        /**
108         * Defines a LUT of lambdas which allow merged arrays of BakedOpState* to be passed to a
109         * static dispatcher when the group of merged ops is replayed.
110         */
111        #define X(Type) \
112                [](void* renderer, const MergedBakedOpList& opList) { \
113                    StaticDispatcher::onMerged##Type##s(*(static_cast(renderer)), opList); \
114                },
115        static MergedOpReceiver mergedReceivers[] = BUILD_MERGEABLE_OP_LUT(X);
116        #undef X
117

如前面如述，之前已经在FrameBuilder中构造了LayerBuilder的stack。接下来，这儿就是按push时的逆序（z-order高到底）对其中的BakedOpState进行replay，因为下面的layer可能会依赖的上面layer的渲染结果。比如要把上面layer画在FBO上的东西当成纹理画到下一层layer上。对于layer（persistent或者temporary的），先在BakedOpRenderer::startRepaintLayer()中初始化相关GL环境，比如创建FBO，绑定layer对应OffscreenBuffer中的纹理，设置viewport，清color buffer等等。对应地，BakedOpRenderer::endLayer()中最相应的销毁和清理工作。中间调用LayerBuilder::replayBakedOpsImpl()函数做真正的replay动作。对于fbo0（即on-screen surface），也是类似的，只是把startRepaintLayer()和endLayer()换成BakedOpRenderer::startFrame()和BakedOpRenderer::endFrame()。它们的功能也是初始化和销毁GL环境。

118        // Relay through layers in reverse order, since layers
119        // later in the list will be drawn by earlier ones
120        for (int i = mLayerBuilders.size() - 1; i >= 1; i--) {
121            GL_CHECKPOINT(MODERATE);
122            LayerBuilder& layer = *(mLayerBuilders[i]);
123            if (layer.renderNode) {
124                // cached HW layer - can't skip layer if empty
125                renderer.startRepaintLayer(layer.offscreenBuffer, layer.repaintRect);
126                GL_CHECKPOINT(MODERATE);
127                layer.replayBakedOpsImpl((void*)&renderer, unmergedReceivers, mergedReceivers);
128                GL_CHECKPOINT(MODERATE);
129                renderer.endLayer();
130            } else if (!layer.empty()) {
131                // save layer - skip entire layer if empty (in which case, LayerOp has null layer).
132                layer.offscreenBuffer = renderer.startTemporaryLayer(layer.width, layer.height);
133                temporaryLayers.push_back(layer.offscreenBuffer);
134                GL_CHECKPOINT(MODERATE);
135                layer.replayBakedOpsImpl((void*)&renderer, unmergedReceivers, mergedReceivers);
136                GL_CHECKPOINT(MODERATE);
137                renderer.endLayer();
138            }
139        }
140
141        GL_CHECKPOINT(MODERATE);
142        if (CC_LIKELY(mDrawFbo0)) {
143            const LayerBuilder& fbo0 = *(mLayerBuilders[0]);
144            renderer.startFrame(fbo0.width, fbo0.height, fbo0.repaintRect);
145            GL_CHECKPOINT(MODERATE);
146            fbo0.replayBakedOpsImpl((void*)&renderer, unmergedReceivers, mergedReceivers);
147            GL_CHECKPOINT(MODERATE);
148            renderer.endFrame(fbo0.repaintRect);
149        }

在replayBakedOpsImpl()函数中，会根据操作的类型调用前面生成的unmergedReceivers和mergedReceivers两个函数分发表中的对应处理函数。它们实质指向BakedOpDispatcher中的静态函数。这些函数onXXXOp()和onMergedXXXOps()函数大同小异，基本都是通过GlopBuilder将BakedOpState和相关的信息封装成Glop对象，然后调用BakedOpRenderer::renderGlop()，接着通过DefaultGlopReceiver()调用BakedOpRenderer::renderGlopImpl()函数，最后在RenderState::render()中通过GL命令将Glop渲染出来。大功告成。

• 结语

总的来说，可以看到一个View上的东西要绘制出来，要经过多步的转化。

这样做有几个好处：第一、对绘制操作进行batch/merge可以减少GL的draw call，从而减少渲染状态切换，提高了性能。第二、因为将View层次结构要绘制的东西转化为DisplayList这种“中间语言”的形式，当需要绘制时才转化为GL命令。因此在View中内容没有更改或只有部分属性更改时只要修改中间表示（即RenderNode和RenderProperties）即可，从而避免很多重复劳动。第三、由于DisplayList中包含了要绘制的所有信息，一些属性动画可以由渲染线程全权处理，无需主线程介入，主线程卡住也不会让界面卡住。另一方面，也可以看到一些潜力可挖。比如当前可以合并的操作类型有限。另外主线程和渲染线程间的很多调用还是同步的，并行度或许可以进一步提高。另外Vulkan的引入也可以帮助进一步榨干GPU的能力。