标签:调用 界面 ITEM 发热 hashCount 排查 优化 CHANGE
1.表现
在低端机发热很严重,运行十分钟就会非常烫手。
测试机型:iphone6,iphone7,iphone7p
2.排查
可以利用chrome的performance工具进行性能监控,得到下图。
我们可以直观看到几个大波峰,表示这里严重占用cpu资源。这是我们的重点解决对象。
选择其中某一段,并且滚动鼠标滑轮可以进行放大,看到里面代码的调用堆栈。
上面是白鹭的渲染逻辑,可以通过减少drawcall来减低这部分消耗。
这是其中一个优化点。
光靠上面的图,还不能很好定位发热。
之前一直认为ITEM_CHANGE消耗最厉害,移除了该事件后,还是比较发热。
所以我在SimpleDispatch类里面加了时间日志,计算出每个事件的执行时间和频率,最终得出ITEM_CHANGE、ROLE_EQM_INFO和GAME_TIME_TICK调用最频繁,其中ITEM_CHANGE最消耗cpu。所以接下来重点监控这两个事件。
existBetterEqmToWear该函数本身耗时极大,在打开角色界面后,每次挂机获得金币或者经验都会调用一次,大概是2秒/次。所以打开角色界面后,温度很快就上去了。
由此得出第二个优化点是,降低existBetterEqmToWear和BagModel里的几个获取装备方法的调用频率。
GAME_TIME_TICK时间每秒分发一次。其中调用getPower比较频繁。
我直接全局搜索了绑定这个事件的地方,查看有没有内存泄漏的地方。
ROLE_EQM_INFO在刚开始进入游戏的时候只调用一次,但消耗非常大。
3.解决
通过上面的分析后,我做了以下优化工作:
1.减少drawcall
当活动面板或者大部分大屏面板打开时,隐藏战斗角色和战斗特效。模型超出屏幕一定可见区域,进行隐藏。屏幕特效超过一定数量,进行拦截处理。
2.在频繁调用的函数里加入脏位优化算法
在RoleMode、AttrInfo和BagModel加入脏位优化算法。
3.hashObject调试
这个hashCount是由白鹭引擎内部 API,用于统计引擎对象的创建数量。在引擎的 HashObject 的构造函数这里添加一个打印日志,对比当前hashCount跟上一个hashCount,在运行时去检查调用堆栈
通过日志发现战斗特效、伤害飘字造成频繁的创建销毁,通过内存池进行优化。
4.分帧加载
元素较多的界面、副本玩法创建较多怪物,进行游戏一次性加载过多界面时,进行分帧处理,避免同步计算造成瞬间掉帧严重。
标签:调用,界面,ITEM,发热,hashCount,排查,优化,CHANGE 来源: https://blog.csdn.net/u011469832/article/details/111295133
本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享; 2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关; 3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关; 4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除; 5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。