希望本文能给大家一个相对全局的视角来看待卡顿问题，认识到卡顿是什么，卡顿的原因，卡顿的分类，卡顿的优化和一些经验积累，有针对性地解决App流畅性问题。接下来，将从以下五个方面来讲述：

卡顿是什么？

为什么会这样？

如何评价卡顿

如何优化卡顿

加入我们

1. 什么是卡顿

滞后，顾名思义，用户体感界面不流畅。我们知道手机屏幕以一定的频率刷新。理论上，24帧的更新应该会让人眼感觉连贯。但实际上，这只是一般的视频。对于高度互动或敏感的场景，如游戏，至少需要60帧，30帧的游戏是不舒服的。平移或大尺度动画30帧会有明显的挫败感；如果手部动画能达到90帧甚至120帧，会让人感觉非常细腻，这也是最近厂家主打高刷品牌的原因。

对于用户来说，从体感的角度来看，caton大致可以分为以下几类：

这些体验对用户来说是非常糟糕的，甚至会引起感官上的烦躁，让用户不愿意留在我们的App中。可以说，流畅的体验对用户来说至关重要。

造成用户运动感觉失速的原因有很多，往往是一个复合问题。为了对焦，这里只考虑真正意义上的帧降失速。

我们通常说屏幕的刷新率是60帧，并且所有的事情都需要在16ms内完成，以免造成拖延。但有几个基本问题需要弄清楚：

为什么16女士？在16毫秒内需要做什么？系统如何确保任务在16毫秒内完成？如果没有在16ms内完成，一定会造成延迟吗？为了回答第一个问题：为什么是16毫秒？在Android的早期，没有垂直同步机制，CPU和GPU的协调相当混乱。这也造成了著名的撕裂问题，即CPU/GPU直接更新了显示的屏幕缓冲区，造成撕裂。后来，Android引入了双缓冲机制，但缓冲开关也需要很好的时间，在屏幕扫描完最后一帧之后，这就是为什么引入了垂直同步。

通常的屏幕刷新率是60FPS，所以每个垂直同步信号间隔也是16ms，但随着技术的变化和制造商追求平滑，越来越多的90fps和120fps手机出现了，所以间隔变成了11ms和8ms。

现在VSYNC可用，谁在使用VSYNC?实际上，Android有两个VSYNC消费者，对应两种VSYNC信号，即VSYNC -app和VSYNC - sf，分别对应上层视图渲染和surfaceFlinger合成。我们将在下面讨论细节。

这里也有一些有趣的地方。一些制造商将有垂直同步偏移设计。App和sf的垂直同步信号之间存在偏移，这也在一定程度上使得App和sf之间的协同效果更好。

在我们进入下一部分之前，让我们先介绍一个话题：

视图究竟是如何出现在屏幕上的？

我们通常理解渲染视图的三个主要过程，但渲染视图远不止于此：

这里用一般的硬件加速过程来表示

垂直同步调度：很多同学的一个误解是，垂直同步每16ms可用一次，但实际上，垂直同步需要调度，没有调度，就没有回调；消息调度：主要是doframe消息调度，如果消息被阻塞，将直接造成延迟；输入处理：处理触摸事件；动画：动画师动画执行与渲染；视图处理：主要有视图相关遍历和三个过程；实施三个过程：测量、布置和绘制：查看；显示列表更新：视图硬件加速绘制op;OpenGL指令转换：绘制指令转换为OpenGL指令；指令缓冲区交换：OpenGL的指令交换到GPU内部执行；GPU处理：由GPU进行数据处理；层合成：表面缓冲合成画面显示缓冲过程；栅格化：将矢量图像转换为位图；显示：显示控制；缓冲开关：切换画面上显示的帧缓冲区；谷歌将此过程分为：其他时间/VSync延迟、输入处理、动画、测量/布局、绘图、同步和上传、命令问题和交换缓冲区。这是我们经常使用的GPU严格模式，但原理是一样的。这就引出了第二个问题：在16毫秒内需要做什么？

确切地说，还可以进一步细化：APP端数据制作可以在16ms内完成；sf层在16ms内合成

View的视觉效果是通过这整个复杂的环节一步步展现出来的。在这个前提下，可以得出结论，上述任何一个链接都会导致死锁。

0

更具体地说，生产者大致可以分为两类，一类是以窗口为代表的页面，也就是我们通常看到的视图树集；另一种是视频流，可以直接与表面完成数据交换，如摄像头预览。

对于一般的生产者和消费者模型，我们知道存在相互阻塞的问题。比如生产者的速度快而消费者的速度慢，或者生产者的速度慢而消费者的速度快，都会导致整体速度慢，造成资源的浪费。因此，垂直同步和双倍甚至三倍缓冲的协同作用开始发挥作用。

考虑一下这个问题：缓冲越多越好吗？过多的缓冲有什么问题？答案是，它造成了另一个严重的问题：滞后，延迟响应

在这里，结合life of view，我们可以把这两个过程结合在一起，让我们的视角更上一层楼：

现在我们来回答第三个问题。从系统的渲染架构来看，机械保护主要有几个方面：

垂直同步机制的协调；Multi-buffer设计；表面的提供；同步屏障保护；硬件渲染支持；渲染线程支持；GPU合成加速；这些机械保护在系统层面上最能确保App的流畅体验，但它们并不能帮助我们彻底解决问题。为了提供更流畅的体验，一方面可以加强系统机制保护，如FWatchDog;另一方面，我们需要从App的角度出发来处理卡在应用中的问题。

经过以上讨论，我们得出了卡顿分析的一个核心理论支撑：渲染机制中任何异常的流动过程都会引起卡顿。

那么，让我们来看看每一个可能的失速原因。

2. 为什么会发生卡顿

垂直同步调度：这是起点，但是调度过程中会经过线程切换和一些委托逻辑，可能会有延迟，但一般可能性比较小，我们基本无法介入；消息调度：主要是doframe消息调度，这是一种常见的Handler调度。如果调度被其他消息阻塞而导致延迟，则不会直接触发所有后续进程。这里建立了一种用于直播的FWtachDog机制，通过优化消息调度来达到插入帧的效果，使界面更加流畅。输入处理：输入是Vsync调度执行的第一个逻辑，它处理输入事件。如果累积了大量的事件，或者在事件分发逻辑中加入了大量耗时的业务逻辑，将会延长当前帧的持续时间，造成延迟。抖音基础技术的同学也尝试了事件采样的程序，减少了事件的处理，取得了很好的效果。动画处理：主要是动画师动画的更新。同样，过多的动画或动画更新中耗时的逻辑也会导致当前帧的渲染滞后。减少动画帧数和复杂度实际上就是解决这个问题；视图处理：主要是接下来的三个进程，透支，频繁刷新，复杂的视图效果是这里延迟的主要原因。比如我们平时说的降低页面的层次，主要解决的就是这个问题；measure/layout/draw:视图渲染的三个过程，因为涉及遍历和高频执行，所以这里涉及到的耗时问题会被放大，比如我们在draw中不会调用耗时的函数，不能新建对象等等；DisplayList的更新：这主要是canvas和DisplayList的映射。一般不会出现延迟问题，但可能会出现映射失败导致的显示问题。OpenGL指令转换：这主要是将canvas命令转换为OpenGL指令，一般没有问题。然而，这里有一点值得探讨。是否有一个特殊的画布指令消耗大量转换的OpenGL指令，从而导致GPU消耗？有理解的学生可以讨论；缓冲区交换：这是指将OpenGL指令集交换给GPU，这一般取决于指令的复杂程度。一个有趣的事情是，它曾经被用作在线采集GPU指标的数据源，但由于多个缓冲因素导致数据准确性不足而被放弃；GPU处理：顾名思义，这是GPU对数据的处理。其耗时主要与任务数量和纹理复杂度有关。这就是为什么我们减少GPU负载以帮助减少延迟；图层合成：这里主要是图层合成的工作，这是一般难以接近的。偶尔，sf同步信号被发现延迟，导致缓冲区供应延迟。原因尚不清楚。栅格化/显示：暂时忽略底层系统行为；缓冲区切换：这主要是屏幕的显示，其中缓冲区的数量也会影响帧的整体延迟，但这是系统行为，不应该受到干扰。除了前面提到的导致延迟的渲染流之外，还有其他因素，通常是视频流。

渲染延迟：TextureView主要用于渲染。Textureview与window共享一个表面，每个帧都需要协同渲染并相互交互。UI延迟可能导致视频流延迟，而视频流延迟有时也可能导致UI延迟。解码：解码主要是将数据流解码成表面可消费的缓冲区数据，这是网络外最重要的耗时点。现在我们一般使用硬溶液，性能比软溶液高得多。但是，帧复杂度、编码算法复杂度、分辨率等，都会直接导致解码时间拉长；OpenGL处理：有时要对解码后的数据做二次处理，如果这样耗时会直接导致渲染滞后；网络：这不会重复，包括DNS节点优化，cdn服务，GOP配置等。推流异常：这是数据源的问题。在这里，用户端视图是主要的，暂时不讨论它。2.5.3系统负载

内存：内存紧张会直接导致GC甚至ANR的增加，这是一个不容忽视的因素。CPU: CPU对时延的影响主要体现在帧速率上

以vsync到达时间为起点，以doFrame执行完成事件为终点，以doFrame完成事件为每一帧的渲染时间。同时，利用渲染时间/刷新率计算每次渲染丢失的帧数。平均FPS=一个周期内渲染帧数* 60 /(渲染帧数和丢失帧数)

vsync

stall_video_ui_rate

总滞留率

(UI卡长度立即流卡长度立即)/收集持续时间

vsync

stall_ui_rate

粘滞率

[3帧]UI瞬间长度/收集持续时间

vsync

stall_video_rate

流量

流卡时长/收款时长

vsync

stall_ui_slight_rate

轻微滞留率

[3-6]丢帧时间/采集时间

vsync

stall_ui_moderate_rate

中等保持率

[7-13]丢帧时间/采集时间

vsync

stall_ui_serious_rate

严重的紧张症

[14]丢帧时间/采集时间

vsync

Diggo是Byte公司开发的开放式开发调试工具平台。是集“评估、分析、调试”为一体的一站式工具平台。内置性能评估、接口分析、滞后分析、内存分析、崩溃分析、实时调试等基础分析功能，可为产品开发阶段提供强有力的帮助。

2.1 绕不开的 VSYNC

2.2 View 颠沛流离的一生

2.3 生产者和消费者

2.4 机制上的保护

这主要是针对UI延迟和UI/流交互称为延迟。

离线代码；减少执行死刑的次数；异步的；分手：分手；预热；重用；方案优化；硬件加速；总的思路是“尽量少做，尽量少做，尽可能早做，尽可能早做，尽可能晚做，让别人做你能做的，尽可能做一次10次，然后考虑自己做一件大事。”

下面是一些常见的优化思路。请注意，这绝不是全部。如果还有其他好的优化思路，我们可以一起交流。

直播是一个长期的SurfaceView切换专项项目，分多个阶段逐步实现全SurfaceView直播，场景涵盖秀场直播、聊天室直播、游戏直播、电商直播、媒体直播等。在业务方面，这对渗透和停留时间有显著的好处，对功耗也有相当大的好处。

这里有一个权衡问题，SurfaceView兼容性问题pk收益可以是偶数，一般来说，业务场景越复杂，收益越大。

2.5 再看卡顿的成因

FWatchDog基于MessageQueue调度策略和同步屏障原理。Fwatchdog以平均帧时间作为阈值，在确定丢帧后主动将同步barrier插入MessageQueue中，以保证异步消息和帧呈现的优先级。实现了渲染插入帧的效果，同时具有ANR自动恢复同步屏障的能力，保证了有效的色散。

所以FWatchDog和shatter是很好的搭档，可以产生1,1大于2的效果。

典型的应用场景是GC抑制滑动场景，可以显著改善用户的上下滑动体验。这个场景认为每一个业务都会存在，特别是有很多遍历逻辑，优化效果明显。

2.5.1 渲染流程

一些旧的框架，无用的逻辑和存在不高的代码可以脱机，这里的基本业务是强相关的，不给出具体的例子。

2.5.2 视频流

首先是分帧，直播做了很多任务的分帧和分帧，第一可以减少当前渲染帧的时间压力，第二可以结合FWatchDog来实现分帧的效果。实际上，任务的执行优先级是可以控制的，包括队列跳转等。简而言之，合理调度MessageQueue是必要的。

异步的使用也相对较多。带有嵌入式日志和一些加载模式的帧可以使用异步使用来解决阻塞问题。

3.2 线下指标

直播提供了一个预热框架，它可以让直播中的一次性成本逻辑有机会在主机端执行。它还提供完整的队列优先级管理、同步异步管理和任务生命周期管理，减少了直播中的第一个负载问题。

提升硬件运行性能，如CPU主频、GPU主频、线程绑定大核、网络相关调优，从底层提升App运行体验。

4. 如何优化卡顿

直播客户端技术团队是集体验优化、平台搭建、跨端、端到端智能化、稳定性于一体的综合性团队。团队氛围好，技术发展快，团队有足够的自由发挥自己的优势来保护DAU过亿级的产品，但也面临着更加多元化的挑战。每一行代码都会为数亿用户带来更好的体验!现在我们诚挚地邀请您加入我们。如果你对这些方向感兴趣，请过来聊天。