Android Performance

最近读了一本新书：《打造流畅的 Android App》，京东链接：https://item.jd.com/10035215362170.html 。因为书名所以买了这本书，读完之后觉得有必要写一篇文章，让还没有买此书的同学了解一下

我个人的建议是：如果你是个老鸟，不建议买，这本书里面没有介绍太多原理性的东西，对于 Android 流畅性也没有一个比较全面的介绍；如果你是新手，这本书用来当做开阔视野 + 查漏补缺还可以，想更深入的了解 Android 流畅度还是差了点东西

之所以我会这么建议，是因为这本书确实没有讲太多性能或者流畅度相关的东西，也没有比较深入的原理部分，篇幅更多在讲静态代码审查、AS Profiler 的使用、App 架构、保活、网络性能优化、APK 大小优化、App 耗电等，内容也不深，浅尝辄止

Android 12 源码于 2021 年发布，我当时用来折腾的测试机是 Pixel 3 XL。本文保留那次实操记录，并将可复现的发布版示例固定为 android-12.0.0_r3。版本对应关系以 AOSP tags/build numbers 为准。

本文介绍这条历史分支的下载、编译和刷机。本地编译便于查看/修改系统源码、增加调试信息，主要用途如下：

1. 可以刷真机，方便开发者进行本地 Debug，同时代码可以导入 Android Studio 进行 Debug
2. 可以编译 userdebug 版本以使用更多调试能力。adb root/remount 是否可用还取决于 adbd、AVB/verity、分区和构建配置；userdebug 不等于所有目录直接可写，也不代替应用自身的调试权限。
3. 可以更方便地进行 Android 源代码的学习，本地版本可以打开很多系统级别的 Debug Log，也可以自己加 Log，或者自己修改流程

在讨论 Android 性能问题的时候，卡顿、响应速度、ANR 常被放在一起。它们可能有共同原因，也可能同时出现，但不是按严重程度划分的三个等级。用户说“卡”，还需要分清是动画不连贯、操作后等得太久，还是系统触发了无响应判定。

动画或列表滚动的不连贯通常称为 Jank；应用启动、亮灭屏或场景切换耗时过长属于 响应慢（slow response / high latency）；ANR 则由具体的系统超时条件触发。掉帧率、启动耗时和 ANR 率各有测量口径，分析时要分开。

本文是响应速度系列的第三篇，主要是讲在使用 Systrace 分析应用响应速度问题的时候，其中的一些延伸知识，包括启动速度测试、Log 输出解读、Systrace 状态解读、三方启动库等内容

在讨论 Android 性能问题的时候，卡顿、响应速度、ANR 常被放在一起。它们可能有共同原因，也可能同时出现，但不是按严重程度划分的三个等级。用户说“卡”，还需要分清是动画不连贯、操作后等得太久，还是系统触发了无响应判定。

动画或列表滚动的不连贯通常称为 Jank；应用启动、亮灭屏或场景切换耗时过长属于 响应慢（slow response / high latency）；ANR 则由具体的系统超时条件触发。掉帧率、启动耗时和 ANR 率各有测量口径，分析时要分开。

本文是响应速度系列的第二篇，主要是以 Android App 冷启动为例，讲解如何使用 Systrace 来分析 App 冷启动

在讨论 Android 性能问题的时候，卡顿、响应速度、ANR 常会一起出现，部分原因也会重叠，但它们不是按严重程度划分的同一个问题。画面节奏异常、操作反馈延迟和具体超时机制触发的 ANR，需要分别确认。用户说“手机卡”或“App 卡”时，可以先把它当作宽泛的体验描述，再问清发生了什么、从哪个动作到哪个结果变慢。

动画播放或列表滑动不连贯，通常称为 Jank；应用启动、亮灭屏或场景切换耗时较长，可描述为 响应慢（slow response / high latency）；ANR 则是 Application Not Responding。这些说法帮助组织问题，不是互斥分类；高延迟也可能同时伴随卡顿，ANR 还要按具体触发类型分析。

另外在 App 或者厂商内部，卡顿、响应速度、ANR 这几个性能指标都是有单独的标准的，比如 掉帧率、启动速度、ANR 率等，所以针对这些性能问题的分析和优化能力，对开发者来说就非常重要了

本文是响应速度系列的第一篇，主要讲响应速度相关的理论知识，包括性能工程概述、响应速度涉及到的知识点，以及分析方法。

不同的人对流畅性(卡顿掉帧)有不同的理解，对卡顿阈值也有不同的感知，所以有必要在开始这个系列文章之前，先把涉及到的内容说清楚，防止出现不同的理解，也方便大家带着问题去看这几篇问题，下面是一些基本的说明

1. 对手机用户来说，卡顿包含了很多场景，比如在 滑动列表的时候掉帧、应用启动白屏过长、点击电源键亮屏慢、界面操作没有反应然后闪退、点击图标没有响应、窗口动画不连贯、滑动不跟手、重启手机进入桌面卡顿 等场景，这些场景跟我们开发人员所理解的卡顿还有点不一样，开发人员会更加细分去分析这些问题，这是开发人员和用户之间的一个认知差异，这一点在处理用户(或者测试人员)的问题反馈的时候尤其需要注意
2. 对开发人员来说，可以先按 流畅度（画面节奏不连贯）、响应速度（操作后等待过长）和 稳定性（崩溃、ANR 等）整理反馈。这些现象可能重叠；点击没有响应不一定是稳定性故障，需要结合输入、应用状态和日志进一步分类。
3. 技术上，这三类问题并不是同一个 Message 超时机制的不同阈值。主线程长任务会同时影响输入和绘制，但 GPU、SurfaceFlinger、显示链路、线程调度或远端服务也可能造成延迟。ANR 由具体输入/组件等超时规则触发，崩溃则另有异常或信号等原因；不能仅凭一次长 Message 判定它们。
4. 流畅性这个系列主要是分析流畅度相关的问题，响应速度和稳定性会有专门的文章介绍，在理解了流畅性相关的内容之后，再去分析响应速度和稳定性问题会事半功倍
5. 流畅性这个系列主要是讲如何使用 Systrace (Perfetto) 工具去分析，之所以 Systrace 为切入点，是因为影响流畅度的因素很多，有 App 自身的原因、也有系统的原因。而 Systrace(Perfetto) 工具可以从一个整机运行的角度来展示问题发生的过程，方便我们去初步定位问题

不同的人对流畅性(卡顿掉帧)有不同的理解，对卡顿阈值也有不同的感知，所以有必要在开始这个系列文章之前，先把涉及到的内容说清楚，防止出现不同的理解，也方便大家带着问题去看这几篇问题，下面是一些基本的说明

1. 对手机用户来说，卡顿包含了很多场景，比如在 滑动列表的时候掉帧、应用启动白屏过长、点击电源键亮屏慢、界面操作没有反应然后闪退、点击图标没有响应、窗口动画不连贯、滑动不跟手、重启手机进入桌面卡顿 等场景，这些场景跟我们开发人员所理解的卡顿还有点不一样，开发人员会更加细分去分析这些问题，这是开发人员和用户之间的一个认知差异，这一点在处理用户(或者测试人员)的问题反馈的时候尤其需要注意
2. 对开发人员来说，可以先按 流畅度（画面节奏不连贯）、响应速度（操作后等待过长）和 稳定性（崩溃、ANR 等）整理反馈。这些现象可能重叠；点击没有响应不一定是稳定性故障，需要结合输入、应用状态和日志进一步分类。
3. 技术上，这三类问题并不是同一个 Message 超时机制的不同阈值。主线程长任务会同时影响输入和绘制，但 GPU、SurfaceFlinger、显示链路、线程调度或远端服务也可能造成延迟。ANR 由具体输入/组件等超时规则触发，崩溃则另有异常或信号等原因；不能仅凭一次长 Message 判定它们。
4. 流畅性这个系列主要是分析流畅度相关的问题，响应速度和稳定性会有专门的文章介绍，在理解了流畅性相关的内容之后，再去分析响应速度和稳定性问题会事半功倍
5. 流畅性这个系列主要是讲如何使用 Systrace (Perfetto) 工具去分析，之所以 Systrace 为切入点，是因为影响流畅度的因素很多，有 App 自身的原因、也有系统的原因。而 Systrace(Perfetto) 工具可以从一个整机运行的角度来展示问题发生的过程，方便我们去初步定位问题

不同的人对流畅性(卡顿掉帧)有不同的理解，对卡顿阈值也有不同的感知，所以有必要在开始这个系列文章之前，先把涉及到的内容说清楚，防止出现不同的理解，也方便大家带着问题去看这几篇问题，下面是一些基本的说明

1. 对手机用户来说，卡顿包含了很多场景，比如在 滑动列表的时候掉帧、应用启动白屏过长、点击电源键亮屏慢、界面操作没有反应然后闪退、点击图标没有响应、窗口动画不连贯、滑动不跟手、重启手机进入桌面卡顿 等场景，这些场景跟我们开发人员所理解的卡顿还有点不一样，开发人员会更加细分去分析这些问题，这是开发人员和用户之间的一个认知差异，这一点在处理用户(或者测试人员)的问题反馈的时候尤其需要注意
2. 对开发人员来说，可以先按 流畅度（画面节奏不连贯）、响应速度（操作后等待过长）和 稳定性（崩溃、ANR 等）整理反馈。这些现象可能重叠；点击没有响应不一定是稳定性故障，需要结合输入、应用状态和日志进一步分类。
3. 技术上，这三类问题并不是同一个 Message 超时机制的不同阈值。主线程长任务会同时影响输入和绘制，但 GPU、SurfaceFlinger、显示链路、线程调度或远端服务也可能造成延迟。ANR 由具体输入/组件等超时规则触发，崩溃则另有异常或信号等原因；不能仅凭一次长 Message 判定它们。
4. 流畅性这个系列主要是分析流畅度相关的问题，响应速度和稳定性会有专门的文章介绍，在理解了流畅性相关的内容之后，再去分析响应速度和稳定性问题会事半功倍
5. 流畅性这个系列主要是讲如何使用 Systrace (Perfetto) 工具去分析，之所以 Systrace 为切入点，是因为影响流畅度的因素很多，有 App 自身的原因、也有系统的原因。而 Systrace(Perfetto) 工具可以从一个整机运行的角度来展示问题发生的过程，方便我们去初步定位问题

技术群里的小伙伴发了一条微博， https://weibo.com/1808884742/IApbpEVQr， 博主 @王波粒 发现， Mate 30 Pro 有个很特别的现象（建议先去看一下视频）

这里讨论的是 2020 年观察到的一组差异：部分华为样机上的微博会在主页列表滑动中显示图片，而当时部分其他样机要等到停止后才显示。 这个现象不能推广到当前所有机型；相同客户端版本也可能受到配置、缓存和系统实现的影响。

同一个版本的微博，在不同手机上表现不一样，作为系统优化工程师，我还是想搞清楚的：是不是微博专门做了适配？具体改了什么？下面就从技术的角度来分析这个现象，看看我们能从里面学到什么。

2020 年 5 月 23 号凌晨 1 点 30 左右, 大量三星手机用户的手机出现死机, 无限重启、进 Recovery 等问题, 并且操作不当会导致数据丢失, 并且上了知乎的热点, 售后点更是人满为患

知乎的部分回答中, 大家更是对三星的家属送上了亲切的问候, 甚至有的人已经将这次事故与 Note7 事件、充电门、绿屏门事件相提并论, 甚至预言三星因此会退出国内市场 ; 有的人因为这个丢了 Offer, 有的人准备了很久的资源丢失, 有的人甚至直接把手机砸了…

作为一个 Android 开发者, 我并不想对三星落井下石, 我只想搞清楚到底是什么原因导致了这场事故, 以及我们能从里面学到什么 . 我认为既然是 Android 系统出了问题, 我们有必要从技术的角度来分析为什么会出现这样的问题

MIUI 12 的发布, 将之前一直是应用开发者和 Rom 开发者斗争最激烈的部分展示给了普通消费者, 让普通消费者也知道了这场斗争的细节, 正所谓 “魔高一尺道高一丈”, Rom 开发者由于有更高的代码修改权限, 始终占据着上风 ; App 开发者当然也不甘示弱, 各种保活拉起黑科技层出不穷,甚至 Google 都参与到了这部分斗争中, 居中调和, 制定各种规则来规范双方. 当然斗争对双方来说都算是好事, 毕竟任何一方完全的胜利都会导致 “狡兔死走狗烹,飞鸟尽良弓藏”

不过双方斗争的受害者无疑还是使用手机的消费者, App 如果斗争成功, 那么手机上各种后台进程乱跑, 杀不掉, 占用 CPU 和内存, 这不是消费者想看到的 ; 如果 Rom 开发者斗争成功, App 的体验必定会大打折扣, 各位 App 开发者应该深有体会.

从文章最后一段可以看到, 其实各个手机厂商对付这一套都有自己的策略, 基本上都可以搞定自启动和关联启动. 至于隐私, 李彦宏曾经说过 “中国人对隐私问题的态度更加开放，也相对来说没那么敏感。如果他们可以用隐私换取便利、安全或者效率。在很多情况下，他们就愿意这么做“ . 大家想想在微信里面复制一段话打开到淘宝就可以自动跳转到这个物品, 方不方便? 好不好用? 还想不想用? 剪贴板再借我看一看?

本文是 Systrace 系列文章的第五篇，主要是对 SurfaceFlinger 的工作流程进行简单介绍，介绍了 SurfaceFlinger 中几个比较重要的线程，包括 Vsync 信号的解读、应用的 Buffer 展示、卡顿判定等，由于 Vsync 这一块在 Systrace 基础知识 - Vsync 解读 和 Android 基于 Choreographer 的渲染机制详解 这两篇文章里面已经介绍过，这里就不再做详细的讲解了。

本系列的目的是通过 Systrace 这个工具，从另外一个角度来看待 Android 系统整体的运行，同时也从另外一个角度来对 Framework 进行学习。也许你看了很多讲 Framework 的文章，但是总是记不住代码，或者不清楚其运行的流程，也许从 Systrace 这个图形化的角度，你可以理解的更深入一些。

Medium 上 @MindOrks 发布了一篇 2020 年 Android 程序员的学习线路，鉴于一部分人无法阅读原文(你懂得原因)，我把这篇文章的内容结合自己的 2020 年的学习计划，一起发出来，给大家一个参考

原文比较简单，并没有介绍为什么要推荐这些，只是单纯地列了一下知识点，我这边针对每个知识点做一些简单的介绍，有些知识点原文并没有提到，我会根据自己的理解加上，仅供参考

这篇文章主要针对 Android 开发者，如果你是新手，那么下面的内容可以帮助你找到学习的线路；如果你是老手，这篇文章列出的内容也可以帮助你查漏补缺。如果各位有什么其他的建议，欢迎留言交流

下面记录了我 2020 年的读书单，所记录的，都是已经读完了的，技术书籍由于很难定义读完，所以不在此列。

我比较喜欢读历史相关的书，其中 汴京之围 这本书读起来非常难受，弱国无外交，真的是写实；坏小孩 书如其名，个人感觉是要比电视剧好很多；重来 2 和 重来 3 跟工作相关，讲的是远程工作和工作方法，跟 2020 年居家办公的大趋势一致，白领程序员推荐看一下；我的最后一本减肥书 则比较系统和专业地讲了一下减肥相关的知识，对于在减肥的我来说很有用；最后 镖人 也算是国漫经典了，等出完了之后我一定要买一套实体书典藏（巨人也是）

2020 读书不多，2021 要加大这方面的投入，读 + 记录 + 总结 ，读书笔记后续都会补上

本文是 Systrace 系列文章的第十二篇，主要是对 Systrace 中的 CPU 信息区域(Kernel)进行简单介绍，简单介绍了如何在 Systrace 中查看 Kernel 模块输出的 CPU 相关的信息，了解 CPU 频率、调度、锁频、锁核相关的信息

本系列的目的是通过 Systrace 这个工具，从另外一个角度来看待 Android 系统整体的运行，同时也从另外一个角度来对 Framework 进行学习。也许你看了很多讲 Framework 的文章，但是总是记不住代码，或者不清楚其运行的流程，也许从 Systrace 这个图形化的角度，你可以理解的更深入一些。