Tag Archives: TypeScript

Hello World

Label对Drawcall的影响测试

众所周知,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!

Hello World

浅析schedule与update的关系

schedule是cocos自带的定时器,这里简单试试这玩意的执行情况:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
    onLoad () {
        this.schedule(()=>{
            let now = new Date().getTime();
            console.log('schedule-test, schedule 0.001', now);
        }, 0.001);
        this.schedule(()=>{
            let now = new Date().getTime();
            console.log('schedule-test, schedule  0.01', now);
        }, 0.01);
        this.schedule(()=>{
            let now = new Date().getTime();
            console.log('schedule-test, schedule   0.1', now);
        }, 0.1);
    }
 
    update (dt) {
        let now = new Date().getTime();
        console.log('schedule-test,         update', now);
    }

输出如下:
————
schedule-test, update 1658395521046
schedule-test, schedule 0.001 1658395521047
schedule-test, schedule 0.01 1658395521048
schedule-test, update 1658395521063
schedule-test, schedule 0.001 1658395521064
schedule-test, schedule 0.01 1658395521065
schedule-test, update 1658395521080
schedule-test, schedule 0.001 1658395521081
schedule-test, schedule 0.01 1658395521082
schedule-test, update 1658395521097
schedule-test, schedule 0.001 1658395521098
schedule-test, schedule 0.01 1658395521099
schedule-test, schedule 0.1 1658395521100
schedule-test, update 1658395521113
schedule-test, schedule 0.001 1658395521114
schedule-test, schedule 0.01 1658395521115
。。。。
————
简单总结一下,可以得到下面几个结论:
1. 在cocos的世界里,一“帧”,就是它的最小计时单位,也是schedule的最小调用周期,比帧间隔再小的时间单位,对schedule无效
2. schedule(可能)会在每一帧的update以后,调起定时逻辑
3. 即使定时间隔大于帧间隔,schedule也不能按毫秒级的时间精确调起回调函数(这一点从定时“0.1s”的回调里可以看出,不过上面没贴出出这么多)
嗯,简单来说看,可以把schedule当成低配版setInterval,既然cocos提供了自己的定时器,就尽量少用setInterval和setTimeout吧
————
转载请注明出处:http://www.jiangkl.com/2022/07/cocos_schedule_update