摘要:而模拟卡顿的图表中,每一帧的绘制则不均匀,有的长达将近。但由于是我们自身模拟的结果,并非实际卡顿,所以图表中均为绿色的显示。至此,我们就抓到了导致掉帧的元凶,下一步就是结合源代码进行优化了。如何快速定位卡顿位置首先是确保发生了卡顿。
这次我们依旧来谈谈有关性能优化的话题,这次我们会用到Google给我们提供的分析工具——Systrace。如果你还不了解这个工具,最好先了解一下。Google 官方文档:
https://developer.android.com/studio/command-line/systrace
我们还会用到一个Demo,用来对比卡顿和不卡顿的状况。
Demo运行起来会是这样的:
流畅运行
模拟卡顿
这里解释一下,GIF动画表现得不是很完善,流畅运行的效果其实是每秒60帧,实际运行效果非常顺畅。模拟卡顿的效果在每秒60帧的基础上加了随机时长的线程sleep时间。具体实验代码片如下所示:
流畅运行的代码片
threadRun = true; pbCurrent = 0; demoPb.setProgress(pbCurrent); new Thread(new Runnable() { @Override public void run() { while (threadRun) { try { Thread.sleep(1000 / 60); } catch (InterruptedException e) { e.printStackTrace(); } if (pbCurrent > PB_MAX) { pbCurrent = 0; } else { pbCurrent++; } Message msg = new Message(); msg.what = UPDATE_HANDLER_KEY; mUiHandler.sendMessage(msg); } } }).start();
模拟卡顿的代码片
thread2Run = true; pbCurrent = 0; demoPb.setProgress(pbCurrent); new Thread(new Runnable() { @Override public void run() { while (thread2Run) { try { Thread.sleep(1000 / 60); Thread.sleep(new Random().nextInt(200)); } catch (InterruptedException e) { e.printStackTrace(); } if (pbCurrent > PB_MAX) { pbCurrent = 0; } else { pbCurrent++; } Message msg = new Message(); msg.what = UPDATE_HANDLER_KEY; mUiHandler.sendMessage(msg); } } }).start();
更新UI部分代码片
@Override public void handleMessage(Message msg) { super.handleMessage(msg); switch (msg.what) { case UPDATE_HANDLER_KEY: demoPb.setProgress(pbCurrent); break; } }
两个按钮分别对应上述两个线程的使能,另外请注意:我们只是模拟卡顿,并非真的发生了卡顿。因此,在Systrace的图表中,没有出现红色或橙色的告警。
分别对上述两种情况取Systrace图表,得到如下结果:
流畅运行的图表
模拟卡顿运行的图表
通过对比,我们可以看到上面二者之间的差别。流畅运行的图表中,每一帧的绘制很均匀。差不多16.6ms一帧,也就是1000毫秒除以60帧,得到的16.6ms一帧。而模拟卡顿的图表中,每一帧的绘制则不均匀,有的长达将近200ms。但由于是我们自身模拟的结果,并非实际卡顿,所以图表中均为绿色的显示。下面我们来看一个真实的案例:
真实案例
上图中,一帧本来应该是16ms完成的,然而却花费了近60ms,用1000ms/60ms,我们得到近似16帧。而16帧的帧率已经是肉眼可见的卡顿了。
我们聚焦到上面真实的案例,放大看发生卡顿的位置:
我们发现,Record View 的draw()方法花费了一些时间。
此外,还有一堆琐碎的小片段,我们进一步放大观察,会发现:
这里居然还加载了一堆贴图。
至此,我们就抓到了导致掉帧的“元凶”,下一步就是结合源代码进行优化了。
为什么16ms一帧?
16ms是1000ms/60帧得到的结果,60帧对于人眼而言已经是很流畅的体验了。而最低的限度是33ms一帧,也就是1000ms/30帧得到的结果。如果时间再长一点的话,就有可能发生人眼可见的卡顿了。
延伸一点,也就是说,如果严格要求60帧,但是中间掉了1帧,就相当于33ms画一帧,此时,虽然掉帧,但是人眼还是可接受的。
如何快速定位卡顿位置
首先是确保发生了卡顿。一般而言,没有发生卡顿的图表,网页的图表会是绿色的,发生卡顿的则是红色的。
然后我们使用键盘+鼠标的组合来找位置,键盘的快捷键对应W、S、A、D。AD相当于拖拽时间滑块,WS相当于缩放。
最后我们用鼠标来选取相应的时间范围即可。
今天的分享到此,希望对你有帮助。
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/2468.html
摘要:前言淘宝新势力周春上新是命运石链路链路第一次承接级大促,面对级大促内容丰富且复杂的页面需求,链路遇到了一些性能问题,在未进行性能优化之前,搭建出来的页面,业务方普遍反馈页面卡顿严重,无法滑动。 前言 淘宝新势力周(春上新)是命运石kimi链路(H5链路)第一次承接S级大促,面对S级大促内容丰富且复杂的页面需求,kimi链路遇到了一些性能问题,在未进行性能优化之前,搭建出来的页面,业务方...
摘要:,部分设备支持功能,在启用功能后,系统会对内存进行压缩,增加,会相应减少,由于压缩会占用资源,同时相应会导致降低虚拟内存整机可用剩余内存,极限测试情况下开启可能会造成性能损耗。 一、PerfDog简介 PerfDog性能狗是移动全平台iOS/Android性能测试工具,快速定位分析性能问题,...
摘要:性能优化实践原文链接本文记录了优化需要用到的工具和以及在实践中的。关于优化,推荐一篇博客,给我很大帮助,性能优化系列。 Android App 性能优化实践 原文链接: http://stackvoid.com/performance-tuning-on-android/ 本文记录了Android App优化需要用到的工具和以及在实践中的Tips。也算对我这半年来部分工作的...
摘要:那么问题就是如何有效检测主线程的卡顿发生,目前业界两种主流有效的监控方式如下,在卡顿监控方式实现这篇文章中我将分别详细阐述这两者的特点和实现。欢迎大家前往腾讯云+社区,获取更多腾讯海量技术实践干货哦~ 本文由likunhuang发表于云+社区专栏 实现背景 应用的使用流畅度,是衡量用户体验的重要标准之一。Android 由于机型配置和系统的不同,项目复杂App场景丰富,代码多人参与迭代历...
摘要:若某个的合成不在中进行如,则该的显示性能无法用这类指标进行衡量。我们再来仔细瞧瞧给出的显示性能测试的十全大补丸。通过这条命令,我们获取每一帧绘制过程中每个关键节点的耗时情况,从而仔细的分析潜在的性能问题。 前言 注:Google 在自己文章中用了 Display Performance 来描述我们常说的流畅度,为了显得有文化,本文主要用显示性能一词来代指流畅度(虽然两者在概念上有细微差...
阅读 1022·2021-11-22 09:34
阅读 3073·2021-09-29 09:35
阅读 320·2021-09-04 16:40
阅读 2798·2019-08-30 15:53
阅读 2448·2019-08-30 15:44
阅读 2480·2019-08-30 14:10
阅读 1218·2019-08-29 18:43
阅读 2078·2019-08-29 13:26