表示关注，
生成图片怎么样？对于大多数文字来说，并不需要动态修改
ttf 用的时候本来就是边用边缓存字符纹理的，只不过是分页的，不知道你说的生成图片是指什么…
label全是ttf吗，系统字体试过没有，如果是一大段文字的话，系统字应该划得来一点，混合了sprite的话可以试着分层来画，ttf的drawcall合并好像是不大好弄，按引擎现在的逻辑逐字来画，要连续命中同一页…
能使用bmfont的地方尽量使用bmfont，可合并draw,目前此办法最可用
我是新人关注下，
目前项目里都是用TTF，
各位前辈都是把所有文字改为BMF吗？
多语系也是这么做？
就是所有文字生成一张图片
之前也问过这个，bmfont是当前可用的方法了
这个可以去适当看下源码，看下ttf label的绘制过程，这里面ttf涉及到字体缓存的问题，里面用freetype库加载ttf，label绘制的时候会逐个生成/获取对应字符的图形(缓存了就直接用)，放到缓存页(512x512的纹理)中并形成索引，组合形成一个label.（过程大概是这样）
按你这意思是不缓存咯，那效率照样会被吐槽，生成对应字符的图形数据也是要成本的，不然引擎为嘛要这么做，考虑效率呗
系统字体会比ttf省吗？我记得ttf字体引擎是先生成一张字图，系统字体是怎么样的呢？
1.这个省不省应该要看哪方面，我也没测试过，不过ttf能实现的效果要比系统字丰富
2.系统字就是，一个label的整个内容字符串就是一张图，,只不过这个是调用系统api生成image data，格式化成cocos需要的格式，所以它是不缓存的，每次label.setString成不同内容都会重复这个过程
ok多谢解答~
现在只能做到 同字号&&同描边颜色 才合并.
shadow颜色不受影响, 外发光没搞定.
看起来很美好,实际上收效甚微
测试环境 iphone6s release版
8000个label
1 drawcall 和 8000 drawcall
fps相差 0.几 21 和 22的差别
Android上面没有测, windows和iOS结果一致
因为label的像素填充数量实在太少了. 所以即使合并,也没有太大的收益.
最近正在做 drawcall 和像素填充数量 关系的测试. 如果有人知道其中奥秘,请不吝赐教
关于ttf合并批次, 我的建议是
不
用
搞
了
4赞
确实6s上优化没啥意义. 如果是低端android机还是有点必要.
有解决方案吗？
2.0.9版本ttf可以被合并了
性能瓶颈不在这，单独合并lable是没意义，关键要把label和相邻的sprite合并，或者想办法不打断sprite的合并，这样才能提升性能，要把图片混进去。
这个后面有没有通用的解决方案啊 真是蛋疼啊
大佬 能共享下修改的代码吗