序言 首先流畅度不仅仅是受到代码的影响。也会跟机器的硬件配置有关系。所以第一点需要明确的是,流畅度最低保证在哪个硬件配置之上。这样有了一个基点之后,才能比较好明确优化目标。不然你拿一个两三年前的机子来做优化。那就真的是吃力不讨好的事情。
流畅度跟两方面有关:一、机器的配置,二、编写的代码。
首先明确一点:流畅意味着 每一帧的绘制在16ms内完成。
那如果在你选的最低配置的机子上达到了流畅,那就没必要优化了。如果在你选的机子上,出现了较大的流畅性问题,那就需要着重优化。
使用的工具 我们需要使用Systrace工具来进行优化。具体的使用方法,这里就不详细介绍了。我在这里附上Android官方文档,你也可以寻找相关博客学习。Android Systrace使用文档
【Android性能优化——界面流畅度优化】这里开始,就是假设你已经看过相关博客和官方文档了,懂得如何使用systrace来测量界面流畅性。
需要的东西:1. 作为基准的手机。 2. chrome 3.Android Monitor工具集。
步骤
- 获取测试报告(也就是.trace文件)
当开始systrace测试时,在相应的页面上滚动。然后systrace就会在设定的时长(默认5秒)结束。并在(默认在user目录)相应的目录下生成trace.html报告 - 使用chrome打开
在chrom中键入 chrome://tracing ,回车。得到如下页面。 打开刚刚生成的文件
文章图片
点击Load,回弹出一个文件选择器,选中刚刚生成的 trace.html 文件。就打开该报告 - 分析
滚动到帧相应的行。Frames,并展开UIThread
文章图片
文章图片
从上面这幅图可以看到。红框框出来的地方就是卡顿的地方。我们通过快捷键w(放大)s(缩小) a(向左移动)d(向右移动)来操控
就让我们放大红色区域看看
文章图片
文章图片
可以看到蓝绿部分都是GridView inflate操作,看起来GridView回收机制没有生效。然后回到代码中分析后,发现原来是因为这个页面的结构是ListView嵌套了GridView。这就是不断inflate的原因所在。
解决 发现问题之后,解决起来也就有方向了。这个就得看具体原因了。
总结 界面流畅度一般来说就以下两种造成
- getView执行时间过长。(绝大多说滚动的页面都是ListView或者RecycleView做的,所以出问题就在getView那里了)
- 频繁的创建大的临时对象或者过多的临时对象,触发频繁的垃圾回收。垃圾回收时,其他线程是会停止工作的,包括主线。等垃圾回收完毕,主线才会继续工作。这就导致了卡顿。