《移动App性能评测与优化》读后感—流畅度

FPS : 1s 内 SurfaceFLinger 提交到屏幕的帧数。

• FPS 很低，但是不卡。 是因为你的 app 在这 1s 内只有 30 帧的显示需求； 如果没有绘制需求, FPS 就是 0；

• App 停止操作后 FPS 还在变化， 是因为每一帧的合成是针对手机所有进程的， 即使你的 app 停止了绘制，其他的进程可能还在绘制，例如通知栏；

如何评测流畅度？

FPS 评测流畅度并不准确，那么应该找到一个什么样的指标进行评测呢？
Android 4.1 引入了 VSync 机制。

vsync.png

VSync 机制就像一台转速固定的发动机(60转/s)，每一转带动着做一些 UI 相关的事情。有时候因为各种阻力， 某一圈的工作量比较重， 超过了 16.6ms, 那么这一秒内就不是 60 转了。
我们通过测量这个转速，来评判应用的流畅度

Android 系统中， Choreographer 类通过监听系统 VSync 信号来协调 App 的动画、输入、绘制工作。 它本身是单例模式。

丢帧计算：在一次 Loop 时，如果执行时间超过了 16.6ms, 那么多余 16.6ms 的时间除以 16.6ms, 即是当前 App 的丢帧情况。

注册 Choreographer callback 事件， 在每一帧绘制完成后， 执行回调

  Choreographer.getInstance().postFrameCallback(new Choreographer.FrameCallback() {
            @Override
            public void doFrame(long frameTimeNanos) {
                //do calculate

                Choreographer.getInstance().postFrameCallback(this);
            }
        });

流畅度值计算：

SM = 帧率(60) * (单位时长总帧数 - 单位时长丢帧数) / 单位时长总帧数

评测标准：

SM值	卡顿情况
SM <= 20	卡死
20 < SM <= 40	很卡
40 < SM <= 50	较卡
50 < SM <= 60	流畅

如何优化

避免过度绘制

设置中开发者选项打开过度绘制区域查看。

	OverDraw 倍数	像素点绘制次数	可接受区域
无色	0X	1	全局
蓝色	1X	2	大片
绿色	2X	3	中等
浅红	3X	4	小，少
暗红	4X	≥ 5	无

解决 UI 布局中不合理的地方

• 减少布局层次， 利用 <merge> <ViewStub> 消除无用的父布局
• 不常用的 UI 设置成 GONE
• 灵活使用 ConstraintLayout

Lint 扫描

Lint 介绍

优化逻辑

1. TraceView 寻找卡住主线程的地方
2. Systrace 获取 app 运行是线程的信息以及 API 的执行情况
3. 避免在主线程执行 IO 操作
4. 优化布局结构
   • 尽量多使用 RelativeLayout 和 LinearLayout
     • 在布局层次一样时，LinearLayout 比 RelativeLayout 性能稍高一点
     • 相对复杂的而不惧， RelativeLayout 可以比 LinearLayout 减少层级
   • 可复用的组件抽取处理啊通过 include 标签使用
   • 使用 ViewStub 标签来加载一些不常用的布局
   • 使用 merge 标签减少布局的嵌套层次
   • 去掉多余的背景颜色，减少过度绘制

Github 上找到的一个 SM 库实现:
https://github.com/friendlyrobotnyc/TinyDancer