动态合图你真的用好了吗？| Cocos Creator

1. 动态合图的默认规则

Cocos 引擎中对动态合图的描述如下：它能在项目运行时动态地将贴图合并到一张大贴图中。

当渲染一张贴图的时候，动态合图系统会自动检测这张贴图是否已经被合并到了图集（图片集合）中，如果没有，并且此贴图又符合动态合图的条件，就会将此贴图合并到图集中。

动态合图是按照渲染顺序来选取要将哪些贴图合并到一张大图中的，这样就能确保相邻的 DrawCall 能合并为一个 DrawCall（又称“合批”）。

若希望强制打开动态合图，只需要增加以下代码：

cc.macro.CLEANUP_IMAGE_CACHE = false;
cc.dynamicAtlasManager.enabled = true;

限制条件：

默认只有贴图宽高都小于 512 的贴图才可以进入到动态合图系统。用户可以根据需求修改这个限制：

cc.dynamicAtlasManager.maxFrameSize = 512;

支持动态合图的渲染组件：Sprite、Label ( BITMAP 模式)。

注意事项：

在场景加载前，动态合图系统会进行重置，SpriteFrame 贴图的引用和 uv 都会恢复到初始值。

查看方法：

通过以下代码可以在游戏中看到所有动态合图会被加到一个 scrollview 上，便于实时查看合图效果。

cc.dynamicAtlasManager.showDebug(true);

其它规则（文档里未直接说明的）：

• 动态合图最大张数为5张，使用完后会强制重建。

• 单张合图的大小为 2048*2048。

• 贴图的多个属性设置为非默认值会影响合批 (FilterMode,genMipmaps,premultiplyAlpha,flipY,wrapS,wrapT,pixelFormat等)

• 如果参与合图的两个渲染组件 A 和 B  被另一个未合图的渲染组件 C 隔开，那么这两个 A 和 B 并不会在一个 DrawCall里渲染。

• 如果一直不切换场景，那么随着动态合图的数量增长，渲染效率可能会降低，适得其反。

2. 通过实例来理解动态合图的使用

这里使用官方文档中给到一个实例 暗黑斩 来测试动态合图的效果。

暗黑斩: https://github.com/cocos-creator/tutorial-dark-slash

注意事项：

由于该项目中把所有贴图的 FilterMode 设置为 Point 模式了，因此首先我们把这个全部改为 Bilinear。

首先关闭动态合图，查看运行两个场景时的 Drawcall 数量分别是：

StartGame:37

PlayGame:38

然后打开动态合图，我们在两个场景下分别查看合图效果如下：

(StartGame)

(PlayGame)

 DrawCall 数量分别如下：

StartGame:9

PlayGame:25

可以看到在不同的场景下，参与合图的纹理都被合到一张大图上了， DrawCall 确实提高了很多。

3. 增加需求

上面这个示例只是一个非常简单的 DEMO，实际游戏中的使用需求远比上面这个复杂，主要有以下几个实际问题是我们要去考虑的：

• 游戏中只有一个场景，也就是说动态合图不会被重建。

• 已经合图的资源被释放后，下次图集上的纹理还能否使用？

• 如果在重建前出现多图集的情况下会有哪些影响？

那么我们分别来尝试满足以上条件时，动态合图还能否保持高效率。

3.1 保持动态合图不被重建

由于 DEMO 中有两个场景，为了不改动游戏逻辑，我们直接改引擎，在切换场景时直接不要重建动态合图。代码如下：

// manager.js
function beforeSceneLoad () {
    //dynamicAtlasManager.reset();
}

然后测试此时的动态合图效果：

如上图所示：

所有符合合图条件的纹理都合并到一张图集上， DrawCall 依次为 9 和 25 。

3.2 增加资源释放

在 DEMO 中切换场景时，增加资源释放代码：

// HomeUI.js
playGame: function () {
        cc.eventManager.pauseTarget(this.btnGroup, true);
        let self = this
        cc.director.preloadScene('PlayGame', null, function(error, newScene){
            res.cleanRes(self.node, newScene)
            cc.director.loadScene('PlayGame')
        })
        // cc.director.loadScene('PlayGame', function(error, newScene){
        //     res.cleanRes(self.node, newScene)
        // });
    }


// Game.js: 战斗结束时，点取消按钮回到HomeUI场景
gameOver: function () {
        this.deathUI.hide();
        this.gameOverUI.show();


        let self = this
        // cc.director.loadScene('StartGame', function(error, sceneAsset){
        //     res.cleanRes(self.node, sceneAsset)
        // });
        cc.director.preloadScene('StartGame', null, function(error, newScene){
            res.cleanRes(self.node, newScene)
            cc.director.loadScene('StartGame')
        })
    },


// 新增加文件res.js
let res = {
    cleanRes:function( oldScene, newScene ) {
        let scene = cc.director.getRunningScene()
        let oldDeps = scene.dependAssets
        let newDeps = cc.loader.getDependsRecursively(newScene)
        let length = oldDeps.length
        for (let index = length - 1; index >= 0; --index) {
            let dep = oldDeps[index]
            if (newDeps.indexOf(dep) >= 0) {
                oldDeps.splice(index, 1)
            }
        }


        cc.loader.release(oldDeps)
    },
}

module.exports = res;

运行游戏，执行 StartGame->PlayGame->StartGame->PlayGame->StartGame的这个流程后，再看动态合图的效果如下：

注意：这时候，动态合图里面出现了两张动态图集：

第一张被使用完全，第二张使用到了一部分。

此时的 Drawcall 相比没有释放资源时，有时会增加了1。分别是10和26。

很明显，此时 Drawcall 增加的原因是：部分资源在第一个图集上，部分资源在第二个图集上，相比只有一张图集时， DrawCall 就增加了1个。

3.3 出现多张图集时的影响

正如 3.2 所示，出现多张图集时，主要有以下影响：

• 图集数量的增加消耗了内存。

• 图集数量的增加导致 DrawCall 可能会升高，图集数量越多，影响越大。

4. 如何优化

综合以上 DEMO 中的尝试，我们可以得出结论：

如果要在实际项目中从效率和性能兼顾的方向来使用动态合图，显然当前的这个机制是不符合要求的，那么主要解决哪些问题？我认为有以下两个：

• 只要原始贴图参与过合图，不论后来是否被释放，下次能直接使用合图中已经有的纹理来渲染，而不必再占用新的图集空间。

• 控制总的动态图集数量，最好不能超过3张，最好在2张(含)以内。

4.1 重复利用合图空间

为了能够重复利用合图的空间，我们需要明白为什么同一个资源被释放后，它在合图空间中的纹理不能再次被使用了。我们通过阅读源码可以找到答案:

// atlas.js
insertSpriteFrame (spriteFrame) {
    let rect = spriteFrame._rect,
    texture = spriteFrame._texture,
    // 合图记录是通过纹理的_id值来查找的。
    info = this._innerTextureInfos[texture._id];


    ......
}


// CCTexture2D.js
ctor () {
    // 生成id的方法
    this._id = idGenerater.getNewId();


    ......
}


// id-generate.js
function IdGenerater (category) {
    // init with a random id to emphasize that the returns id should not be stored in persistence data
    this.id = 0 | (Math.random() * 998);
    
    this.prefix = category ? (category + NonUuidMark) : '';
}

IdGenerater.prototype.getNewId = function () {
    return this.prefix + (++this.id);
};

通过以上代码，我们可以知晓，所有的纹理加载时生成的 _id 都是唯一的且其中的数字部分是自增的。因此即使是同一个资源，释放之后再加载到内存时，它的_id 与之前不一样。因此参与合图时即使已经合过，也找不到记录了。

既然找到了症结所在，那么解决办法也很简单，把 _id 改成一个能与当前贴图唯一对应的标识即可，显然，这个标识就是 texture._uuid (这里不做解释，阅读引擎源码能找到答案)。

把 insertSpriteFrame 方法中 texture._id 改为 texture._uuid 后，测试执行 StartGame->PlayGame->StartGame->PlayGame->StartGame 的这个流程后，动态合图效果如下：

drawcall 依然保持是9和25。

4.2 提高图集利用率

从图5可以看到，虽然所有纹理都集中合到一张图集上，但是这个图集里面有太多的空白区域，不会被利用到。如果能利用到一整张图集的所有空间，那么可以提高单张图集上同时合并的纹理数量，间接也降低了 DrawCall 。

我们可以想到，如果能按照 TexturePacker 的合图方式来做动态图集的合图，那么无疑是比较理想的。当然这是可以的，我们可以自己写一个算法来计算合图时的位置和空间。也可以找第三方的算法。这里我推荐网上一个 MaxRect 的开源代码(c++版本，直接翻译成js版本即可)。代码我就不贴了，直接看使用这个算法的结果：

4.3 控制图集数量

客观来说，一个游戏用几张动态图集是不确定的。但是可以确定的是，我们需要哪些贴图被合并进动态图集。这要从我们的目的来着手。动态图集解决的是降低 DrawCall 的目的。

因此以下情况是考虑是否要让贴图参与动态合图的重要因素：

• 贴图 size 较大，接近 512*512 或者你设置的最大 size。

• 贴图符合合图要求，但使用频次较低。

• 贴图是否会打断需要批量渲染的组件。

• 贴图参与合图后能否显著提高当前界面 DrawCall 。

相反，我们真正需要动态合图的需求是：

• 复用结构中的小尺寸贴图。

• 高频次使用的小尺寸贴图。

• 常用列表上的公共背景贴图。

• 高频次使用的 TTF 的小图集。

最后，一定不要参与合图的是：

• BITMAP 模式的低频次 Label：纯粹浪费合图空间。

• 单一使用的背景框。

• 非主角相关的 icon 贴图。

• 其它低频次的贴图。

通过以上的一些限制条件来控制游戏中参与合图的贴图后，如果能把图集控制在3张以内。那么 DrawCall 可以在稳定的较高的水平。同时，渲染过程中合图的工作可以省掉大部分。

---

以上是由 Cocos 开发者 乐府-堂主 分享的优质技术教程，欢迎分享本文给身边的朋友，也欢迎您在评论区或进入作者原文一起交流！

乐府系列更多分享：

如果您在使用 Cocos 引擎的过程中，获得了独到的开发心得、见解或是方法，并且乐于分享出来，帮助更多开发者解决技术问题，加速游戏开发效率，期待您与我们联系！