Android性能优化——界面流畅度优化

序言

首先流畅度不仅仅是受到代码的影响。也会跟机器的硬件配置有关系。所以第一点需要明确的是，流畅度最低保证在哪个硬件配置之上。这样有了一个基点之后，才能比较好明确优化目标。不然你拿一个两三年前的机子来做优化。那就真的是吃力不讨好的事情。

流畅度跟两方面有关：一、机器的配置，二、编写的代码。

首先明确一点：流畅意味着每一帧的绘制在16ms内完成。

那如果在你选的最低配置的机子上达到了流畅，那就没必要优化了。如果在你选的机子上，出现了较大的流畅性问题，那就需要着重优化。

使用的工具

我们需要使用Systrace工具来进行优化。具体的使用方法，这里就不详细介绍了。我在这里附上Android官方文档，你也可以寻找相关博客学习。Android Systrace使用文档

这里开始，就是假设你已经看过相关博客和官方文档了，懂得如何使用systrace来测量界面流畅性。

需要的东西：1. 作为基准的手机。 2. chrome 3.Android Monitor工具集。

步骤

获取测试报告(也就是.trace文件)
当开始systrace测试时，在相应的页面上滚动。然后systrace就会在设定的时长（默认5秒）结束。并在（默认在user目录）相应的目录下生成trace.html报告
使用chrome打开
在chrom中键入 chrome://tracing ，回车。得到如下页面。打开刚刚生成的文件

点击Load，回弹出一个文件选择器，选中刚刚生成的 trace.html 文件。就打开该报告
分析
滚动到帧相应的行。Frames，并展开UIThread

往右边看，我们可以看到F标记。一个F表示一帧。绿色的F，表示该帧在16ms内绘制完成。而红色则表示，严重超出了16ms。也就是通常所说的掉帧。

从上面这幅图可以看到。红框框出来的地方就是卡顿的地方。我们通过快捷键w(放大）s(缩小) a(向左移动）d(向右移动）来操控
就让我们放大红色区域看看

可以看到蓝绿部分都是GridView inflate操作，看起来GridView回收机制没有生效。然后回到代码中分析后，发现原来是因为这个页面的结构是ListView嵌套了GridView。这就是不断inflate的原因所在。

解决

发现问题之后，解决起来也就有方向了。这个就得看具体原因了。

总结

界面流畅度一般来说就以下两种造成

getView执行时间过长。（绝大多说滚动的页面都是ListView或者RecycleView做的，所以出问题就在getView那里了）
频繁的创建大的临时对象或者过多的临时对象，触发频繁的垃圾回收。垃圾回收时，其他线程是会停止工作的，包括主线。等垃圾回收完毕，主线才会继续工作。这就导致了卡顿。