深入了解Android图形管道-part2

深入了解Android Graphics Pipeline-part-2

>
* 原文链接 : Android Graphics Pipeline: From Button to Framebuffer (Part 2)
* 作者 : Mathias Garbe
* 译者 : chaossss
* 校对者: Mr.Simple
* 状态 : 完成

在上一篇博文中，我们图文结合介绍了 Android 怎么把 onDraw() 方法的 Java 代码转换为 Native 层的 C/C++ 代码。而今天，我们会承接上一篇博文讲的内容，继续探索 Android 在 Native 层是如何通过 C/C++ 代码绘制屏幕上的各种元素（控件、动画等）。在开始讲解之前，我需要提前提醒大家：要深入到 Native 层中研究 C/C++ 代码对 Java 代码的实现，意味着我们从此刻开始要忘掉 Java 安逸的垃圾回收机制，并忍受 C/C++ 代码带来的各种令人蛋疼的内存管理问题。不过大家不必惶恐，我会尽可能简单地讲解今天的内容，而且只会展示与我们今天的内容有关的有趣代码。

绘制元素

在 Android 4.3 之前，UI 的绘制流程和将 UI 元素添加到相应 View 层级的顺序相同，并将它们添加到 display list 中。但这里存在一个很严重的问题，这样的渲染流程会不断进入 GPU 最糟糕的使用场景，原因在于：这样的绘制流程会导致在绘制不同的控件时，需要不断地切换状态。举例来说吧，我们现在要绘制两个 Button，那么 GPU 就需要先绘制第一个 Button 的背景和文字，绘制完成后再对第二个 Button 做同样的操作，渲染流程结束后，至少进行了三次的状态改变。

重新设计绘制流程

所以为了最小化状态切换带来的 GPU 开销，Android 基于 UI 元素的类型和状态重新设计了相应的绘制流程。不过在接着讲解之前我们要暂时放下“界面中只有一个 Button ”的例子，并随便找一个 Activity 先进行相关知识的介绍。

示例 Activity 包含了许多重叠的元素，我们这样做的目的是：通过使用极端的例子模拟各种可能出现的情况，解释为什么绘制时会产生这些问题，以及对应的解决策略。

如你所见，简单地根据 UI 的元素类型重新设计绘制流程在大多数情况下都不能满足我们的需求，原因在于：无论是先绘制所有文字，再绘制图片；还是先绘制图片，再绘制文字，都不能获得我们我们真正想要的 UI，因为总有一些该显示的 UI 元素会因为绘制顺序被挡住，我相信任何一个有品位的 UI 设计师都不会接受这样的客户端。

为了能正确地渲染示例 Activity 的 UI，UI 中的文字元素 A 和 B 必须先被绘制，然后绘制图片元素 C，最后是文字元素 D。由于 A 和 B 是同类型的元素，所以我们可以同时进行 A 和 B的绘制，但 C 和 D 只能按照顺序绘制，不然又会产生 UI 元素的覆盖问题。

为了更好地优化 UI 每一个 View 层级的绘制流程，在重新设计了绘制顺序后，就要将类似的绘制操作合并。合并在 DeferredDisplayList 中执行，给这个函数取这个名字是因为绘制操作没有按序执行，而是在所有操作的分析，重排序，合并完成前，不断地延迟其绘制动作，直到分析，重排序，合并完成才按序绘制。

由于每一个 display list 的绘制操作只能用于绘制它自身，如果一个操作支持把相同类型的元素的多个操作合并，那这个操作必须能被用于绘制多个具有相同类型的不同页面。但你需要注意的是，这不意味每一个操作都能进行合并，在新的设计里还留有许多只能重排序的操作。

OpenGLRenderer 是 Skia 2D 图像绘制 API 的一个接口，与常见的接口不同，它不需要利用 CPU 进行硬件加速，而是用 OpenGL 完成了所有硬件加速的工作。虽然有很多办法能完成这样的工作，但是 OpenGLRenderer 是第一个用 C++ 实现的本地类。OpenGLRenderer 在 Android 3.0 中被提出，设计它主要是让它和 GLES20Canvas 协作，绘制我们想要的界面元素。有趣的是，在界面绘制的操作中，只有它们是以协作的形式进行的。

为了把多个操作合并到一个绘制操作中，每一个操作都通过调用 addDrawOp() 方法被添加到 deferred display list 中。同时，绘制操作还需要提供 batchId，因为绘制操作必须知道这个类型的操作能否被合并，此外，绘制操作还需要通过调用 DrawOp.onDefer(…) 方法提供 mergeId,以指明哪些操作已经被合并.

一般 batchId 包含了一个简单的枚举，主要是为 9-Patch 图片元素提供 OpBatch_Patch，并为普通的文字元素提供 OpBatch_Text。mergeId 的值由 DrawOpitself 决定，用于判断两个具有相同的 DrawOp 类型的操作能否被合并。对 9-Patch 图片元素来说，mergeId 用于指向图片资源文件，对文字元素来说，则是对应的文字颜色。来自同一个资源文件夹的资源文件可能会被合并到同一个 batch 中，帮助我们大量地节约绘制流程带来时间开销。

有关一个操作的所有信息都被归并到一个简单的结构中，代码如下：

    struct DeferInfo {
        // Type of operation (TextView, Button, etc.)
        // batchId 注明被操作的 UI 元素的类型（如 TextView，Button等……）
        int batchId;

        // State of operation (Text size, font, color, etc.)
        // mergeId 注明被操作的 UI 元素的状态（如 文字大小，字体，文字颜色等……）
        mergeid_t mergeId;

        // Indicates if operation is mergable
        // 标记操作是否可被合并
        bool mergeable;
    };

当一个绘制操作的 batchId 和 mergeId 被确定，如果它还没有被合并，就会被添加到 batch 队列的尾部。如果没有可用的 batch，我们就会创建一个新的 batch。不过一般情况下，这些绘制操作都是可以合并的。为了知道每一个最近合并的 batch 的去向，我们会通过一个简化的算法调用 MergeBatches 的实例 hashmap，用 batchId 构建键值对保存相应的 batch。对每一个 batch 使用 hashmap 能避免使用 mergeId 导致的冲突。

    vector<DrawBatch> batches;
    Hashmap<MergeId, DrawBatch*> mergingBatches[BatchTypeCount];

    void DeferredDisplayList::addDrawOp(DrawOp op):
        DeferInfo info;
        /* DrawOp fills DeferInfo with its mergeId and batchId */
        /* DrawOp 方法用 mergeId 和 batchId 填充 DeferInfo */
        op.onDefer(info);

        if(/* op is not mergeable */):
            /* Add Op to last added Batch with same batchId, if first
               op then create a new Batch */
            /* 将 Op 添加到最后被添加入元素的 Batch 中，但这个 Batch 必须与 Op 具有相同 batchId，此外，如果 op 是 Batch 中的第一个元素，那么需要新建一个 Batch */

            return; 

        DrawBatch batch = NULL;
        if(batches.isEmpty() == false):
            batch = mergingBatches[info.batchId].get(info.mergeId);
            if(batch != NULL && /* Op can merge with batch */):
                batch.add(op);
                mergingBatches[info.batchId].put(info.mergeId, batch);
                return;

            /* Op can not merge with batch due to different states,
               flags or bounds */
            /* 如果 Op 与 Batch 具有不同的状态，标记，和边界，那么 Op 将无法被合并到 Batch 中 */

            int newBatchIndex = batches.size();
            for(overBatch in batches.reverse()):
                if (overBatch == batch):
                    /* No intersection as we found our own batch */
                    /* Batch 之间应该没有交集 */

                    break;

                if(overBatch.batchId  == info.batchId):
                    /* Save position of similar batches to insert 
                       after (reordering) */
                    /* 在重排序后保存 batchId 相同的 batch 中对应的位置，便于后面插入元素 */

                    newBatchIndex == iterationIndex;

                if(overBatch.intersects(localBounds)):
                    /* We can not merge due to intersection */
                    /* 如果 Batch 间产生了交集，我们不能进行合并 */

                    batch = NULL
                    break;

        if(batch == NULL):
            /* Create new Batch and add to mergingBatches */
            /* 如果 batch 为空，则创建一个新的 batch，并将它添加到 mergingBatches 中 */

            batch = new DrawBatch(...);
            mergingBatches[deferInfo.batchId].put(info.mergeId, batch);
            batches.insertAt(newBatchIndex, batch);
        batch.add(op);

如果当前操作能够与其他具有相同 mergeId 和 batchId 的操作合并，那么这个操作和下一个可以合并的操作都会被添加到现有的 batch 中。但如果它因为状态不一致、绘制标记或边界限制无法被合并，算法就需要将它插入到一个新的 batch 中。为了实现这样的需求，我们则需要获得 batch 队列中所有 batch 对应的 postion。理想情况下，它能在当前绘制操作中找到一个和它状态相同的 batch。不过需要注意的是，在这个绘制操作中为它找到合适的位置的过程中，也必须保证它和其他 batch 没有交集。因此，batch 列表都以逆序寻找一个合适的位置，并确认对应的位置与其他元素没有交集。如果出现了交集，那么对应操作则不能被合并，并需要在这个位置创建一个新的 DrawBatch，并将其插入 Mergebatchedhaspmap。新的 batch 会被添加到 batch 队列的相应位置中。无论发生什么，改操作都会被加入到当前的 batch 中，区别在于：是在新的 batch 还是已存在的 batch 中。

具体的实现会比我们的简化讲解更复杂（虽然我们这里讲的也很难懂……）。但其中优化的方法值得我们学习：算法通过移除堵塞的绘制操作尽可能地避免重绘，同时通过对为合并的操作进行重排序，从而避免 GPU 状态改变带来的开销。

绘制界面

在重排序和合并后，新的 deferred display list 终于可以被绘制到屏幕上了。

在 OpenGLRenderers::drawDisplayList(…) 方法里，deferred display list 其实就是一个填满了操作的新建普通显示列表，填充完成后延迟显示页面将绘制它自身。

OpenGLRenderer: drawDisplayList(…)

    status_t OpenGLRenderer::drawDisplayList(
                   DisplayList* displayList, Rect& dirty,
                   int32_t replayFlags) {
        // All the usual checks and setup operations 
        // (quickReject, setupDraw, etc.)
        // will be performed by the display list itself
        // 所有的常规检查与创建操作（例如 quickReject, setupDraw 等等）都会由 display list 完成

        if (displayList && displayList->isRenderable()) {
            DeferredDisplayList deferredList(*(mSnapshot->clipRect));
            DeferStateStruct deferStruct(
                deferredList, *this, replayFlags);
            displayList->defer(deferStruct, 0);
            return deferredList.flush(*this, dirty);
        }
        return DrawGlInfo::kStatusDone;
    }

multiDraw(…) 方法会在列表中的第一个操作中被调用，而其他的操作都被视作参数。被调用的操作负责立刻绘制所有被提供的操作，并调用 OpenGLRenderer 执行绘制其自身的操作。

显示列表中的操作

每一个绘制操作都会在拥有对应显示操作列表的 Canvas 里被执行，所有显示操作列表必须实现重载了绘制操作的 replay() 方法。这些绘制操作调用 OpenGLRenderer 去绘制他们，当我们创建一个操作时需要提供一个 renderer 的引用。除此以外，我们还需要实现 onDefer() 方法，并返回操作的 drawId 和 mergeId。为合并的 batch 会设置相应的绘制 id 为 kOpBatch_None。可合并的操作必须实现用于立刻绘制所有已合并的操作的 multiDraw() 方法。

例如，绘制 9-Patch 的操作包含了下列 multiDraw(…) 实现：

DrawPatchOp::multiDraw(…)

    virtual status_t multiDraw(OpenGLRenderer& renderer, Rect& dirty,
            const Vector<OpStatePair>& ops, const Rect& bounds) {

        // Merge all 9-Patche vertices and texture coordinates 
        // into one big vector
        // 将所有 9-Patche 图片的顶点坐标和纹理坐标合并到一个矢量中

        Vector<TextureVertex> vertices;
        for (unsigned int i = 0; i < ops.size(); i++) {
            DrawPatchOp* patchOp = (DrawPatchOp*) ops[i].op;
            const Patch* opMesh = patchOp->getMesh(renderer);
            TextureVertex* opVertices = opMesh->vertices;
            for (uint32_t j = 0; j < opMesh->verticesCount; 
                 j++, opVertices++) {
                vertices.add(TextureVertex(opVertices->position[0], 
                                           opVertices->position[1],
                                           opVertices->texture[