当咱们说 流畅度 的时候，咱们说的是什么？不一样的人对流畅性(卡顿掉帧)有不一样的理解，对卡顿阈值也有不一样的感知，因此有必要在开始这个系列文章以前，先把涉及到的内容说清楚，防止出现不一样的理解，也方便你们带着问题去看这几篇问题，下面是一些基本的说明java

对手机用户来讲，卡顿包含了不少场景，好比在 滑动列表的时候掉帧、应用启动白屏过长、点击电源键亮屏慢、界面操做没有反应而后闪退、点击图标没有响应、窗口动画不连贯、滑动不跟手、重启手机进入桌面卡顿 等场景，这些场景跟咱们开发人员所理解的卡顿还有点不同，开发人员会更加细分去分析这些问题，这是开发人员和用户之间的一个认知差别，这一点在处理用户(或者测试人员)的问题反馈的时候尤为须要注意
对开发人员来讲，上面的场景包括了 流畅度（滑动列表的时候掉帧、窗口动画不连贯、重启手机进入桌面卡顿）、响应速度（应用启动白屏过长、点击电源键亮屏慢、滑动不跟手）、稳定性（界面操做没有反应而后闪退、点击图标没有响应）这三个大的分类。之因此这么分类，是由于每一种分类都有不太同样的分析方法和步骤，快速分辨问题是属于哪一类很重要
在技术上来讲，流畅度、响应速度、稳定性（ANR）这三类之因此用户感知都是卡顿，是由于这三类问题产生的原理是一致的，都是因为主线程的 Message 在执行任务的时候超时，根据不一样的超时阈值来进行划分而已，因此要理解这些问题，须要对系统的一些基本的运行机制有必定的了解，本文会介绍一些基本的运行机制
流畅性这个系列主要是分析流畅度相关的问题，响应速度和稳定性会有专门的文章介绍，在理解了流畅性相关的内容以后，再去分析响应速度和稳定性问题会事半功倍
流畅性这个系列主要是讲如何使用 Systrace (Perfetto) 工具去分析，之因此 Systrace 为切入点，是由于影响流畅度的因素不少，有 App 自身的缘由、也有系统的缘由。而 (Perfetto) 工具能够从一个整机运行的角度来展现问题发生的过程，方便咱们去初步定位问题

Systrace 流畅性实战目前包括下面三篇android

Systrace (Perfetto) 工具的基本使用若是还不是很熟悉，那么须要优先去补一下 Systrace 基础知识系列git

了解卡顿原理

卡顿现象及影响

如文章开头所述，本文主要是分析流畅度相关的问题。流畅度是一个定义，咱们评价一个场景的流畅度的时候，每每会使用 fps 来表示。好比 60 fps，意思是每秒画面更新 60 次；120 fps，意思是每秒画面更新 120 次。若是 120 fps 的状况下，每秒画面只更新了 110 次(连续动画的过程)，这种状况咱们就称之为掉帧，其表现就是卡顿，fps 对应的也从 120 下降到了 110 ，这些均可以被精确地监控到github

同时掉帧帧的缘由很是多，有 APP 自己的问题，有系统缘由致使卡顿的，也有硬件层的、整机卡的，这个能够参考下面四篇文章性能优化

用户在使用手机的过程当中，卡顿是最容易被感觉到的markdown

偶尔出现的小卡顿会下降用户的使用体验，好比刷微博的时候卡了一下，好比返回桌面动画卡顿这种
整机出现卡顿的则会让手机没法使用
如今的高帧率时代，若是用户习惯了 120 fps ，在用户比较容易感知的场景下忽然切换到 60 fps，用户也会有明显的感知，并以为出现了卡顿

因此不论是应用仍是系统，都应该尽可能避免出现卡顿，发现的卡顿问题最好优先进行解决数据结构

卡顿定义

应用一帧渲染的总体流程

为了知道卡顿是如何发生的，咱们须要知道应用主线程的一帧是如何工做的app

从执行顺序的角度来看

从 Choreographer 收到 Vsync 开始，到 SurfaceFlinger/HWC 合成一帧结束（后面还包含屏幕显示部分，不过是硬件相关，这里就不列出来了）ide

从 Systrace 的角度来看

上面的流程图从 Systrace （Perfetto）的角度来看会更加直观函数

具体的流程参考上面两个图以及代码就会很清楚了，上述总体流程中，任何一个步骤超时都有可能致使卡顿，因此分析卡顿问题，须要从多个层面来进行分析，好比应用主线程、渲染线程、SystemServer 进程、SurfaceFlinger 进程、Linux 区域等

卡顿定义

我对卡顿的定义是：稳定帧率输出的画面出现几帧没有绘制 对应的应用单词是 Smooth VS Jank

好比下图中，App 主线程有在正常绘制的时候（一般是作动画或者列表滑动），有一帧没有绘制，那么咱们认为这一帧有可能会致使卡顿（这里说的是有可能，因为 Triple Buffer 的存在，这里也有可能不掉帧）

下面从三个方面定义卡顿

从现象上来讲，在 App 连续的动画播放或者手指滑动列表时（关键是连续），若是连续 2 帧或者 2 帧以上，应用的画面都没有变化，那么咱们认为这里发生了卡顿
从 SurfaceFlinger 的角度来讲，在 App 连续的动画播放或者手指滑动列表时（关键是连续），若是有一个 Vsync 到来的时候，App 没有能够用来合成的 Buffer，那么这个 Vsync 周期 SurfaceFlinger 就不会走合成的逻辑（或者是去合成其余的 Layer），那么这一帧就会显示 App 的上一帧的画面，咱们认为这里发生了卡顿
从 App 的角度来看，若是渲染线程在一个 Vsync 周期内没有 queueBuffer 到 SurfaceFlinger 中 App 对应的 BufferQueue 中，那么咱们认为这里发生了卡顿

这里没有提到应用主线程，是由于主线程耗时长通常会间接致使渲染线程出现延迟，加大渲染线程执行超时的风险，从而引发卡顿；并且应用致使的卡顿缘由里面，大部分都是主线程耗时过长致使的

卡顿还要区分是否是逻辑卡顿，逻辑卡顿指的是一帧的渲染流程都是没有问题的，也有对应的 Buffer 给到 SurfaceFlinger 去合成，可是这个 App Buffer 的内容和上一帧 App Buffer 相同（或者基本相同，肉眼没法分辨），那么用户看来就是连续两帧显示了相同的内容。这里通常来讲咱们也认为是发生了卡顿（不过还要区分具体的状况）；逻辑卡顿主要是应用自身的代码逻辑形成的

系统运行机制简介

因为卡顿的缘由比较多，若是要分析卡顿问题，首先得对 Android 系统运行的机制有必定的了解，下面简单介绍一下分析卡顿问题须要了解的系统运行机制：

App 主线程运行原理
Message、Handler、MessageQueue、Looper 机制
屏幕刷新机制和 Vsync
Choreogrepher 机制
Buffer 流程和 TripleBuffer
Input 流程

系统机制 - App 主线程运行原理

App 进程在建立的时候，Fork 完成后会调用 ActivityThread 的 main 方法，进行主线程的初始化工做

frameworks/base/core/java/android/app/ActivityThread.java public static void main(String[] args) {
     ......
     // 建立 Looper、Handler、MessageQueue
       Looper.prepareMainLooper();
       ......
       ActivityThread thread = new ActivityThread();
       thread.attach(false, startSeq);

       if (sMainThreadHandler == null) {
           sMainThreadHandler = thread.getHandler();
      }
       ......
       // 开始准备接收消息
       Looper.loop();
}

// 准备主线程的 Looper
frameworks/base/core/java/android/os/Looper.java public static void prepareMainLooper() {
    prepare(false);
    synchronized (Looper.class) {
        if (sMainLooper != null) {
            throw new IllegalStateException("The main Looper has already been prepared.");
        }
        sMainLooper = myLooper();
    }
}

// prepare 方法中会建立一个 Looper 对象
frameworks/base/core/java/android/os/Looper.java private static void prepare(boolean quitAllowed) {
    if (sThreadLocal.get() != null) {
        throw new RuntimeException("Only one Looper may be created per thread");
    }
    sThreadLocal.set(new Looper(quitAllowed));
}

// Looper 对象建立的时候，同时建立一个 MessageQueue
frameworks/base/core/java/android/os/Looper.java private Looper(boolean quitAllowed) {
    mQueue = new MessageQueue(quitAllowed);
    mThread = Thread.currentThread()
}
复制代码

主线程初始化完成后，主线程就有了完整的 Looper、MessageQueue、Handler，此时 ActivityThread 的 Handler 就能够开始处理 Message，包括 Application、Activity、ContentProvider、Service、Broadcast 等组件的生命周期函数，都会以 Message 的形式，在主线程按照顺序处理，这就是 App 主线程的初始化和运行原理，部分处理的 Message 以下

frameworks/base/core/java/android/app/ActivityThread.java
class H extends Handler {
    public static final int BIND_APPLICATION        = 110;
    public static final int EXIT_APPLICATION        = 111;
    public static final int RECEIVER                = 113;
    public static final int CREATE_SERVICE          = 114;
    public static final int SERVICE_ARGS            = 115;
    public static final int STOP_SERVICE            = 116;

    public void handleMessage(Message msg) {
        switch (msg.what) {
            case BIND_APPLICATION:
                Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "bindApplication");
                AppBindData data = (AppBindData)msg.obj;
                handleBindApplication(data);
                Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
                break;
        }
    }
}
复制代码

系统机制 - Message 机制

上一节应用的主线程初始化完成后，主线程就进入阻塞状态，等待 Message，一旦有 Message 发过来，主线程就会被唤醒，处理 Message，处理完成以后，若是没有其余的 Message 须要处理，那么主线程就会进入休眠阻塞状态继续等待

从下图能够看到，Android Message 机制的核心就是四个：Handler、Looper、MessageQueue、Message

网上有不少关于 Message 机制代码细节的分析，因此这里只是简单介绍 Message 机制的四个核心组件的做用

Handler : Handler 主要是用来处理 Message，应用能够在任何线程建立 Handler，只要在建立的时候指定对应的 Looper 便可，若是不指定，默认是在当前 Thread 对应的 Looper
Looper : Looper 能够当作是一个循环器，其 loop 方法开启后，不断地从 MessageQueue 中获取 Message，对 Message 进行 Delivery 和 Dispatch，最终发给对应的 Handler 去处理。因为 Looper 中应用能够在 Message 处理先后插入本身的 printer，因此不少 APM 工具都会使用这个做为性能监控的一个切入点，具体能够参考 Tencent-Matrix 和 BlockCanary
MessageQueue：MessageQueue 入上图所示，就是一个管理器，队列中是 Message，在没有 Message 的时候，MessageQueue 借助 Linux 的 nativePoll 机制，阻塞等待，直到有 Message 进入队列
Message：Message 是传递消息的对象，其内部包含了要传递的内容，最经常使用的包括 what、arg、callback 等

从第一节 App 主线程运行原理可知，ActivityThread 的就是利用 Message 机制，处理 App 各个生命周期和组件各个生命周期的函数

系统机制 - 屏幕刷新机制和 Vsync

首先咱们须要知道什么是屏幕刷新率，简单来讲，屏幕刷新率是一个硬件的概念，是说屏幕这个硬件刷新画面的频率：举例来讲，60Hz 刷新率意思是：这个屏幕在 1 秒内，会刷新显示内容 60 次；那么对应的，90Hz 是说在 1 秒内刷新显示内容 90 次

与屏幕刷新率对应的，FPS 是一个软件的概念，与屏幕刷新率这个硬件概念要区分开，FPS 是由软件系统决定的：FPS 是 Frame Per Second 的缩写，意思是每秒产生画面的个数。举例来讲，60FPS 指的是每秒产生 60 个画面；90FPS 指的是每秒产生 90 个画面

VSync 是垂直同期( Vertical Synchronization )的简称。基本的思路是将你的 FPS 和显示器的刷新率同期起来。其目的是避免一种称之为”撕裂”的现象.

60 fps 的系统 , 1s 内须要生成 60 个可供显示的 Frame , 也就是说绘制一帧须要 16.67ms ( 1/60 ) , 才会不掉帧 ( FrameMiss ).
90 fps 的系统 , 1s 内生成 90 个可供显示的 Frame , 也就是说绘制一帧须要 11.11ms ( 1/90 ) , 才不会掉帧 ( FrameMiss ).

通常来讲，屏幕刷新率是由屏幕控制的，FPS 则是由 Vsync 来控制的，在实际的使用场景里面，屏幕刷新率和 FPS 通常都是一一对应的，具体能够参考下面两篇文章：

系统机制 - Choreographer

上一节讲到 Vsync 控制 FPS，其实 Vsync 是经过 Choreographer 来控制应用刷新的频率的

Choreographer 的引入，主要是配合 Vsync，给上层 App 的渲染提供一个稳定的 Message 处理的时机，也就是 Vsync 到来的时候，系统经过对 Vsync 信号周期的调整，来控制每一帧绘制操做的时机. 至于为何 Vsync 周期选择是 16.6ms (60 fps) ，是由于目前大部分手机的屏幕都是 60Hz 的刷新率，也就是 16.6ms 刷新一次，系统为了配合屏幕的刷新频率，将 Vsync 的周期也设置为 16.6 ms，每隔 16.6 ms，Vsync 信号到来唤醒 Choreographer 来作 App 的绘制操做，若是每一个 Vsync 周期应用都能渲染完成，那么应用的 fps 就是 60，给用户的感受就是很是流畅，这就是引入 Choreographer 的主要做用

Choreographer 扮演 Android 渲染链路中承上启下的角色

承上：负责接收和处理 App 的各类更新消息和回调，等到 Vsync 到来的时候统一处理。好比集中处理 Input(主要是 Input 事件的处理) 、Animation(动画相关)、Traversal(包括 measure、layout、draw 等操做) ，判断卡顿掉帧状况，记录 CallBack 耗时等
启下：负责请求和接收 Vsync 信号。接收 Vsync 事件回调(经过 FrameDisplayEventReceiver.onVsync )；请求 Vsync(FrameDisplayEventReceiver.scheduleVsync) .

下图就是 Vsync 信号到来的时候，Choreographer 借助 Message 机制开始一帧的绘制工做流程图

这部分详细的流程能够看 Android 基于 Choreographer 的渲染机制详解这篇文章

系统机制 - Buffer 流程和 TripleBuffer

BufferQueue 是一个生产者(Producer)-消费者(Consumer)模型中的数据结构，通常来讲，消费者(Consumer) 建立 BufferQueue，而生产者(Producer) 通常不和 BufferQueue 在同一个进程里面

在 Android App 的渲染流程里面，App 就是个生产者(Producer) ，而 SurfaceFlinger 是一个消费者(Consumer)，因此上面的流程就能够翻译为

当 App 须要 Buffer 时，它经过调用 dequeueBuffer（）并指定 Buffer 的宽度，高度，像素格式和使用标志，从 BufferQueue 请求释放 Buffer
App 能够用 cpu 进行渲染也能够调用用 gpu 来进行渲染，渲染完成后，经过调用 queueBuffer（）将缓冲区返回到 App 对应的 BufferQueue(若是是 gpu 渲染的话，这里还有个 gpu 处理的过程，因此这个 Buffer 不会立刻可用，须要等 GPU 渲染完成)
SurfaceFlinger 在收到 Vsync 信号以后，开始准备合成，使用 acquireBuffer（）获取 App 对应的 BufferQueue 中的 Buffer 并进行合成操做
合成结束后，SurfaceFlinger 将经过调用 releaseBuffer（）将 Buffer 返回到 App 对应的 BufferQueue

知道了 Buffer 流转的过程，下面须要说明的是，在目前的大部分系统上，每一个应用都有三个 Buffer 轮转使用，来减小因为 Buffer 在某个流程耗时过长致使应用无 Buffer 可用而出现卡顿状况

下图是双 Buffer 和三 Buffer 的一个对比图

三个 Buffer 的好处以下

缓解掉帧 :从上图 Double Buffer 和 Triple Buffer 的对比图能够看到，在这种状况下（出现连续主线程超时），三个 Buffer 的轮转有助于缓解掉帧出现的次数（从掉帧两次 -> 只掉帧一次）。，App 主线程超时不必定会致使掉帧，因为 Triple Buffer 的存在，部分 App 端的掉帧(主要是因为 GPU 致使)，到 SurfaceFlinger 这里未必是掉帧，这是看 Systrace 的时候须要注意的一个点
减小主线程和渲染线程等待时间 ：双 Buffer 的轮转，App 主线程有时候必需要等待 SurfaceFlinger(消费者)释放 Buffer 后，才能获取 Buffer 进行生产，这时候就有个问题，如今大部分手机 SurfaceFlinger 和 App 同时收到 Vsync 信号，若是出现 App 主线程等待 SurfaceFlinger(消费者)释放 Buffer，那么势必会让 App 主线程的执行时间延后
下降 GPU 和 SurfaceFlinger 瓶颈 ：这个比较好理解，双 Buffer 的时候，App 生产的 Buffer 必需要及时拿去让 GPU 进行渲染，而后 SurfaceFlinger 才能进行合成，一旦 GPU 超时，就很容易出现 SurfaceFlinger 没法及时合成而致使掉帧；在三个 Buffer 轮转的时候，App 生产的 Buffer 能够及早进入 BufferQueue，让 GPU 去进行渲染（由于不须要等待，就算这里积累了 2 个 Buffer，下下一帧才去合成，这里也会提前进行，而不是在真正使用以前去匆忙让 GPU 去渲染），另外 SurfaceFlinger 自己的负载若是比较大，三个 Buffer 轮转也会有效下降 dequeueBuffer 的等待时间

坏处就是 Buffer 多了会占用内存

这部分详细的流程能够看 Android Systrace 基础知识 - Triple Buffer 解读这篇文章

系统机制 - Input 流程

Android 系统是由事件驱动的，而 input 是最多见的事件之一，用户的点击、滑动、长按等操做，都属于 input 事件驱动，其中的核心就是 InputReader 和 InputDispatcher。InputReader 和 InputDispatcher 是跑在 SystemServer 里面的两个 Native 线程，负责读取和分发 Input 事件，咱们分析 Systrace 的 Input 事件流，首先是找到这里。

InputReader 负责从 EventHub 里面把 Input 事件读取出来，而后交给 InputDispatcher 进行事件分发
InputDispatcher 在拿到 InputReader 获取的事件以后，对事件进行包装和分发 (也就是发给对应的)
OutboundQueue 里面放的是即将要被派发给对应 AppConnection 的事件
WaitQueue 里面记录的是已经派发给 AppConnection 可是 App 还在处理没有返回处理成功的事件
PendingInputEventQueue 里面记录的是 App 须要处理的 Input 事件，这里能够看到已经到了应用进程
deliverInputEvent 标识 App UI Thread 被 Input 事件唤醒
InputResponse 标识 Input 事件区域，这里能够看到一个 Input_Down 事件 + 若干个 Input_Move 事件 + 一个 Input_Up 事件的处理阶段都被算到了这里
App 响应 Input 事件：这里是滑动而后松手，也就是咱们熟悉的桌面滑动的操做，桌面随着手指的滑动更新画面，松手后触发 Fling 继续滑动，从 Systrace 就能够看到整个事件的流程

上面流程对应的 Systrace 以下

这部分详细的流程能够看 Android Systrace 基础知识 - Input 解读这篇文章

系列文章

附件

附件已经上传到了 Github 上，能够自行下载：github.com/Gracker/Sys…

xiaomi_launcher.zip : 桌面滑动卡顿的 Systrace 文件，此次案例主要是分析这个 Systrace 文件
xiaomi_launcher_scroll_all_the_time.zip : 桌面一直按着滑动的 Systrace 文件
oppo_launcher_scroll.zip ：对比文件

关于我 && 博客

关于我 , 很是但愿和你们一块儿交流 , 共同进步 .
博客内容导航
优秀博客文章记录 - Android 性能优化必知必会

一我的能够走的更快 , 一群人能够走的更远

Systrace 流畅性实战 1 ：了解卡顿原理

了解卡顿原理

卡顿现象及影响

卡顿定义

应用一帧渲染的总体流程

从执行顺序的角度来看

从 Systrace 的角度来看

卡顿定义

系统运行机制简介

系统机制 - App 主线程运行原理

系统机制 - Message 机制

系统机制 - 屏幕刷新机制 和 Vsync

系统机制 - Choreographer

系统机制 - Buffer 流程和 TripleBuffer

系统机制 - Input 流程

系列文章

附件

关于我 && 博客

系统机制 - 屏幕刷新机制和 Vsync