在Android 中的卡顿丢帧原因概述 - 应用篇这篇文章中我们列举了应用自身原因导致的手机卡顿问题 ， 这一篇文章我们主要列举一些由 Android 平台自身原因导致的卡顿问题. 各大国内 Android 厂商的产品由于硬件性能有高有低 ， 功能实现各有差异 ， 团队技术能力各有千秋 ， 所以其系统的质量也有高有低 ， 这里我们就来列举一下 ， 由于系统的硬件和软件原因导致的性能问题.
Android 手机使用中的卡顿问题 ， 一般来说手机厂商和 App 开发商都会非常重视 ， 所以不管是手机厂商还是 App 开发者 ， 都会对卡顿问题非常重视 ， 内部一般也会有专门的基础组或者优化组来进行优化 . 目前市面上有一些非常棒的第三方性能监控工具 ， 比如腾讯的 Matrix ; 手机厂商一般也会有自己的性能监控方案 ， 由于可以修改源码和避免权限问题 ， 所以手机厂商可以拿到更多的数据 ， 分析起来也会更方便一些.
说回流畅度 ， 其实就是操作过程中的丢帧 ， 本来一秒中画面需要更新 60 帧，但是如果这期间只更新了 55 帧 ， 那么在用户看来就是丢帧了 ， 主观感觉就是卡了 ， 尤其是帧率波动 ， 用户的感知会更明显. 引起丢帧的原因非常多， 有硬件层面的 ， 有软件层面的 ， 也有 App 自身的问题. 所以这一部分我分为四篇文章去讲 ， 会简单讲一下哪些原因会用户觉得卡顿丢帧 :
0. Android 中的卡顿丢帧原因概述 - 方法论
1. Android 中的卡顿丢帧原因概述 - 系统篇
2. Android 中的卡顿丢帧原因概述 - 应用篇
3. Android 中的卡顿丢帧原因概述 - 低内存篇
Android 平台性能导致的性能案例
下面我会列出来一些实际的卡顿案例 ， 这些导致卡顿的原因都是由于 Android 系统平台的一些问题导致的 ， 有些问题在开发阶段就会暴露出来 ， 这一类通常会在发给用户之前就解决掉 ; 有些问题是用户在长时间使用之后才会暴露出来 ， 这一类问题最多 ， 但是也比较难以解决 ; 还有一些问题 ， 只有非常特殊的场景或者特殊的硬件才会暴露出来 .
这些实际的案例 ， 很多都可以在 Systrace 上看出来 ， 所以我的很多贴图都是 Systrace 上实际被发现的问题 ， 如果你对 Systrace 不了解 ， 可以查看这个 Systrace 系列 ， 这里你只需要知道 ， 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 跑到了小核， 导致这一帧执行时间过长，造成卡顿图片:
如下图 ， 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 的使用情况
主线程调度不到 ， 处于 Runnable 状态
当线程为 Runnable 状态的时候 ， 调度器如果迟迟不能对齐进行调度 ， 那么就会产生长时间的 Runnable 线程状态 ， 导致错过 Vsync 而产生流畅性问题.
无关进程活跃耗时
无关进程通常是人为定义的 ， 指的是与当前前台 App 运行无关的进程 ， 这些活跃进程势必会对 App 主线程的调度产生影响 ， 不管这些无关进程是系统的还是 App 自身的 ， 或者是其他三方 App 的.
cpu 被占用
原因同上 ， 当后台任务过多的时候 ， cpu 资源就会异常紧缺 ， 如下图就是在系统低内存的时候 ， HeapTask 和 kswapD 几乎占满了整个 cpu ， 在疯狂地向系统申请内存 .
System 锁
system_server 的 AMS 锁和 WMS 锁 ， 在系统异常的情况下 ， 会变得非常严重 ， 如下图所示 ， 许多系统的关键任务都被阻塞 ， 等待锁的释放 ， 这时候如果有 App 发来的 Binder 请求带锁 ， 那么也会进入等待状态 ， 这时候 App 就会产生性能问题 ; 如果此时做 Window 动画 ， 那么 system_server 的这些锁也会导致窗口动画卡顿
8.Layer过多导致 SurfaceFlinger Layer Compute 耗时
Android P 修改了 Layer 的计算方法 ， 把这部分放到了 SurfaceFlinger 主线程去执行， 如果后台 Layer 过多， 就会导致 SurfaceFlinger 在执行 rebuildLayerStacks 的时候耗时 ， 导致 SurfaceFlinger 主线程执行时间过长.
所以在使用 Android 系统的时候 ， 记得多用多任务清理后台任务.
9.Input 报点不均匀
如果出现 Input 报点不均匀或者没有报点的情况， 那么主线程由于没有收到 Input 事件， 所以不去做绘制， 也会导致卡顿
如下图 ， 这是一个连续滑动的 Systrace 图 ， 最下面两行是 InputReader 和 InputDispatcher ， 可以看到在滑动的过程中， InputReader 和 InputDispatcher 没有读出来 Input 事件， 导致卡顿
10.LMK 频繁工作抢占 cpu
LMK 工作时， 会占用 cpu 资源 ， 其表现主要有下面几点
- CPU 资源 : 由于 LMK 杀掉的进程通常都是一些 Cache 或者 Service ， 这些进程由于低内存被杀之后 ， 通常会很快就被其主进程拉起来， 然后又被 LMK 杀掉， 从而进入了一种循环. 由于起进程是一件很消耗 cpu 的操作， 所以如果后台一直有进程被杀和重启， 那么前台的进程很容易出现卡顿
- Memory : 由于低内存的原因， 很容易触发各个进程的 GC ， 如下图的 CPU 状态可以看到， 用于内存回收的 HeapTaskDeamon 出现非常频繁
- IO : 低内存会导致磁盘 IO 变多， 如果频繁进行磁盘 IO ， 由于磁盘IO 很慢， 那么主线程会有很多进程处于等 IO 的状态， 也就是我们经常看到的 Uninterruptible Sleep
11.低内存导致 IO 耗时
低内存情况下， 很容易出现主线程 IO 从而导致应用卡顿
主线程 IO 导致卡顿
主线程 IO 导致应用启动速度慢
滑动列表时候 IO 导致卡顿
12.GPU 合成导致 SurfaceFlinger 耗时
当 SurfaceFlinger 有 GPU 合成时， 其主线程的执行时间就会变长， 也会导致合成不及时而卡顿
13.KSWAPD 跑大核
低内存时， kswapd 由于负载比较高 ， 其 cpu 占用比较高， 且经常会跑到大核上 ， 导致机器发热限频， 或者抢占主线程的 cpu 时间片
14.SurfaceFlinger Vsync 不均匀
SurfaceFlinger 有时候会出现 Vsync 不均匀的情况， 不均匀指的是 Vsync 间隔会持续地变化， 一会大一会小， 就会导致用户看到的画面不均匀， 有卡顿感
如下图 ， 可以明显看到 SurfaceFlinger 的 VSYNC-sf 这一行间隔是不一样的. 这种问题一般是由于 SurfaceFlinger 这边的修改或者 HWC 的修改导致的 .
15.三方应用使用 Accessibility 服务导致系统卡顿
三方应用如果使用 Accessibility 服务监听了 Input 事件的话， InputDispatcher 的行为就会与预期的出现偏差， 导致 InputDispatcher 没有及时把事件传给主线程导致卡顿
总结
Android 原生系统是一个不断进化的过程 ， 目前已经进化到了 Android Q ， 每个版本都会解决非常多的性能问题 ， 同时也会引进一些问题 ; 到了手机厂商这里 ， 由于硬件差异和软件定制 ， 会在系统中加入大量的自己的代码 ， 这无疑也会影响系统的性能 .
上面列出的这些影响流畅性的案例 ， 只是 Android 系统开发中遇到的性能问题的冰山一角 ， 任何一个问题都会对用户的使用产生影响 ， 这也是为什么手机厂商越来越重视系统优化 . 手机厂商非常重视开发过程中和用户使用过程中遇到的性能问题 ， 并开发和提出各项优化措施 ， 从硬件到软件 ， 从用户行为优化到系统策略动态学习 . 这也是为什么现在的手机厂商的系统越做越好 ， 质量越来越高的一个原因 ， 那些不重视质量只重视设计和产品的手机厂商 ， 都渐渐地被消费者淘汰了.
大家可以看看这个问题 : 当手机厂商说安卓手机性能优化的时候，他们到底在做什么
这也是流畅性的一个系列文章中的一篇 ， 可以点击下面的链接查看本系列的其他文章.
0. Android 中的卡顿丢帧原因概述 - 方法论
1. Android 中的卡顿丢帧原因概述 - 系统篇
2. Android 中的卡顿丢帧原因概述 - 应用篇
3. Android 中的卡顿丢帧原因概述 - 低内存篇
本文知乎地址
由于博客留言交流不方便，点赞或者交流，可以移步本文的知乎界面
知乎 - Android 中的卡顿丢帧原因概述 - 系统篇
关于我 && 博客
- 关于我 ， 非常希望和大家一起交流 ， 共同进步 .
- 博客内容导航
- 优秀博客文章记录 - Android 性能优化必知必会
一个人可以走的更快 ， 一群人可以走的更远
