支持动态合图的渲染组件： 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 并不会在一个 Dr awCall 里渲染。
如果一直不切换场景，那么随着动态合图的数量增长，渲染效率可能会降低，适得其反。
这里使用官方文档中给到一个实例 暗黑斩来测试动态合图的效果。
暗黑斩: 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
functionbeforeSceneLoad{
//dynamicAtlasManager.reset;
}
然后测试此时的动态合图效果：
如上图所示：
所有符合合图条件的纹理都合并到一张图集上， DrawCall依次为 9和 25。
3.2 增加资源释放
在 DEMO 中切换场景时，增加资源释放代码：
// HomeUI.js
playGame: function{
cc.eventManager.pauseTarget(this.btnGroup, true);
letself = 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;
letself = 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
letres = {
cleanRes: function( oldScene, newScene ) {
letscene = cc.director.getRunningScene
letoldDeps = scene.dependAssets
letnewDeps = cc.loader.getDependsRecursively(newScene)
letlength = oldDeps.length
for( letindex = length - 1; index >= 0; --index) {
letdep = 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 所示，出现多张图集时，主要有以下影响：
图集数量的增加消耗了内存。
图集数量的增加导致 Dr awCall 可能会升高，图集数量越多，影响越大。
综合以上 DEMO 中的尝试，我们可以得出结论：
如果要在实际项目中从效率和性能兼顾的方向来使用动态合图，显然当前的这个机制是不符合要求的，那么主要解决哪些问题？我认为有以下两个：
只要原始贴图参与过合图，不论后来是否被释放，下次能直接使用合图中已经有的纹理来渲染，而不必再占用新的图集空间。
控制总的动态图集数量，最好不能超过3张，最好在2张(含)以内。
为了能够重复利用合图的空间，我们需要明白为什么同一个资源被释放后，它在合图空间中的纹理不能再次被使用了。我们通过阅读源码可以找到答案:
// atlas.js
insertSpriteFrame (spriteFrame) {
letrect = spriteFrame._rect,
texture = spriteFrame._texture,
// 合图记录是通过纹理的_id值来查找的。
info = this._innerTextureInfos[texture._id];
......
}
// CCTexture2D.js
ctor{
// 生成id的方法
this._id = idGenerater.getNewId;
......
}
// id-generate.js
functionIdGenerater (category) {
// init with a random id to emphasize that the returns id should not be stored inpersistence data
this.id = 0 | (Math.random * 998);
this.prefix = category ? (category + NonUuidMark) : '';
}
IdGenerater.prototype.getNewId = function{
returnthis.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。
贴图符合合图要求，但使用频次较低。
贴图是否会打断需要批量渲染的组件。
贴图参与合图后能否显著提高当前界面 Dr awCall 。
相反，我们真正需要动态合图的需求是：
复用结构中的小尺寸贴图。
高频次使用的小尺寸贴图。
常用列表上的公共背景贴图。
高频次使用的 TTF 的小图集。
最后，一定不要参与合图的是：
BITMAP 模式的低频次 Label ：纯粹浪费合图空间。
单一使用的背景框。
非主角相关的 icon 贴图。
其它低频次的贴图。
通过以上的一些限制条件来控制游戏中参与合图的贴图后，如果能把图集控制在3张以内。那么 DrawCall可以在稳定的较高的水平。同时，渲染过程中合图的工作可以省掉大部分。
以上是由 Cocos 开发者 乐府-堂主分享的优质技术教程， 欢迎分享本文给身边的朋友，也欢迎您在评论区或进入作者原文一起交流！
乐府系列更多分享：
2487
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
