Android 中的卡顿丢帧原因概述 - 系统篇

在Android 中的卡顿丢帧原因概述 - 应用篇^[1]这篇文章中我们列举了应用自身原因导致的手机卡顿问题 , 这一篇文章我们主要列举一些由 Android 平台自身原因导致的卡顿问题. 各大国内 Android 厂商的产品由于硬件性能有高有低 , 功能实现各有差异 , 团队技术能力各有千秋 , 所以其系统的质量也有高有低 , 这里我们就来列举一下 , 由于系统的硬件和软件原因导致的性能问题.

Android 手机使用中的卡顿问题 , 一般来说手机厂商和 App 开发商都会非常重视 , 所以不管是手机厂商还是 App 开发者 , 都会对卡顿问题非常重视 , 内部一般也会有专门的基础组或者优化组来进行优化 . 目前市面上有一些非常棒的第三方性能监控工具 , 比如腾讯的 Matrix ; 手机厂商一般也会有自己的性能监控方案 , 由于可以修改源码和避免权限问题 , 所以手机厂商可以拿到更多的数据 , 分析起来也会更方便一些.

说回流畅度 , 其实就是操作过程中的丢帧 , 本来一秒中画面需要更新 60 帧,但是如果这期间只更新了 55 帧 , 那么在用户看来就是丢帧了 , 主观感觉就是卡了 , 尤其是帧率波动 , 用户的感知会更明显. 引起丢帧的原因非常多, 有硬件层面的 , 有软件层面的 , 也有 App 自身的问题. 所以这一部分我分为四篇文章去讲 , 会简单讲一下哪些原因会用户觉得卡顿丢帧 :

1. Android 中的卡顿丢帧原因概述 - 方法论^[2]

2. Android 中的卡顿丢帧原因概述 - 系统篇^[3]

3. Android 中的卡顿丢帧原因概述 - 应用篇^[4]

4. Android 中的卡顿丢帧原因概述 - 低内存篇^[5]

Android 平台性能导致的性能案例

下面我会列出来一些实际的卡顿案例 , 这些导致卡顿的原因都是由于 Android 系统平台的一些问题导致的 , 有些问题在开发阶段就会暴露出来 , 这一类通常会在发给用户之前就解决掉 ; 有些问题是用户在长时间使用之后才会暴露出来 , 这一类问题最多 , 但是也比较难以解决 ; 还有一些问题 , 只有非常特殊的场景或者特殊的硬件才会暴露出来 .

这些实际的案例 , 很多都可以在 Systrace 上看出来 , 所以我的很多贴图都是 Systrace 上实际被发现的问题 , 如果你对 Systrace 不了解 , 可以查看这个 Systrace 系列^[6] , 这里你只需要知道 , Systrace 从系统全局的角度 , 来展示当前系统的运行状况 , 通常被用来 Debug Android 性能问题 .

1.SurfaceFlinger 主线程耗时

SurfaceFlinger 负责 Surface 的合成 , 一旦 SurfaceFlinger 主线程调用超时 , 就会产生掉帧 .

SurfaceFlinger 主线程耗时会也会导致 hwc service 和 crtc 不能及时完成, 也会阻塞应用的 binder 调用, 如 dequeueBuffer \ queueBuffer 等.

下图中的 SurfaceFlinger 主线程在后半部分明显超时:

SurfaceFlinger 主线程处理不及时导致应用卡顿(第一帧卡顿,后续都为黄帧)

2.屏下光感截图导致 SurfaceFlinger 渲染不及时

有的 Android 机型使用了屏下光感 , 屏下光感的实现方法也会影响 SurfaceFlinger 主线程的运行 . 屏下指纹需要频繁截图 , 来区分光线和屏幕的变化 , 进行对应的亮度变化, 但是其主线程截图的方法会导致 SurfaceFlinger 主线程被截图操作所耽误, 从而导致卡顿

3.WHC Service 执行耗时

hwc Service 耗时也会导致 SurfaceFlinger 下一帧不会做合成操作, 导致应用的 dequeueBuffer 和 setTransationState 方法被阻塞, 导致卡顿. 如下图, 可以看到 SurfaceFlinger 的掉帧情况, Binder 的阻塞情况 和 CRTC 的耗时情况

hwc 耗时

crtc 等待 hwc

4.CRTC 执行耗时

crtc 执行耗时的结果就是 SurfaceFlinger 下一帧不会做合成操作, 导致应用的 dequeueBuffer 和 setTransationState 方法被阻塞, 导致卡顿. 如下图, 可以看到 SurfaceFlinger 的掉帧情况, Binder 的阻塞情况 和 CRTC 的耗时情况

5.CPU 调度问题

重要任务跑小核性能不足导致卡顿

如下图 , RenderThread 跑到了小核, 导致这一帧执行时间过长,造成卡顿图片:

RenderThread 跑小核

如下图 , cpu 频率对性能的影响

优先级低未能及时获取 cpu 时间片导致卡顿

在调度器看来的低优先级任务 , 在用户这里未必是低优先级任务 , 他可能正在和 App 的主线程交互 , 或者正在和 system_server 进行交互

被 RT 进程抢占

App 主线程或者渲染线程被 RT 进程抢占也会导致系统卡顿或者响应慢 , Google 也意识到了这个问题 , 也在尝试在应用启动的时候 , 把 App 主线程和渲染线程的优先级也设置为 RT , 不过这个属性一直没开 , 因为会导致应用启动速度变慢.

大小核调度导致

大小核调度的问题通常表现在该跑在大核的任务跑到了小核 , 或者该在小核运行的任务却持续跑到大核 ,或者错误的被绑定在了某一个核心上 .

如下图, 这是一个 CTS 问题, CTS 主线程由于被绑定到了 cpu7 , 由于 cpu7 在执行 RenderThread , 所以主线程没有调度到, 导致 CTS 失败

大小核调度

6.触发 Thermal 导致限频

触发 Thermal 发热限频也有可能导致卡顿 , 这算是一种硬件级别的保护 , 如果手机已经过热 , 此时如果不进行干涉 , 那么可能会导致用户手机太烫而无法持续使用手机. 一般这个时候都会对系统的资源进行一些限制 , 比如降低 cpu\gpu 的最高频率之类的 , 这么做的话 , 势必也会对流畅性造成影响.

如果你手机非常热 , 而且变卡了 , 那么放下手机休息一会 , 查杀一下后台 , 或者重启一下手机 .

7.后台活动进程太多导致系统繁忙

后台进程活动太多,会导致系统非常繁忙, cpu \ io \ memory 等资源都会被占用, 这时候很容易出现卡顿问题 , 这也是系统这边经常会碰到的问题

CPU 繁忙

dumpsys cpuinfo 可以查看一段时间内 cpu 的使用情况

CPU 繁忙

主线程调度不到 , 处于 Runnable 状态

当线程为 Runnable 状态的时候 , 调度器如果迟迟不能对齐进行调度 , 那么就会产生长时间的 Runnable 线程状态 , 导致错过 Vsync 而产生流畅性问题.

Runnable

无关进程活跃耗时

无关进程通常是人为定义的 , 指的是与当前前台 App 运行无关的进程 , 这些活跃进程势必会对 App 主线程的调度产生影响 , 不管这些无关进程是系统的还是 App 自身的 , 或者是其他三方 App 的.

无关进程活跃耗时

cpu 被占用

原因同上 , 当后台任务过多的时候 , cpu 资源就会异常紧缺 , 如下图就是在系统低内存的时候 , HeapTask 和 kswapD 几乎占满了整个 cpu , 在疯狂地向系统申请内存 .

cpu 被占用

SystemServer 锁

system_server 的 AMS 锁和 WMS 锁 , 在系统异常的情况下 , 会变得非常严重 , 如下图所示 , 许多系统的关键任务都被阻塞 , 等待锁的释放 , 这时候如果有 App 发来的 Binder 请求带锁 , 那么也会进入等待状态 , 这时候 App 就会产生性能问题 ; 如果此时做 Window 动画 , 那么 system_server 的这些锁也会导致窗口动画卡顿

SystemServer 锁

8.Layer 过多导致 SurfaceFlinger Layer Compute 耗时

Android P 修改了 Layer 的计算方法 , 把这部分放到了 SurfaceFlinger 主线程去执行, 如果后台 Layer 过多, 就会导致 SurfaceFlinger 在执行 rebuildLayerStacks 的时候耗时 , 导致 SurfaceFlinger 主线程执行时间过长.

Layer 过多

所以在使用 Android 系统的时候 , 记得多用多任务清理后台任务.

9.Input 报点不均匀

如果出现 Input 报点不均匀或者没有报点的情况, 那么主线程由于没有收到 Input 事件, 所以不去做绘制, 也会导致卡顿 如下图 , 这是一个连续滑动的 Systrace 图 , 最下面两行是 InputReader 和 InputDispatcher , 可以看到在滑动的过程中, InputReader 和 InputDispatcher 没有读出来 Input 事件, 导致卡顿

Input 报点不均匀

10.LMK 频繁工作抢占 cpu

LMK 工作时, 会占用 cpu 资源 , 其表现主要有下面几点

1. CPU 资源 : 由于 LMK 杀掉的进程通常都是一些 Cache 或者 Service , 这些进程由于低内存被杀之后 , 通常会很快就被其主进程拉起来, 然后又被 LMK 杀掉, 从而进入了一种循环. 由于起进程是一件很消耗 cpu 的操作, 所以如果后台一直有进程被杀和重启, 那么前台的进程很容易出现卡顿

2. Memory : 由于低内存的原因, 很容易触发各个进程的 GC , 如下图的 CPU 状态可以看到, 用于内存回收的 HeapTaskDeamon 出现非常频繁

3. IO : 低内存会导致磁盘 IO 变多, 如果频繁进行磁盘 IO , 由于磁盘 IO 很慢, 那么主线程会有很多进程处于等 IO 的状态, 也就是我们经常看到的 Uninterruptible Sleep

Low Memory Low Memory

11.低内存导致 IO 耗时

低内存情况下, 很容易出现主线程 IO 从而导致应用卡顿

IO 耗时

主线程 IO 导致卡顿

IO 耗时

主线程 IO 导致应用启动速度慢

主线程 IO 主线程 IO

滑动列表时候 IO 导致卡顿

滑动列表时候 IO 导致卡顿

12.GPU 渲染导致 SurfaceFlinger 耗时

当 SurfaceFlinger 有 GPU 渲染时, 其主线程的执行时间就会变长, 也会导致合成不及时而卡顿

GPU 渲染导致 SurfaceFlinger 耗时 GPU 渲染导致 SurfaceFlinger 耗时

13.KSWAPD 跑大核

低内存时, kswapd 由于负载比较高 , 其 cpu 占用比较高, 且经常会跑到大核上 , 导致机器发热限频, 或者抢占主线程的 cpu 时间片

KSWAPD 跑大核

14.SurfaceFlinger Vsync 不均匀

SurfaceFlinger 有时候会出现 Vsync 不均匀的情况, 不均匀指的是 Vsync 间隔会持续地变化, 一会大一会小, 就会导致用户看到的画面不均匀, 有卡顿感 如下图 , 可以明显看到 SurfaceFlinger 的 VSYNC-sf 这一行间隔是不一样的. 这种问题一般是由于 SurfaceFlinger 这边的修改或者 HWC 的修改导致的 .

SurfaceFlinger Vsync 不均匀

15.三方应用使用 Accessibility 服务导致系统卡顿

三方应用如果使用 Accessibility 服务监听了 Input 事件的话, InputDispatcher 的行为就会与预期的出现偏差, 导致 InputDispatcher 没有及时把事件传给主线程导致卡顿

Accessibility 服务导致系统卡顿

总结

Android 原生系统是一个不断进化的过程 , 目前已经进化到了 Android R , 每个版本都会解决非常多的性能问题 , 同时也会引进一些问题 ; 到了手机厂商这里 , 由于硬件差异和软件定制 , 会在系统中加入大量的自己的代码 , 这无疑也会影响系统的性能 .

上面列出的这些影响流畅性的案例 , 只是 Android 系统开发中遇到的性能问题的冰山一角 , 任何一个问题都会对用户的使用产生影响 , 这也是为什么手机厂商越来越重视系统优化 . 手机厂商非常重视开发过程中和用户使用过程中遇到的性能问题 , 并开发和提出各项优化措施 , 从硬件到软件 , 从用户行为优化到系统策略动态学习 . 这也是为什么现在的手机厂商的系统越做越好 , 质量越来越高的一个原因 , 那些不重视质量只重视设计和产品的手机厂商 , 都渐渐地被消费者淘汰了.

大家可以看看这个问题 : 当手机厂商说安卓手机性能优化的时候，他们到底在做什么^[7]

参考资料

[1]

Android 中的卡顿丢帧原因概述 - 应用篇: https://www.androidperformance.com/2019/09/05/Android-Jank-Due-To-App/

[2]

Android 中的卡顿丢帧原因概述 - 方法论: https://www.androidperformance.com/2019/09/05/Android-Jank-Debug/

[3]

Android 中的卡顿丢帧原因概述 - 系统篇: https://www.androidperformance.com/2019/09/05/Android-Jank-Due-To-System/

[4]

Android 中的卡顿丢帧原因概述 - 应用篇: https://www.androidperformance.com/2019/09/05/Android-Jank-Due-To-App/

[5]

Android 中的卡顿丢帧原因概述 - 低内存篇: https://www.androidperformance.com/2019/09/18/Android-Jank-Due-To-Low-Memory/

[6]

Systrace 系列: https://www.androidperformance.com/2019/05/26/Android_Systrace_0/

[7]

当手机厂商说安卓手机性能优化的时候，他们到底在做什么: https://www.zhihu.com/question/335226118/answer/751587534