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

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

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

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

如何评测流畅度?

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


《移动App性能评测与优化》读后感—流畅度_第1张图片
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 布局中不合理的地方

  • 减少布局层次, 利用 消除无用的父布局
  • 不常用的 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

你可能感兴趣的:(《移动App性能评测与优化》读后感—流畅度)