Android 手机使用中的卡顿问题, 一般来说手机厂商和 App 开发商都会非常重视, 所以不管是手机厂商还是 App 开发者, 都会对卡顿问题非常重视, 内部一般也会有专门的基础组或者优化组来进行优化 .
目前市面上有一些非常棒的第三方性能监控工具, 比如腾讯的 Matrix ; 手机厂商一般也会有自己的性能监控方案, 由于可以修改源码和避免权限问题, 所以手机厂商可以拿到更多的数据, 分析起来也会更方便一些.
说回流畅度, 其实就是操作过程中的丢帧, 本来一秒中画面需要更新 60 帧,但是如果这期间只更新了 55 帧, 那么在用户看来就是丢帧了, 主观感觉就是卡了, 尤其是帧率波动, 用户的感知会更明显. 引起丢帧的原因非常多, 有硬件层面的, 有软件层面的, 也有 App 自身的问题. 所以这一部分我分为四篇文章去讲, 会简单讲一下哪些原因会用户觉得卡顿丢帧 :
0. Android 中的卡顿丢帧原因概述 - 方法论
1. Android 中的卡顿丢帧原因概述 - 系统篇
2. Android 中的卡顿丢帧原因概述 - 应用篇
3. Android 中的卡顿丢帧原因概述 - 低内存篇
这篇文章的“先定位场景，再分 App/System/Kernel/Display 归因”的方法仍然适用，但工具入口需要更新：Systrace 应替换为 Perfetto/System Trace，掉帧判断优先看 Frame Timeline；MethodTrace/TraceView 应替换为 Android Studio CPU Profiler、sampled callstack、Perfetto custom trace section；MAT 只适合 Java heap 离线分析，内存压力要结合 Android Studio Memory Profiler、dumpsys meminfo、LMK/Vitals 和 Perfetto；线上趋势应看 Android Vitals、JankStats 或自研 APM，再把可疑场景回放到 Macrobenchmark FrameTimingMetric。
1. 流畅度相关工作内容概述
作为手机厂商优化组的一员, 我有必要在开始之前简单描述一下我们工作的流程 . 系统开发的过程中, 有很多引起 Android 卡顿的原因,但是用户和测试感受最直观的是正在使用的应用掉帧和不流畅 . 由于测试和用户没有办法直接确定卡顿的原因, 所以一般会直接将 Bug 提到我们这边, 所以我们的角色更像是一个卡顿问题接口人, 负责分析引起卡顿的原因, 再把 Bug 分配给对应的模块负责人去解决, 如框架 \ App \ 多媒体 \ Display \ BSP 等.
所以直接由我们来解决的问题并不是很多, 我们更多的时候是通过专门的分析工具, 结合源码来定位和分析问题, 最多使用的工具如下:
- Systrace\strace\ftrace : 从整个系统的层面来看问题的大致原因
- MethodTrace : 可以从进程的角度, 以详细调用栈的形式来显示
- Android Studio 的 Profile 工具
- MAT : 用来分析内存问题
- Log : LogReport 抓取或者录制的 Log, 里面包含大量的信息, 包括各种常规 Log (Main Log, System Log, Event Log, Kernel Log, Crash Log 等), 也包含了厂商自己加的一些 Log ( Power Log, Performance Log 等), 也包含事故发生时候的截图 \ 录制的视频等
- 复现视频
- 本地复现等
确定卡顿的根本原因, 这需要对 Android App 开发 \ Android Framework 知识 \ Display 知识 \ Linux Kernel 知识有一定的了解, 知道基本的工作流程, 并能熟练使用对应的工具, 区分不同的场景, 迅速找到问题的原因, 然后和相关模块的负责人一起讨论优化.
对于一些系统全局性的方案则需要与对应的模块负责人一起分析和解决, 必要的时候我们也会开发一些 Feature 来解决问题 .
2. 性能问题分析的一些工具和套路
应用卡顿问题的原因比较多, 在数据埋点还没有完善的情况下, 更多的依赖 Systrace 来从全局的角度来分析卡顿的具体原因:
- Systrace 分析
- 首先确认卡顿的 App
- 通过 App 的主线程和 SurfaceFlinger 的主线程信息可以确定卡顿的现场
- 分析 Systrace, Systrace 的分析需要一定的知识储备 : 需要知道 Systrace 每一个模块展示的内容是如何与用户感受到的内容相对应的 ; 需要知道 Systrace 上各个模块的交互式如何展示的 ; 需要知道 Binder 调用信息 ; 需要会看 Kernel 信息 (后续会继续完善 Systrace 系列)
1. 如果是 App 主线程耗时, 则分析 App 主线程的原因 ( 案例里有 App 的卡顿原因 )
2. 如果是 System 的问题, 则需要分析 System_Server \ SurfaceFlinger \ HWC \ CRTC \ CPU 等 ( 详细参考下面系统卡顿原因) - TraceView + 源码分析
- 使用 Systrace 确定原因后, 可以使用 TraceView 结合源码查看对应的代码逻辑, Android Studio 的 Profile 工具可以以进程为单位, 进行 Method 的 Profile, 可以打出非常详细的函数调用栈, 并且可以与 Systrace 相对应
- 源码分析可以使用 Android Studio 进行断点调试 App 或者 Framework, 观察 Debug 信息是否与预期相符
- 很多问题也需要借助 Log 工具抓上来的 Log 进行分析, Log 分析 Log 里面一些比较重要的点 (一般从 Log 里面很难确定卡顿的原因, 但是可以结合 Systrace 做一定的辅助分析)
- 截图 : 确定卡顿发生的时间点 \ 卡顿的界面 (如果没有尽量提供)
- dumpsys meminfo 信息
- dumpsys cpuinfo 信息
- “Slow dispatch” 和 “Slow delivery” Log 信息
- 卡顿发生的一段时间内的 EventLog, 还原卡顿时候用户的操作
- 本地尝试复现
- 可以录高速录像, 观察细节,如果必现,可以让测试这边提供录像.
- 过滤 Log, 找到卡顿时候的异常 Log
- 多抓几份 Systrace, 有助于确定原因
- 可以让测试提供 LogReport 中没有的一些信息, 来分析当时用户的手机的整体的状态.
- adb shell dumpsys activity oom
- adb shell dumpsys meminfo
- adb shell cat /proc/buddyinfo
- adb shell dumpsys cpuinfo
- adb shell dumpsys input
- adb shell dumpsys window
3. 通过性能数据数据分析
由于用户反馈的不确定性, 和内部测试的不完备性, 通过系统或者 App 的性能埋点数据来做分析, 是改进系统的一个好的方法 . 一方面不用用户主动参与, 一方面有大量的数据可以来做分析, 看趋势 .
目前国内各大手机厂商和 App 厂商基本都有自己的 APM 平台, 负责监控 App 或者系统的监控程度, 来做对应的优化方案, 比如腾讯的 Matrix 平台已经监控了下面这些内容, 其他的 App 厂商可以直接接入
手机厂商由于有代码权限, 所以可以采集到更多的数据, 比如 Kernel 相关的数据 : cpu 负载 \ io 负载 \ Memory 负载 \ FSync \ 异常监控 \ 温度监控 \ 存储大小监控 等, 每一个大项又都有几十个小项 . 所以可以监控的数据会非常多, 遇到问题也可以从多个技术指标去分析 . 这就需要在这方面经验非常丰富的团队, 去定义这些监控指标, 确定最终要收集那些信息, 收集上来的数据如何去分析等.
至于后续的优化工作, 就考验各个厂商的研发能力了, 正如伟琳在这篇文章:那些年，我们一起经历过的 Android 系统性能优化 所说, 目前能力比较强的手机厂商, 都在底层各个模块, 结合硬件做优化, 因为最后还是都是资源的分配 ; 而一些研发实力不是很强的厂商, 则重点还是围绕在根据场景分配资源.
4. 总结
这里简单概述了一下流畅性问题的一般分析思路和分析工具, 而且由于我的方向主要在 Framework 和 App, 所以很多东西都是从上层的角度来说的, 想必 Kernel 优化团队会有更好的角度和分析 .
各个厂商的优化大家可以看看这篇总结, 那些年，我们一起经历过的 Android 系统性能优化, 华米 OV 都有涉及, 下面摘录了一段总结, 大家可以看看
展望一下，这里想把手机厂商分为三类:
- 一类是苹果，自己研发芯片和核心元件，有自己的OS和生态；
- 二类是三星、华为，自己研发芯片和核心元件(当然华为和三星还是有所区别)，共享 Android OS 和生态，当然三星在本土化这一块做的是不如华为和其他 Top 厂商的；
- 三类是其他 Android 手机厂商，芯片和核心元件来自于不同供应商，共享 Android OS和生态；
从技术层面看:
- 苹果始终会是在性能的第一阵营，可以顺利推行从硬件到 OS 到 APP 级别的任何性能保障方案；
- 三星、华为属于第二阵营，可以实现芯片-OS层面的整合优化；
- 其他 Top Android 手机厂商差距不会太大，他们有多个不同的 SoC 供应商，方案有差异，非常芯片底层的地方，往往不会去涉及，更多是做纯软件层面的策略性的优化，有价值但是不容易形成壁垒，注意这个不容易形成壁垒指的是在 top 厂商中间，一些小的厂商往往还是心有余而力不足。不过还是很期待看到有更多的突破出现。
这也是流畅性的一个系列文章中的一篇, 可以点击下面的链接查看本系列的其他文章.
0. Android 中的卡顿丢帧原因概述 - 方法论
1. Android 中的卡顿丢帧原因概述 - 系统篇
2. Android 中的卡顿丢帧原因概述 - 应用篇
本文知乎地址
由于博客留言交流不方便，点赞或者交流，可以移步本文的知乎界面
知乎 - Android 中的卡顿丢帧原因概述 - 方法论
关于我 && 博客
下面是个人的介绍和相关的链接，期望与同行的各位多多交流，三人行，则必有我师!
- 博主个人介绍 ：里面有个人的微信和微信群链接。
- 本博客内容导航 ：个人博客内容的一个导航。
- 个人整理和搜集的优秀博客文章 - Android 性能优化必知必会 ：欢迎大家自荐和推荐 （微信私聊即可）
- Android性能优化知识星球 ： 欢迎加入，多谢支持～
一个人可以走的更快 , 一群人可以走的更远
