Quantcast
Channel: Cocos中文社区 - 最新主题
Viewing all articles
Browse latest Browse all 88737

关于creator性能调优的问题 和 部分解决方法

$
0
0

@yangzhu626 写道:

项目进入到调优阶段 发现产品性能问题较大,需要较大的调整。问题点列表如下,有部分已解决,有部分尚待解决。抛砖引玉,希望大神提供思路。
问题
1:安桌真机渲染性能很低,部分UI面板帧速低于10帧(手机比较破)。
渲染的优化基本集中于降低draw call。引擎本身有对同一图集的相领渲染节点做同一批次的处理。


**如果A B C三个精灵的spriteFrame来自于同一图集,那么将共用一次drawcall. **
如果A C来自于同一图集,B来自另一图图集,那么将占用三次 draw call。
如果A B 来自于同一图集,C来自于另一图集,那么将占用2次draw call.

draw call的次数来次于渲染过程中图集的切换次数。

于是优化的点便来自于对节点层级进行规划。让来自于相同图集的处于连续的位置。 这需要在制作UI的过程中非常精细的控制图片的来源和节点顺序。 经过优化,部分面板的draw call降了很多。部分甚至超过一半。

另外需要注意的是每个Label会单独占用一次draw call。并且会打断连续的节点。 所以在面板规功的时候最好把所有的label单独提出到一个空节点。 否则会吃大亏。draw call翻倍不是梦。稍不注意就过百。
另外对于label这个 创建性能极差 渲染性能极差 又大量要用的东西有另外一种优化方案。
> BMFont会让多个连续的label共用同一次draw call。注意 多个BMFont label中间不要置入普通的label,否则draw call一样会被打断。

2:cc.instantiate()实例化对像性能极差,造成打开面板 批量创建对像(列表cell)时响应速度很差。

简单跟踪了一下cc.instantiate方法的实现。发现只是深度拷贝一个对像。JS的深拷贝性能一直极其坑爹。也没有想到什么合适的方法能优化这一块。求大神给予指导。 另外对像池有利于减少cc.instantiate()的调用,复用之前的对像。但是在面板上需要一下子批量创建出大量面板图标的情况下。cc.instantiate性能实在着急。 询问官方人员,说以后有可能用类似jit的方式去实现对像的拷贝。 不懂什么是jit方式。只求快一点。

3:scrollView拖动体验不尽如人意。有顿挫感。安桌不说,IOS上也会。

暂时还没找原因。只是发现这个问题。scroll上有很多个卡牌的精灵。这体验实在着急。另外这里已经使用了对像池。新出现的scrollview仅仅是从池中取出再add到节点上。

4:tiledMap在地图超大时会出现内存爆增,直接卡死。

这个之前有发帖写过。http://forum.cocos.com/t/ccc-tiledmap-demo/37879 解决方法也有共享到git。思路对超大型地图的实现有用。代码不够优美。参考即可。

很感谢天天被我烦的工作人员 Jare

帖子: 2

参与者: 1

阅读整个主题


Viewing all articles
Browse latest Browse all 88737

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>