你应该是用了 DynamicAtlas 是吧？感觉一个界面一个 DC 还挺牛逼的。
在 3.4.2 合批策略确实有调整，你试试把 macro.BATCHER2D_MEM_INCREMENT 增大一些，比如增大到 1440，看看是不是 draw call 能降下来
没有 用DynamicAtlas 关闭了 用的plist
那你那个界面是咋合批的，所有文字都是贴图吗？
用的位图 用工具导出的
运行的时候 换的plist里面的贴图
麻烦具体解释一下，或者给一个外网可访问的地址
我的字体都是font格式的 把font的图片打进了plist 在加载的时候我重新设置了label字体的font的spriteFrame 为plist里面的那张图， 现在在3.4.2 drawcall 就显示不正常的，在3.4.0里面可以正常显示
外网访问地址 没有弄 可以的话 你可以加下QQ 远程看下
哈哈哈，没想到还真的有人这么做，我之前也是想着将bmfont和图片散图合在一张图上。。。。。。。
这个不错。学习下。
实测3.4.2还算是挺稳定的，没多少普通的bug（编辑器bug不算在里面），
说下cc的编辑器bug的通病：各大组件的互斥功能做的很差劲，比如widget和layou的多个功能重合的情况下会出现模棱两可的渲染模式，在编辑器上面表现为不断增长的height或者width，说明很多互斥的东西没加足够的判断，再一个就是编辑器的内存的占用还是居高不下，实测你们编辑器的网络服务有内存泄漏的可能性，
在这里还是要吐槽下引擎组的大佬，作为一个通用游戏引擎，对于读取/写入文件这种基础功能的API,应当需要一套好用的接口，包括但不限于如下方法：
getFileInfo(filepath) 返回文件大小等信息
readFile(filepath) 返回数据 同步读取文件
readFileAsyc(filepath,callback) 异步读取文件
writeFile(data,filepath) 写入文件
以上应当是最基础的API,并且要实现跨平台统一接口，引擎内部去实现各种平台文件读取和写入
现在creator的引擎大佬们，想当然地做了各种封装，以为大家按照他们的设想去使用就好了。 其实在开发游戏的过程中，有好多定制的需求，比如文件加密压缩等就需要依赖这种原始的文件读取写接口，希望大佬们多看看竞品的API以及文档。
说到底，作为一个游戏引擎，需要多种层级的接口，以满足不同开发层级的需求。做简单游戏开发的，可以使用高层接口。有特殊定制需求的可以使用低层接口去实现定制需求
3赞
现在自动图集不是已经支持这么做了么？
无力吐槽啊。。ios导出虽然添加的跳过xcode工程更新，但是资源变动不会更新到工程。。有何意义。。
帮你顶下+1
你在哪个版本遇到的问题? 这个问题在最近发布的版本已经解决.
这个问题修复没有
实测确实是 buffer 不够大导致的，尝试以下方法可以让 drawcall 回归 6
// 在任意组件脚本的全局空间下加入
macro.BATCHER2D_MEM_INCREMENT = 512;
这样会将一段 buffer 最大尺寸设置为 512KB（原始值是 144KB），合批被打断的原因是你的界面元素过多，需要两段 144KB 的 buffer，而在渲染”回收设置“的界面时，出现了一部分元素之间 buffer 不同导致的无法合批，属于正常现象。
附上这个宏的说明：
Batcher2D 中内存增量的大小（KB）
这个值决定了当场景中存在的 2d 渲染组件的顶点数量超过当前 batcher2D 中可容纳的顶点数量时，内存扩充的增加量。
这个值越大，共用同一个 meshBuffer 的 2d 渲染组件数量会更多，但每次扩充所占用的内存也会更大。
默认值在标准格式（[[vfmtPosUvColor]]）下可容纳 4096 个顶点（409694/1024），你可以增加容量来提升每个批次可容纳的元素数量。
1赞