众所周知，drawcall的数量是影响CocosCreator流畅度的一个重要指标，本文主要测试Label与Sprite混排时对性能的影响，主要有下面几个对照量：
1. 运行环境，共三种：
a. mac端chrome浏览器（开启开发者工具、尺寸模拟iphon12pro）
b. iphone（8plus）自带浏览器
c. android（其实是鸿蒙、麒麟820/6G运存）自带浏览器
2. Label属性CacheMode，这里节选一下官方文档：
a. None: 默认值，Label 中的整段文本将生成一张位图
b. BitMap: 选择后，Label 中的整段文本仍将生成一张位图，但是会尽量参与 动态合图。只要满足动态合图的要求，就会和动态合图中的其它 Sprite 或者 Label 合并 Draw Call。由于动态合图会占用更多内存，该模式只能用于文本不常更新的 Label
c. Char: 原理类似 BMFont，Label 将以“字”为单位将文本缓存到全局共享的位图中，相同字体样式和字号的每个字符将在全局共享一份缓存。能支持文本的频繁修改，对性能和内存最友好……不能参与动态合图（同样启用 CHAR 模式的多个 Label 在渲染顺序不被打断的情况下仍然能合并 Draw Call）
3. 节点形态：每一个精灵节点下，加一个Label子节点;精灵节点简单转动或摆动；Label仅显示数字，使用系统字体；测试过程共分三种情况：50/200/1000个节点
4. Label节点除了会修改CacheMode，还会尝试两种情况：不修改文案内容、每秒修改一次文案内容
基本的测试要素就是上面这些，下面来看测试结果
简单总结几个结论：
1. 就像文档里说的，对于固定内容的Label，BitMap确实对性能有巨大帮助，可以通过合批最大程度减少Drawcall
2. 对于Label和Sprite混排的情况，文本如果还要频繁更新，性能必然会受影响，如果预期这类节点数量很多，一定不能这么做
3. 虽然测试用的chrome浏览器已经开启了硬件加速，但或许是对m1mac的适配不好，这次测试chrome浏览器的表现完败，甚至不如六年前的iphone手机。（试了一下mac自带的safar浏览器，表现和iphone手机浏览器差不多）
那么，针对上面提到的第二条，如果确实需要大量、频繁更新的文本，应该怎么办？看文档大概有下面两种解决方案：
1. 使用艺术字图集代替系统字体
2. 将Label节点提出来，不要和Sprite混编
后续有时间试试这两种方案的效果 o(*￣︶￣*)o
————
转载请注明出处：http://www.jiangkl.com/2023/04/cocos_label_drawcall
————
补充：
继续上面的话题，按照第2个解决方案对项目做了“优化”，也就是将所有的Label提取出来，单独放在一个节点了，和Sprite区隔开，测试结果：
1000个节点的情况下，三个端都能轻松运行，FPS 60，Drawcall 5，成功将1000个Label合批到一个Drawcall！
关于本站