牛皮~，Mark！顶你上天
DrawCall变小
FrameTime变大
意义？
你如果仔细看了代码就知道消耗不高。如果觉得没意义不好意思浪费你时间了。
我只看最终数据
每帧的耗时增加一样掉帧
每帧执行 getComponentsInChildren 可能开销有点大. 有没有可能对 walk 动手脚 来替代.
还有 .forEach 性能也不高.
你说的在这里
可以开个场景试下。这个frametime是不稳定的。不开合批策略也能这么多时间。
就是用英文再写一次
mark…
Mark…
MARK…
mark…
基于本案例的策略，进一步结合 TableView 的业务场景，直接根据虚拟列表的业务场景，直接将虚拟列表的item在创建的时候去重定义_render 然后不再需要每帧去收集需要渲染的对象，进一步提升了优化性能。感兴趣的朋友可以前去github看最新案例。
opacity的父子关系会不会出问题，有个继承关系
mark…
只是延迟了命令的提交。渲染状态还是和原先一样的。不过由于mask的实现有些特殊所以唯一有问题的就是不支持mask
牛皮的普拉斯
马克…
mark.
亲测好用，big old six B plus。