前言

 

迷雾散尽，露出了古朴庄严的森林。古老的铁杉，在头顶编成绿色穹顶。 阳光在树叶间破碎成金色顶棚。从树干间远眺，远处的森林渐渐隐去。
用几句话就能描述一片巨大的森林，但是在实时游戏中做这件事就完全是另外一件事了。 当屏幕上需要显示一整个森林时，图形程序员看到的是每秒需要送到GPU六十次的百万多边形。
我们讨论的是成千上万的树，每棵都由上千的多边形组成。 就算有足够的内存描述森林，渲染的过程中，CPU到GPU的部分也太过繁忙了。
–Bob Nystrom《游戏设计模式》

以上是《游戏设计模式》这本书中“享元模式”章节提到的内容。文中还提到，当我们需要渲染一整片使用给相同纹理的树木时，可以只进行一次树木模型的数据传输，随后发送每棵树不同的位置、大小等数据，来实现森林的效果。

初次读到这个章节的时候，我觉得这真是一个了不起的优化，去除所有重复的工作，用最少的渲染数据，实现大量复用元素的渲染。
当时的我一想，这不就是渲染合批在做的事情吗？提交一次纹理数据，再多次提交顶点数据，就可以实现渲染大量相同的元素。
年轻的我以为故事到这里就结束了… 但是！前段时间看了上海站Cocos Star Meeting，乐府互娱大佬夏凯强分享的“共享节点”，发现这个故事其实还有得聊！

引擎已经帮我们实现了渲染合批的功能，当我们需要渲染大量元素（比如同一张图集下的图片）时，即使不做任何优化，性能效果也是非常优秀的。

能不能更进一步呢？如果我们需要的是一样的结果（比如渲染100个草丛），必须要这么多节点、这么多计算吗？
胆子大一点，把这些节点、组件全部省掉！相同元素只创建一份，杜绝重复劳动——这就是共享节点。

1. 开发环境

浏览器：Chrome
开发语言：JavaScript
引擎版本：CocosCreator 2.4.3

 注意：
乐府互娱基于原生环境实现了共享节点，但本文是基于H5的实现。

2. 研究过程

贴一下大佬的PPT（可在Cocos公众号后台发送“上海”获得，其他内容也很棒）：

在他们的项目中，共享节点技术主要用来解决动效复用的问题。
在我看来，动效渲染时，会伴随大量的计算，如果有多个相同动效，会产生大量没必要的CPU消耗。虽然引擎提供了SHARED_CACHE等优化方式，但是似乎和我们的期望还是有一点点差距。

image750×422 57.8 KB

从这张PPT中，可以看出共享节点的主要实现逻辑：

1. 相同的对象只创建1个
2. 将该对象的渲染数据进行多次提交

image750×422 72.4 KB

最后的PPT涉及的是渲染流程的修改，在渲染子节点之后，对节点下的共享节点（特殊的子节点）进行渲染。

由于我是在线上观看的分享，加上运气不好，进去的时候这一段刚好完美错过了

。
看完PPT之后，也只是模糊地有了一个思路，本着不要脸的精神，我联系上了大佬（#狗头）！

得知他们的方案大概是：修改了节点的相关逻辑，使得共享节点可以有多个父节点，这样就实现了共享节点可以在多个位置进行渲染。感谢大佬！

3. 实现思路

3.1 思路梳理

综上，可以大概得出共享节点实现的逻辑（以多次渲染同一图片为例）：

1. 创建一个实际的节点，带有Sprite组件（称为共享节点）。
2. 不再创建节点，而是将共享节点多次添加到父节点中。
3. 修改渲染流程，在渲染完子节点后，渲染共享节点（可能有多个）。
4. 将共享节点自己的渲染数据再次进行提交。

3.2 思路简化

虽然大致的实现思路已经清晰了，但是为了方便实现… 我换了个方案（…

1. 创建一个实际的节点，带有Sprite组件（称为共享节点）。
2. 不再创建节点，而是创建一个复制节点(js对象），其中保存了位置、共享节点等信息。
3. 将复制节点记录到父节点的_copyChidrens中。
4. 修改渲染流程，在渲染完子节点后，渲染_copyChidrens（可能有多个）。
5. 复制节点在渲染时，拷贝共享节点的渲染数据。
6. 对渲染数据进行一点小加工，比如修改位置。
7. 提交渲染数据！

注意，这里引入了“复制节点”这个概念。意义为：复制节点是共享节点的一个复制品~

4. 代码实现

为了实现共享节点，我们需要修改引擎相关代码。
本文是基于H5的实现，如果你需要像乐府一样支持原生端，则需要修改对应的C++代码。

4.1 拓展cc.Node

我们需要拓展内置节点功能，支持添加复制节点，并修改渲染流程，支持复制节点的渲染。

4.1.1 增加共享节点标记

// CCNode.js(cocos2d\core\CCNode.js)
properties: {
    _isShareNode: false,
    isShareNode: {
        get () {
            return this._isShareNode;
        },
        set (value) {
            this._isShareNode = value;
        }
    },
}

4.1.2 支持记录复制节点

// CCNode.js(cocos2d\core\CCNode.js)
let NodeDefines = {
    /**
     * 添加一个复制节点作为子节点
     * @param {CopyNode} node 复制节点
     */
    addCopyChildren (node) {
        let nodes = (this._copyChidrens || (this._copyChidrens = []));
        nodes.push(node);
        node.setParent(this);
    }
}

4.1.3 渲染复制节点

// render-flow.js(cocos2d\core\renderer\render-flow.js)
_proto._children = function (node) {
    let children = node._children;
    for (let i = 0, l = children.length; i < l; i++) {
      // ... 渲染子节点
    }
  
    // 修改开始-共享节点-渲染复制子节点
    if (node._copyChidrens) {
        for (let children of node._copyChidrens) {
            children.fillBuffers(batcher);
        }
    }
    // 修改结束-共享节点-渲染复制子节点
  
    this._next._func(node);
};

我们在子节点渲染的逻辑之后，渲染复制节点。
我们遍历节点的所有复制子节点（_copyChidrens），并调用fillBuffers函数进行渲染数据的填充。

 注意：
在cocos渲染相关的流程中，若节点没有子节点，则不会进入_children渲染流，因此，作为复制节点的父节点，至少要有一个节点，即使是空节点也可以**。**

节点的修改比较简单，接着我们实现复制节点的逻辑。

4.2 实现复制节点（CopyNode）

不同渲染组件的实现逻辑会有不同，因此我们实现一个父类CopyNode，来负责通用的逻辑。

// CopyNode.js
const _nodeWorldPos = new cc.Vec2();
const _targetWorldPos = new cc.Vec2();

module.exports = class CopyNode {
    constructor(shareNode, x, y) {
        this.shareNode = shareNode;

        this._disX = 0;
        this._disY = 0;

        this.position = new cc.Vec2();
    }

    get x() { return this.position._x }
    get y() { return this.position._y }

    setParent(parent) {
        this._parent = parent;
    }

    setPosition(x, y) {
        if (!this._parent) {
            CC_DEBUG && cc.warn("复制节点：请在设置父节点后，再修改位置");
            return;
        }

        x === undefined && (x = this.position.x);
        y === undefined && (y = this.position.y);

        this.position.x = x;
        this.position.y = y;

        this._parent.convertToWorldSpaceAR(this.position, _nodeWorldPos);
        this.shareNode.parent.convertToWorldSpaceAR(this.shareNode.position, _targetWorldPos);

        let disX = _nodeWorldPos.x - _targetWorldPos.x;
        let disY = _nodeWorldPos.y - _targetWorldPos.y;
        this.calDis(disX, disY);
    }

    /**
     * 计算和共享节点的距离
     * 有特殊需求可重写本函数
     * @param {number} x x距离
     * @param {number} y y距离
     */
    calDis(x, y) {
        this._disX = x;
        this._disY = y;
    }
}

目前的需求只涉及修改位置，因此这里只实现了位置相关的设置和读取功能。
特殊的是，这里还额外计算了_disX和_disY。这是由于，复制节点的渲染数据来源于共享节点，修改位置时，如果知道复制节点和共享节点之间的距离，就可以直接进行相加得出结果，无需重新计算。

4.3 支持复制Sprite

乐府没有提到复用Sprite相关的内容，但是我有一些其他的想法，因此顺便研究了一下

。
Sprite实现起来比Spine简单，我们先从Sprite开始~

// CopySprite.js
module.exports = class CopySprite extends CopyNode {
    fillBuffers(renderer) {
        let renderComp = this.shareNode._renderComponent;
        renderComp._checkBacth(renderer, this.shareNode._cullingMask);

        // 获得共享节点的渲染数据
        let assembler = renderComp._assembler;
        let renderData = assembler._renderData;
        let vData = renderData.vDatas[0];
        let iData = renderData.iDatas[0];

        // 申请渲染数据空间、计算数据位移
        let buffer = assembler.getBuffer(renderer);
        let { verticesCount, floatsPerVert, indicesCount } = assembler;
        let positionOffset = assembler.getVfmt().element("a_position").offset;
        let offsetInfo = buffer.request(verticesCount, indicesCount);
        let vertexOffset = offsetInfo.byteOffset >> 2, vbuf = buffer._vData;

        // 复制vertices
        let vbufLen = vbuf.length;
        if (vData.length + vertexOffset > vbufLen) {
            vbuf.set(vData.subarray(0, vbufLen - vertexOffset), vertexOffset);
        } else {
            vbuf.set(vData, vertexOffset);
        }
      	// 修改位置
        for (let i = 0; i < verticesCount; i++) {
            let positionIndex = vertexOffset + i * floatsPerVert + positionOffset;

            if (positionIndex > vbufLen) {
                break;
            }

            vbuf[positionIndex] += this._disX;
            vbuf[positionIndex + 1] += this._disY;
        }

        // 填充indices
        let ibuf = buffer._iData, indiceOffset = offsetInfo.indiceOffset, vertexId = offsetInfo.vertexOffset;
        for (let i = 0, l = iData.length; i < l; i++) {
            ibuf[indiceOffset++] = vertexId + iData[i];
        }
    }
}

对于Sprite，我们可以仿照Assembler中的fillBuffers函数进行修改。
由于渲染数据都会存储在Assembler中，我们这里取出对应的数据，再重新填充一遍就好了。

复制完渲染数据后，我们可以对顶点数据进行修改，这里只修改了位置。如果你需要修改其他属性（比如颜色），也可以在这里进行处理。

从看到共享节点的第一眼，我就想把它用到TiledMap中！这满屏幕的物件，要是能少创建几个，肯定也有不错的提升！
最后我也确实把它塞到TiledMap中了，优化效果大概是25%（地图不同会导致数据不同）。实现起来不难，大家感兴趣可以试试。

在大部分的应用场景中，很少出现同一张图片渲染多次的情况，复制节点的优势很难凸显，加上复制节点的功能完全打不过真实的节点。估计很难用到其他地方。

4.4 支持复制Spine

与Sprite不同，Spine的渲染数据并不会被缓存，这不就不能CV了吗？这可不行！
根据渲染流程，所有最终的渲染数据都会被填充到buffer中，那我们胆子大一点，直接从buffer中取！

我们在共享节点渲染时，记录Spine渲染数据在buffer中的起始和结束位置，这样就可以在复制节点中通过buffer获得共享节点的渲染数据了！

4.4.1 记录渲染数据位置

// spine-assembler.js(extensions\spine\spine-assembler.js)
fillBuffers (comp, renderer) {
    // ...省略部分代码

    // 修改开始-共享节点-记录渲染数据开始位置
    if (node.isShareNode) {
      this._bufferOffsetInfo = {
        startVertexOffset: _buffer.vertexOffset,
        startIndiceOffset: _buffer.indiceOffset,
      }
    }
    // 修改结束-共享节点-记录渲染数据开始位置
  
    if (comp.isAnimationCached()) {
        // Traverse input assembler.
        this.cacheTraverse(worldMat);
    } else {
        if (_vertexEffect) _vertexEffect.begin(comp._skeleton);
        this.realTimeTraverse(worldMat);
        if (_vertexEffect) _vertexEffect.end();
    }

    // 修改开始-共享节点-记录渲染数据结束位置
    if (node.isShareNode) {
      this._bufferOffsetInfo.endVertexOffset = _buffer.vertexOffset;
      this._bufferOffsetInfo.endIndiceOffset = _buffer.indiceOffset;
    }
    // 修改结束-共享节点-记录渲染数据结束位置
  
    // ...省略部分代码
}

4.4.2 实现复制逻辑

// CopySpine.js
const VFOneColor = cc.gfx.VertexFormat.XY_UV_Color;
const VFTwoColor = cc.gfx.VertexFormat.XY_UV_Two_Color;
const _mt4 = new cc.Mat4();

module.exports = class CopySpine extends CopyNode{
    fillBuffers(renderer) {
        let renderComp = this.shareNode._renderComponent;
        renderComp._checkBacth(renderer, this.shareNode._cullingMask);

        // 计算渲染数据数量
        let assembler = renderComp._assembler;
        let { startVertexOffset, startIndiceOffset, endVertexOffset, endIndiceOffset } = assembler._bufferOffsetInfo;
        let vertexCount = endVertexOffset - startVertexOffset;
        let indiceCount = endIndiceOffset - startIndiceOffset;

        // 准备填充复制节点的渲染数据
        let _useTint = renderComp.useTint || renderComp.isAnimationCached();
        let _vertexFormat = _useTint ? VFTwoColor : VFOneColor;
        let floatsPerVert = _vertexFormat._bytes >> 2;
        // 相关变量计算结束

        // 申请渲染数据空间、计算数据位移
        let _buffer = renderer.getBuffer('spine', _vertexFormat);
        let offsetInfo = _buffer.request(vertexCount, indiceCount);
        let { indiceOffset, vertexOffset } = offsetInfo;
        let vertexFloatOffset = offsetInfo.byteOffset >> 2;

        // 复制vertices
        let vbuf = _buffer._vData;
        let startVbufIndex = startVertexOffset * floatsPerVert;
        for (let i = 0, len = vertexCount * floatsPerVert; i < len; i++) {
            vbuf[vertexFloatOffset + i] = vbuf[startVbufIndex + i];
        }

        // 修改位置
        let positionOffset = _vertexFormat.element("a_position").offset;
        let positionIndex = vertexFloatOffset + positionOffset;
        while (positionIndex < vertexFloatOffset + vertexCount * floatsPerVert) {
            vbuf[positionIndex] += this._disX;
            vbuf[positionIndex + 1] += this._disY;

            positionIndex += floatsPerVert;
        }

        // 填充indices
        let ibuf = _buffer._iData;
        for (let i = 0; i < indiceCount; i++) {
            ibuf[indiceOffset + i] = ibuf[startIndiceOffset + i] - startVertexOffset + vertexOffset;
        }

        _buffer.adjust(vertexCount, indiceCount);
    }
  
    /**
     * 计算和共享节点的距离
     * 未开启合批时，会计算矩阵变换，需要将距离根据缩放进行逆换算。否则坐标错误。
     * @param {number} x x距离
     * @param {number} y y距离
     */
    calDis(x, y) {
        let shareNode = this.shareNode;

        if (!shareNode._renderComponent.enableBatch) {
            shareNode.getWorldMatrix(_mt4);

            x /= _mt4.m[0];
            y /= _mt4.m[5];
        }

        this._disX = x;
        this._disY = y;
    }
}

整体逻辑和Sprite类似，但我们从_buffer中复制渲染数据~

4.5 效果展示

到这里就实现了基本的复制节点效果了，我们已经可以用一个渲染节点来复制出无数个拷贝。是不是很简单！甚至有一点小激动。
你可以像这样使用复制节点：

this.nodeSprite.isShareNode = true;
let copyNode = new CopySprite(this.nodeSprite);
this.nodeContainer.addCopyChildren(copyNode);
copyNode.setPosition(-200, 0);

image960×641 27.3 KB

也可以多复制几个，做个基本的for循环就行（中间那个不合群的是共享节点）：

但是！事情往往没有这么简单！

4.6 测试

4.6.1 翻车

当我把哥布林放到测试用例中…
这个框起来的小人本来应该出现在最右侧，突然… 变成了左侧…

对应的节点树：

当哥布林位于两个小人中间时，复制节点的位置错误。
当哥布林位于两个小人后面时，复制节点的位置正确。

4.6.2 翻车原因

乍一看以为是哥布林的原因，直接方向错误…
根本原因是：合批判定逻辑有缺陷，导致复制节点可以和最后一个渲染节点合批，但该节点又不是共享节点。
当哥布林位于小人后面时，显然无法进行合批，因此位置正确。

为什么合批判定出错，会导致位置错误呢？

渲染数据提交时，每个渲染批次会对应一个渲染模型（model），每个渲染模型会绑定一个节点。
节点的位置会变换为cc_matWorld属性（模型空间转世界空间矩阵），传递给effect的顶点处理器。

// base-renderer.js(cocos2d\renderer\core\base-renderer.js)
_draw (item) {
  // 省略了部分代码
	node.getWorldMatrix(_m4_tmp);
	device.setUniform('cc_matWorld', Mat4.toArray(_float16_pool.add(), _m4_tmp));
}

在effect中，cc_matWorld会和cc_matViewProj进行计算，得出顶点位置的换算矩阵。

// builtin-2d-spine.effect(resources\static\default-assets\resources\effects\builtin-2d-spine.effect)
// 省略了部分代码
CCProgram vs %{
  void main () {
    #if CC_USE_MODEL
      mvp = cc_matViewProj * cc_matWorld;
    #else
      mvp = cc_matViewProj;
    #endif
      
    gl_Position = mvp * vec4(a_position, 1);
  }
}%

因此，当我们判定复制节点可以和最后的小人合批时，我们将渲染数据附在了最后的小人上，一起提交给了渲染引擎。
基于错误的换算矩阵计算出来的位置自然也是错误的。

这里有个新的疑问，为什么Sprite中没有出现类似的问题？
答案就在effect的代码中：CC_USE_MODEL的值。
Sprite的CC_USE_MODEL值为false，而Spine的CC_USE_MODEL值为true！
也就是说，Sprite渲染时，并不会进行转换。自然也不会因为节点的位置导致错误~

CC_USE_MODEL值取决于是否启用合批（enableBatch属性），在复用Spine的情况下，不一定能够合批，因此不进一步讨论。

5. 修正合批检测

5.1 实现合批检测

在原本的方案中，我们调用共享节点的renderComponent来实现合批检测，现在我们需要拓展合批检测逻辑，来实现一个类似的~

// CopyNode.js
class CopyNode {
    /**
     * 检测是否可以合批
     */
    checkBacth(renderer) {
        if (!this.checkCanBacth(renderer)) {
            this.flush(renderer);
            return;
        }

        // cocos内置检测逻辑
        let node = this.shareNode;
        let cullingMask = node._cullingMask;
        let material = node._renderComponent._materials[0];
        if (renderer.cullingMask !== cullingMask ||
            (material && material.getHash() !== renderer.material.getHash())
        ) {
            this.flush(renderer);
        }
    }

    /**
     * 检测是否可以合批(子类可以继承拓展)
     */
    checkCanBacth(renderer) {
        return true;
    }

    /**
     * 刷写渲染数据
     */
    flush(renderer) {
        renderer._flush();

        let node = this.shareNode;
        let material = node._renderComponent._materials[0];
        renderer.node = material.getDefine('CC_USE_MODEL') ? node : renderer._dummyNode;
        renderer.material = material;
        renderer.cullingMask = node._cullingMask;
    }
}

与内置的合批检测相比，我们在检测之前增加了一个可拓展的函数checkCanBatch，来针对某些特殊子类。

修改原有的checkBatch函数调用（CopySpine和CopySprite都需要修改）

fillBuffers(renderer) {
    this.checkBacth(renderer);
    let renderComp = this.shareNode._renderComponent;
    // 省略后续代码
}

5.2 实现Spine合批检测

// CopySpine.js
class CopySpine extends CopyNode {
    checkCanBacth(renderer) {
        return this.shareNode === renderer.node;
    }
}

就这么简单，当节点不一样的时候，我们就认定为无法合批。

很好，位置正确了！哥布林和小人们快乐地… （不是

6. 性能对比

测试数据由于环境的影响，常常波动不定，因此我们将小人复制五百份，来增大对比性。
两组对照为：
优化前：使用cc.instantiate
优化后：使用复制节点

image1405×775 59.3 KB

emmm… 可以明显地看出它们的差距… 大到甚至不想多次实验取平均值…
使用复制节点对比优化前（ShareCache），大约只消耗了32%的性能。

7. 总结

共享节点可以减少节点、组件的创建，避免了大量组件的各类刷新函数调用，同时还可以减少对于渲染数据的计算。
对于复用Spine有奇效，Spine往往需要使用CPU进行位移、变换等运算，使用共享节点后，可以省掉这些计算量，当然SharedCache也可以，但需要额外的内存空间。

本文的方案在某些场景下，已经实现了最初目的——复用Spine，但还是存在一些限制。比如对节点移动、变换等效果的支持不足。也有一些地方还可以优化，比如必须先设置父节点才能修改位置。
受限于本人的技术（以及懒），若干问题不赘述，但技术是个好技术，希望给大家一点启发~
乐府的方案是对原生平台的优化，本人学艺不精，只能做个H5版本玩玩。