阅读视图

发现新文章,点击刷新页面。

Android Perfetto 系列 3:熟悉 Perfetto View

本篇是 Perfetto 系列文章的第三篇,前两篇介绍了 Perfetto 是什么以及 Perfetto Trace 怎么抓,本篇主要是在网页端打开 Perfetto Trace 之后,面对复杂的 Perfetto 信息该怎么看。

随着 Google 宣布 Systrace 工具停更,推出 Perfetto 工具,Perfetto 在我的日常工作中已经基本能取代 Systrace 工具。同时 Oppo、Vivo 等大厂也已经把 Systrace 切换成了 Perfetto,许多新接触 Android 性能优化的小伙伴对于 Perfetto 那眼花缭乱的界面和复杂的功能感觉头疼,希望我能把之前的那些 Systrace 文章使用 Perfetto 来呈现。

Paul Graham 说:要么给大部分人提供有点想要的东西,要么给小部分人提供非常想要的东西。Perfetto 其实就是小部分人非常想要的东西,那就开始写吧,欢迎大家多多交流和沟通,发现错误和描述不准确的地方请及时告知我,我会及时修改,以免误人子弟。

本系列旨在通过 Perfetto 这个工具,从一个新的视角审视 Android 系统的整体运作方式。此外,它还旨在提供一个不同的角度来学习 App 、 Framework、Linux 等关键模块。尽管你可能已经阅读过许多关于 Android Framework、App 、性能优化的文章,但或许因为难以记住代码或不明白其运行流程,你仍感到困惑。通过 Perfetto 这个图形化工具,你可能会获得更深入的理解。

Perfetto 系列目录

  1. Android Perfetto 系列目录
  2. Android Perfetto 系列 1:Perfetto 工具简介
  3. Android Perfetto 系列 2:Perfetto Trace 抓取
  4. Android Perfetto 系列 3:熟悉 Perfetto View

如果大家还没看过 Systrace 系列,下面是传送门:

  1. Systrace 系列目录 : 系统介绍了 Perfetto 的前身 Systrace 的使用,并通过 Systrace 来学习和了解 Android 性能优化和 Android 系统运行的基本规则。
  2. 个人博客 :个人博客,主要是 Android 相关的内容,也放了一些生活和工作相关的内容。

欢迎大家在 关于我 页面加入微信群或者星球,讨论你的问题、你最想看到的关于 Perfetto 的部分,以及跟各位群友讨论所有 Android 开发相关的内容

Perfetto View 界面

抓到 Perfetto Trace 之后,一般是在 ui.perfetto.dev 中打开(如果用官方提供的脚本,则会在抓去结束后自动在这个网站上打开,想看看怎么实现的话可以去看看脚本的源码)。打开后界面如下:

Perfetto View 界面

可以通过 Open trace file 或者直接把 Perfetto Trace 拖到白色区域来打开 Trace。

Perfetto Trace 界面

打开 Perfetto Trace 之后界面如下:

Trace 操作区

大致上 Perfetto Trace 界面可以分为四个区域:

  1. 最右边的操作区:这里最主要的是 Current Trace 这一栏下面的那几个会经常用到。
    1. Show timeline :显示当前 Trace,切到了别的界面之后,再点这个就会回到 Trace View 界面
    2. Query:写 SQL 查询语句和查看执行结果的地方
    3. Metrics:官方默认帮你写好的一些分析结果,可以选择直接打开
    4. Info and stats :当前 Trace 和手机 App 的一些信息
  2. 上方的信息和操作区域:最主要就是看时间。
  3. 中间的 Trace 内容区:操作最多的区域,Trace 内容都在这部分,最上面的几部分是从功能的角度来划成一个区域的,比如 CPU 区(可以查看当前 Task 跑在哪个核心上,频率是多少,跑了多长时间、被谁唤醒)、Ftrace event 区等;下面的就是以 App Process 为单位展示的(包括 App 的各种线程、Input 事件、Binder Call、Memory、Buffer 等信息)。
  4. 最下方的信息区:这个区域主要是展示各种信息、我们选中了某个 Task 段之后,这里就会展示这个 Task 相关的信息(如果你加了 Log,这里也会显示 Log;ftrace event 同理)。

Perfetto 界面最初看的时候会觉得很乱,花里胡哨的,但是用习惯了之后,真香~

基本操作

Perfetto Trace 界面的操作是非常顺滑的,这是相比 Systrace 的一个巨大的优势,Systrace 打开稍大的 Trace 就会卡卡的,但是 Perfetto Trace 打开 500Mb 的 Trace 依然操作很顺滑。

操作看 Trace 的快捷键跟 Systrace 很像,w/s 是放大/缩小,a/d 是左右移动,鼠标点击是选择。官方左下角的文档有详细的操作说明,忘记了的话可以随时去看看,熟能生巧:

基本操作

SQL 相关的操作

其他快捷键

其他快捷键里面用的比较多的:

  1. f 是放大选中

  2. m 是临时 Mark 一段区域(与 Systrace 一样), 用来上下看时间、看其他进程信息等。临时的意思就是你如果按 m 去 mark 另外一个区域,那么上一个用 m mark 出来的 Mark 区域就会消失。退出临时选中:esc ,或者选择其他的 Slice 按 m,当前这个 Slice 的选中效果就会消失

  3. shift + m 是持续 Mark 一段区域(如果你不点,他就不会消失),主要是用来长时间 Mark 住一段信息,比如你把一份 Trace 中所有的掉帧点都 Mark 出来,就可以用 shift + m,这样就不会丢失。

    点击小旗子,就可以看到这段区间内的执行信息

  1. 删除持续 Mark

    1. 点击你选中的那个 Slice 的最上面那个三角
    2. 下面选择 Tab:Current Selection
    3. 点击最后边的 Remove ,就可以把他 Remove 掉了
  2. q :隐藏和显示信息 Tab,由于 Perfetto 非常占屏幕,熟练使用 q 键很重要,看的时候快速打开,看完后快速关闭。

  3. 插旗子:Perfetto 还可以通过插旗子的方法来在 Trace 上做标记,Perfetto 支持你把鼠标放到 Trace 最上面,就会出现一个旗子,点击左键即可插一个旗子在上面,方便我们标记某个事件发生,或者某个时间点

  1. 取消插的旗子:与退出持续选中一样,点击旗子,右下角有个 Remove ,点击就可以把这个旗子干掉了,就不插图了

Perfetto 使用技巧

查看唤醒源

我们可以通过查看某一个 Task 的唤醒源,来了解 App 和 Framework 的运转流程,Systrace 和 Perfetto 都可以查看唤醒源,不过 Perfetto 在这方面做的更丝滑一些。

Android Systrace 响应速度实战 3 :响应速度延伸知识 这篇文章中,有讲 Systrace 是如何查看唤醒源的,其实略微还是有些麻烦的。 Perfetto 中查看唤醒源则非常方便且操作很顺滑:

比如我们想看下图中, RenderThread 是被谁唤醒的,我们可以有好几种方法:

点击 Runnable 状态

与 Systrace 操作一样,直接点击 Running 前面的 Runnable,就可以在下面的信息区看到 Related thread states:

  1. Waker:唤醒源
  2. Previous state:这个 Task 的前一个状态
  3. Next state:这个 Task 的后一个状态

点击他上方的 Running 状态,查看连续唤醒信息:

或者我们可以点击 Running 状态,点击小箭头直接跳到对应的 CPU Info 区域,这里可以看到更详细的信息,也可以连续点击 Task,来追踪唤醒源,并可以通过信息区的小箭头来回在 CPU Info 区域和 Task 区域跳转

点击 RenderThread 上方的 Running 状态,通过小箭头跳转到 CPU Info 区域

RenderThread 是被 MainThread 唤醒的

再点击 MainThread 可以看到他是被 SurfaceFlinger 唤醒的,下方信息区还有对应的唤醒延迟分析

查看 Critical Path(Task)

Critical Task 指的是与当前我们选中的 Task 有依赖关系的 Task,比如我们的 Task 是 e,e 要等 d 执行结束后才能执行,d 要等 c,c 要等 b,b 要等 a,那么 e 的 Critical Task 就是 a、b、c、d。

Perfetto 上就可以查看某一个 Task 的 Critical Task,鉴于 Critical path lite 是 Critical path 的子集,我们这里只介绍 Critical path:

点击 Running 状态,然后点击在下面的信息区点击 Critical path

稍等片刻就可以看到我们选择的 MainThread 对应的 Critical path:

放大来看,可以看到我们选择的 MainThread 的边缘,第一个 Critical Task 是唤醒他的 sf 的 app 线程

再往左看 sf 的 app 线程是被 sf 的 TimerDispatch 线程唤醒的,这里就不贴了。

其实可以看到,Perfetto 提供的 Critical Path 其实就是把连续唤醒的 Task 都聚集到一起了,方便我们来看各个 Task 之间的关系。

Pin (固定到最上面)

在每个 Thread 的最左边,有一个图钉一样的按钮,点击之后,这个 Thread 就会被固定到最上面,方便我们把自己最关注的 Thread 放到一起。

比如下面是我 Pin 的从 App 到 SF 的流程图,放到一起的话就会清晰很多,看掉帧的话也会更方便。

CPU Info 区域 Task 高亮

在 CPU Info 区域,鼠标放到某一个 Task 上,就会这个 Task 对应的 Thread 的其他 Task 都会高亮。

我们经常会用这个方法来初步看某些 Thread 的摆核信息

查看 Buffer 消耗情况

App 的 Buffer 消费者是 SurfaceFlinger,通过 App Process 这边的 Actual Timeline 这行,我们可以看到 Buffer 具体是被 SurfaceFlinger 的哪一框消费了。

快速查看 App 执行超时

由于 Android 多 Buffer 机制的存在,App 执行超时不一定会卡顿,但是超时是需要我们去关注的。

通过 Perfetto 提供给的 Expected Timeline 和 Actual Timeline 这两行,可以清楚看到执行超时的地方。

点击 Actial Timeline 红色那一段,底下的信息栏会显示掉帧原因:

在 Perfetto 上查看 Log

在信息栏上切换到 Android Logs 这个 Tab,鼠标放倒某一行上,Perfetto 就会把对应的 Timeline 拉一条直线,可以看到这个 Log 所对应的时间

同样切换到 Ftrace events tab 也可以查看对应的 ftrace 的 event 和对应的时间线

分析 Thread 的 Running 信息

可以通过鼠标左键按住滑动,选中一段区域来进行分析,比如选中 CPU State 这一栏的话,就可以看到这一段时间对应的 Running、Runnable、Sleep、Uninterruptible Sleep 的占比。

这在分析 App 启动的时候经常会用到。

总结

上面分享了 Perfetto 基本的界面和操作,以及分享了一些比较常用的 Perfetto 的技巧。Google 目前在积极推广和维护 Perfetto,很多新功能指不定哪天就蹦出来了,到时候觉得有用我也会更新上来。

至此 Perfetto 基础篇就结束了,后续就是通过 Perfetto 这个工具,来了解 Android 系统运行的基本流程,以及使用 Perfetto 以及 Perfetto SQL 来分析遇到的性能、功耗等问题。

关于我 && 博客

  1. 关于我 , 非常希望和大家一起交流 , 共同进步 .
  2. 博客内容导航
  3. 优秀博客文章记录 - Android 性能优化必知必会

一个人可以走的更快 , 一群人可以走的更远

Android Perfetto 系列 2:Perfetto Trace 抓取

上一篇文章 Android Perfetto 系列 1:Perfetto 工具简介 介绍了 Perfetto 是什么,这篇简单介绍一下 Perfetto 的抓取。

随着 Google 宣布 Systrace 工具停更,推出 Perfetto 工具,Perfetto 在我的日常工作中已经基本能取代 Systrace 工具。同时 Oppo、Vivo 等大厂也已经把 Systrace 切换成了 Perfetto,许多新接触 Android 性能优化的小伙伴对于 Perfetto 那眼花缭乱的界面和复杂的功能感觉头疼,希望我能把之前的那些 Systrace 文章使用 Perfetto 来呈现。

Paul Graham 说:要么给大部分人提供有点想要的东西,要么给小部分人提供非常想要的东西。Perfetto 其实就是小部分人非常想要的东西,那就开始写吧,欢迎大家多多交流和沟通,发现错误和描述不准确的地方请及时告知我,我会及时修改,以免误人子弟。

本系列旨在通过 Perfetto 这个工具,从一个新的视角审视 Android 系统的整体运作方式。此外,它还旨在提供一个不同的角度来学习 App 、 Framework、Linux 等关键模块。尽管你可能已经阅读过许多关于 Android Framework、App 、性能优化的文章,但或许因为难以记住代码或不明白其运行流程,你仍感到困惑。通过 Perfetto 这个图形化工具,你可能会获得更深入的理解。

Perfetto 系列目录

  1. Android Perfetto 系列目录
  2. Android Perfetto 系列 1:Perfetto 工具简介
  3. Android Perfetto 系列 2:Perfetto Trace 抓取
  4. Android Perfetto 系列 3:熟悉 Perfetto View

如果大家还没看过 Systrace 系列,下面是传送门:

  1. Systrace 系列目录 : 系统介绍了 Perfetto 的前身 Systrace 的使用,并通过 Systrace 来学习和了解 Android 性能优化和 Android 系统运行的基本规则。
  2. 个人博客 :个人博客,主要是 Android 相关的内容,也放了一些生活和工作相关的内容。

欢迎大家在 关于我 页面加入微信群或者星球,讨论你的问题、你最想看到的关于 Perfetto 的部分,以及跟各位群友讨论所有 Android 开发相关的内容

正文

使用 Perfetto 分析问题跟使用 Systrace 分析问题的步骤是一样的:

  1. 首先你需要抓取 Perfetto 文件
  2. ui.perfetto.dev 中打开 Trace 文件进行分析或者使用命令行来进行分析

这篇文章就简单介绍一下使用 Perfetto 抓取 Trace 文件的方法,个人比较推荐使用命令行来抓取,不管是自己配置的命令行还是官方的命令行抓取工具,都非常实用。

1. 使用命令行来抓取 Perfetto(推荐)

基本命令 - adb shell perfetto

对于之前一直用 Systrace 工具的小伙伴来说,命令行抓取 Trace 非常方便。同样,Perfetto 也提供了简单的命令行来抓取,最简单的使用方法与 Systrace 基本一致。你可以直接连到你的 Android 设备上使用/system/bin/perfetto命令来启动跟踪。例如:

1
2
3
4
5
6
7
8
//1. 首先执行命令
adb shell perfetto -o /data/misc/perfetto-traces/trace_file.perfetto-trace -t 20s \
sched freq idle am wm gfx view binder_driver hal dalvik camera input res memory

// 2. 操作手机,复现场景,比如滑动或者启动等

// 3. 将 trace 文件 pull 到本地
adb pull /data/misc/perfetto-traces/trace_file.perfetto-trace

这个命令会启动一个 20 秒钟的跟踪,收集指定的数据源信息,并将跟踪文件保存到/data/misc/perfetto-traces/trace_file.perfetto-trace

执行 adb pull 命令把 trace pull 出来,就可以直接在ui.perfetto.dev 上打开了。

进阶命令 adb shell perfetto with config file

这里就是 Perfetto 与 Systrace 不同的地方,Perfetto 可以抓取的信息非常多,其数据来源也非常多,每次都用命令行加一大堆配置的话会很不方便。这时候我们就可以使用一个单独的**配置文件(Config)**,来存储这些信息,每次抓取的时候,指定这个配置文件即可。

对于在 Android 12 之前和之后版本上使用 Perfetto 的配置文件传递,以下是详细的指南和对应的命令行示例。

在 Android 12 及之后的设备上

从 Android 12 开始,可以直接使用/data/misc/perfetto-configs目录来存储配置文件,这样就不需要通过 stdin 来传递配置文件了。具体命令如下:

1
2
adb push config.pbtx /data/misc/perfetto-configs/config.pbtx
adb shell perfetto --txt -c /data/misc/perfetto-configs/config.pbtx -o /data/misc/perfetto-traces/trace.perfetto-trace

在这个例子中,首先将配置文件config.pbtx推送到/data/misc/perfetto-configs目录中。然后,直接在 Perfetto 命令中通过-c选项指定配置文件的路径来启动跟踪。

在 Android 12 之前的设备上

由于 SELinux 的严格规则,直接通过文件路径传递配置文件在非 root 设备上会失败。因此,需要使用标准输入(stdin)来传递配置文件。这可以通过将配置文件的内容cat到 Perfetto 命令中实现。具体命令如下:

1
2
adb push config.pbtx /data/local/tmp/config.pbtx
adb shell 'cat /data/local/tmp/config.pbtx | perfetto -c - -o /data/misc/perfetto-traces/trace.perfetto-trace'

这里,config.pbtx是你的 Perfetto 配置文件,首先使用adb push命令将其推送到设备的临时目录中。然后,使用cat命令将配置文件的内容传递给 Perfetto 命令。

Config 的来源

Config 我建议使用 ui.perfetto.devRecord new trace 这里进行选择定制,然后再保存到本地的文件里面,不同的场景就加载不同的 Config 即可,文章最后一部分有详细讲到这部分,感兴趣的可以看一下。

官方也提供了 share 按钮,你可以把你自己的 config share 给其他人,非常方便。同时我也会建了一个 Github 的库,方便大家在分享(进行中)。

官方代码库也有一些已经配置好的,各位可以下下来自己使用:https://cs.android.com/android/platform/superproject/main/+/main:external/perfetto/test/configs/

注意事项

  • 确保 adb 正常:在使用这些命令之前,请确保你的设备已经启用了 USB 调试,并且已经通过adb devices命令确认设备已经正确连接。
  • Ctrl+C 中断: 当使用adb shell perfetto命令时,如果你尝试使用 Ctrl+C 来提前结束跟踪,这个信号不会通过 ADB 传播。如果你需要提前结束跟踪,建议使用一个交互式的 PTY-based session 来运行adb shell
  • SELinux 限制: 在 Android 12 之前的非 root 设备上,由于 SELinux 的严格规则,配置文件只能通过cat config | adb shell perfetto -c -的方式传递(其中-c -表示从标准输入读取配置)。从 Android 12 开始,可以使用/data/misc/perfetto-configs路径来存储配置文件。
  • 在 Android 10 之前的版本, adb 没法直接把 /data/misc/perfetto-traces pull 出来. 你可以使用 adb shell cat /data/misc/perfetto-traces/trace > trace 来替代

2. 使用 Perfetto 提供的官方脚本抓取(强烈推荐)

Perfetto 团队还提供了一个便捷的脚本tools/record_android_trace,它简化了从命令行记录跟踪的流程。这个脚本会自动处理路径问题,完成跟踪后自动拉取跟踪文件,并在浏览器中打开它。本质上这个脚本还是使用的 adb shell perfetto 命令,不过官方帮你封装好了,使用示例:

On Linux and Mac:

1
2
3
4
curl -O https://raw.githubusercontent.com/google/perfetto/master/tools/record_android_trace
chmod u+x record_android_trace
./record_android_trace -o trace_file.perfetto-trace -t 10s -b 64mb \
sched freq idle am wm gfx view binder_driver hal dalvik camera input res memory

On Windows:

1
2
3
curl -O https://raw.githubusercontent.com/google/perfetto/master/tools/record_android_trace
python3 record_android_trace -o trace_file.perfetto-trace -t 10s -b 64mb \
sched freq idle am wm gfx view binder_driver hal dalvik camera input res memory

同样的,这里也可以通过 -c 来指定配置文件,比如

1
2
3
4
curl -O https://raw.githubusercontent.com/google/perfetto/master/tools/record_android_trace
chmod u+x record_android_trace
./record_android_trace -c config.pbtx -o trace_file.perfetto-trace -t 10s -b 64mb \
sched freq idle am wm gfx view binder_driver hal dalvik camera input res memory

这将会记录一个 10 秒的跟踪,并将输出文件保存为trace_file.perfetto-trace

执行后会自动抓取 Trace, 自动在浏览器自动打开,非常方便

脚本内容可以直接访问:https://raw.githubusercontent.com/google/perfetto/master/tools/record_android_trace 来查看,

3. 使用手机上的开发者工具来抓取

当然有时候会没有办法连接到电脑上,或者测试内容不能插 usb,这时候就可以使用 Android 上的自带的系统跟踪应用(System Tracing App)来抓取 Trace。这个应用内置于开发者选项中,可以让你通过几个简单的步骤来配置和启动性能跟踪。

启动系统跟踪应用

  1. 启用开发者选项:首先,确保你的设备已经启用了开发者选项。如果你的设置里面没有开发者选项,你需要在关于手机那里,找到编译编号,然后连续点击 7 次,就可以打开开发者选项。

  2. 打开开发者选项:在设置菜单中找到并打开开发者选项。

  3. 启动系统跟踪:在开发者选项中向下滚动直到找到“系统跟踪(System Trace)”或类似的选项。点击它,将打开系统跟踪应用。

大概长下面这样(每个手机可能界面或者文字会有差异,但是功能是一样的)

系统跟踪应用提供了一系列的配置选项,包括但不限于:

  • 跟踪时长:你可以指定跟踪的持续时间,例如 10 秒或更长时间。
  • 数据源:选择你想要收集数据的来源。这可能包括 CPU、内存、网络等多种不同的数据源。
  • 输出文件位置:指定跟踪文件保存的位置。

启动和停止跟踪

配置好所有需要的参数后,你可以通过点击“录制跟踪记录”按钮来启动跟踪。再次“录制跟踪记录”按钮就可以结束抓取,完成抓取后,通常会有一个提示告诉你抓取已经完成,并提供查看或分享跟踪文件的选项。就可以将跟踪文件导出到电脑上,使用 Perfetto 网页 UI 进行更深入的分析。

4. 使用网页端来抓取

网页端抓取的功能比较迷,很多时候你都会抓取失败,比如连不上 adb、连上之后说你需要执行 kill。所以我更推荐大家使用配置好的命令行来抓取,网页端更适合进行 Config 的配置。

Perfetto 还提供了一个强大的 网页端工具(ui.perfetto.dev),允许开发者通过浏览器配置和启动跟踪。你只需要访问 网站,点击“Record new trace”,然后根据需要选择数据源和配置参数。确保你的设备通过 ADB 连接到电脑,并且在网页端选择“Add ADB device”。之后,点击“Start Recording”即可开始收集跟踪数据。

这里选好你想抓取的信息源之后,可以点击 Recording command 来查看,这里可以看到你选好的 Config 的具体内容,你可以分享或者保存到本地的文件里面,用命令行抓取的时候使用。

选取 Config 的时候,Android apps 那一栏里面的 Atrace userspace annotations、Event log (logcat)、Frame timeline 建议都选上(command + a)

另外如果想看调用栈,可以把 Stack Samples 这里的 Callstack sampling 勾选上(注意需要最新版本的 Android 才可以,而且所 debug 的进程得是 debugable 的)

至于其他的有啥用,可以自己探索,后续的 Perfetto 也会介绍到每个部分和他在 Trace 上的呈现,帮助大家更快入手 Perfetto。

从网页端提取参数

前面提到网页端的可以图形化选择 Config 这个很方便,选好之后,点击 Recording command 这里,就可以看到已经选好的 Config,你在保存的时候记得把下面这几行去掉就可以了

参考文档

  1. https://perfetto.dev/docs/quickstart/android-tracing
  2. https://perfetto.dev/docs/concepts/config
  3. https://developer.android.com/tools/releases/platform-tools?hl=zh-cn
  4. https://mp.weixin.qq.com/s/nsqc51L5T4mrTUVsPgkj6A
  5. https://juejin.cn/post/7344983784549400613
  6. https://cs.android.com/android/platform/superproject/main/+/main:external/perfetto/test/configs/

关于我 && 博客

  1. 关于我 , 非常希望和大家一起交流 , 共同进步 .
  2. 博客内容导航
  3. 优秀博客文章记录 - Android 性能优化必知必会

一个人可以走的更快 , 一群人可以走的更远

Android Perfetto 系列 1:Perfetto 工具简介

本篇是 Perfetto 系列文章的第一篇,主要是简单介绍 Perfetto 工具,包括 Perfetto 的历史、发展,以及 Perfetto 能做什么。

随着 Google 宣布 Systrace 工具停更,推出 Perfetto 工具,Perfetto 在我的日常工作中已经基本能取代 Systrace 工具。同时 Oppo、Vivo 等大厂也已经把 Systrace 切换成了 Perfetto,许多新接触 Android 性能优化的小伙伴对于 Perfetto 那眼花缭乱的界面和复杂的功能感觉头疼,希望我能把之前的那些 Systrace 文章使用 Perfetto 来呈现。

Paul Graham 说:要么给大部分人提供有点想要的东西,要么给小部分人提供非常想要的东西。Perfetto 其实就是小部分人非常想要的东西,那就开始写吧,欢迎大家多多交流和沟通,发现错误和描述不准确的地方请及时告知我,我会及时修改,以免误人子弟。

本系列旨在通过 Perfetto 这个工具,从一个新的视角审视 Android 系统的整体运作方式。此外,它还旨在提供一个不同的角度来学习 App 、 Framework、Linux 等关键模块。尽管你可能已经阅读过许多关于 Android Framework、App 、性能优化的文章,但或许因为难以记住代码或不明白其运行流程,你仍感到困惑。通过 Perfetto 这个图形化工具,你可能会获得更深入的理解。

Perfetto 系列目录

  1. Android Perfetto 系列目录
  2. Android Perfetto 系列 1:Perfetto 工具简介
  3. Android Perfetto 系列 2:Perfetto Trace 抓取
  4. Android Perfetto 系列 3:熟悉 Perfetto View

如果大家还没看过 Systrace 系列,下面是传送门:

  1. Systrace 系列目录 : 系统介绍了 Perfetto 的前身 Systrace 的使用,并通过 Systrace 来学习和了解 Android 性能优化和 Android 系统运行的基本规则。
  2. 个人博客 :个人博客,主要是 Android 相关的内容,也放了一些生活和工作相关的内容。

欢迎大家在 关于我 页面加入微信群或者星球,讨论你的问题、你最想看到的关于 Perfetto 的部分,以及跟各位群友讨论所有 Android 开发相关的内容

正文

2019 年开始写 Systrace 系列,陆陆续续写了 20 多篇,从基本使用到各个模块在 Systrace 上的呈现,再到启动速度、流畅性等实战,基本上可以满足初级系统开发者和 App 开发者对于 Systrace 工具的需求。通过博客也加了不少志同道合的小伙伴,光交流群就建了有 6 个。这里非常感谢大家的支持。

随着 Google 宣布 Systrace 工具停更,推出 Perfetto 工具,Perfetto 在我的日常工作中已经基本能取代 Systrace 工具。同时 Oppo、Vivo 等大厂也已经把 Systrace 切换成了 Perfetto,许多新接触 Android 性能优化的小伙伴对于 Perfetto 那眼花缭乱的界面和复杂的功能感觉头疼,希望我能把之前的那些 Systrace 文章使用 Perfetto 来呈现。

所以就有了这个系列,我也有在星球里面写了几条为什么要更新 Perfetto 系列的原因(之前一直觉得 Systrace 系列就够了):

  1. 目前 Oppo、Vivo 这些手机厂商内部,都已经切换成 Perfetto 了,不管是抓 Trace 还是看 Trace,都在使用 Perfetto ,很多新人接触的都是 Perfetto 而不是 Systrace ,守着之前的老 Systrace 系列会流失这部分读者
  2. 之前的 Systrace 系列,对应的 Code 已经比较老了,全新的 Perfetto 系列可以使用 Android 14 的 Code 来进行更新
  3. 个人对 Perfetto 的使用也没有很深入,有些高阶功能目前还只是浅尝辄止。可以通过重写 Perfetto 系列来进行这部分内容的强化
  4. Perfetto 是个很强大的工具,他的背后是整个 Android + Linux 系统,所以在写这个系列的时候,应该是以他背后的这个 Android + Linux 为主,而不是仅仅局限于 Perfetto 这个工具。工具只是我们观测 Android + Linux 的方式,理解整个 Android 系统运行的规律,思考其运行的原理,通过工具挖掘问题,通过问题思考本质,这才是对开发者来说有意义的
  5. 很多 Android 系统运行相关的内容,Perfetto 的官方文档还是没有讲,这部分我这边可以作为补足;另外官方文档是英文版本的,中文博客可以补充这方面。
  6. Perfetto 可以拿到 Google Dev Fest 上作为演讲内容~。

Paul Graham 说:要么给大部分人提供有点想要的东西,要么给小部分人提供非常想要的东西。Perfetto 其实就是小部分人非常想要的东西,那就开始写吧,欢迎大家多多交流和沟通,发现错误和描述不准确的地方请及时告知我,我会及时修改,以免误人子弟。

Perfetto

性能分析为什么需要上帝视角

在介绍 Perfetto 之前,我们需要了解为什么性能分析需要 Systrace 和 Perfetto 这样的工具:以 Android 系统为例,影响性能的因素是非常多的:App 自身质量、系统各个模块的性能、Linux 的性能、硬件性能,再加上各个厂商的策略、厂商定制的功能、系统自身的负载、低内存、发热、Android 各个版本的差异、用户的使用习惯等。这都不是通过分析某一个 App 或者某一个模块就能知道原因的,我们需要一个上帝视角,从更高的纬度来看 Android 系统的运行情况。

而 Perfetto 工具就提供了这样的一个上帝视角,通过上帝视角我们可以看到 Android 系统在运行时的各个细节,比如

  1. Input 事件是怎么流转的
  2. 你正在使用的 App 的每一帧是怎么从 App 产生到上屏的
  3. CPU 的实时频率、负载、摆核、唤醒等
  4. 系统中的各个 App 是怎么运行的
  5. ….

App 开发者和 Android 系统开发者也都会在重要的代码逻辑处加上 Trace 点,打开部分 Debug 选项之后,更是可以得到非常详细的信息,甚至一个 Task 为什么摆在某个 cpu 上,都会有详细的记载。通过这些在 Perfetto 上所展示的信息,我们能初步分析到性能问题的原因,接下来继续分析就会有针对性。

同样为了说明性能优化的复杂性,可以看看 <性能之巅**> 这本书中对于性能的描述,具体来说就是方法论,非常贴合本文的主题,也强烈推荐各位搞性能优化的同学,把这本书作为手头常读的方法论书籍:系统性能工程是一个充满挑战的领域,具体原因有很多,其中包括以下事实,系统性能是主观的、复杂的,而且常常是多问题并存的**

性能是主观的

  1. 技术学科往往是客观的,太多的业界人士审视问题非黑即白。在进行软件故障查找的时候,判断 bug 是否存在或 bug 是否修复就是这样。bug 的出现总是伴随着错误信息,错误信息通常容易解读,进而你就明白错误为什么会出现了
  2. 与此不同,性能常常是主观性的。开始着手性能问题的时候,对问题是否存在的判断都有可能是模糊的,在问题被修复的时候也同样,被一个用户认为是“不好”的性能,另一个用户可能认为是“好”的

系统是复杂的

  1. 除了主观性之外,性能工程作为一门充满了挑战的学科,除了因为系统的复杂性,还因为对于性能,我们常常缺少一个明确的分析起点。有时我们只是从猜测开始,比如,责怪网络,而性能分析必须对这是不是一个正确的方向做出判断
  2. 性能问题可能出在子系统之间复杂的互联上,即便这些子系统隔离时表现得都很好。也可能由于连锁故障(cascading failure)出现性能问题,这指的是一个出现故障的组件会导致其他组件产生性能问题。要理解这些产生的问题,你必须理清组件之间的关系,还要了解它们是怎样协作的
  3. 瓶颈往往是复杂的,还会以意想不到的方式互相联系。修复了一个问题可能只是把瓶颈推向了系统里的其他地方,导致系统的整体性能并没有得到期望的提升。
  4. 除了系统的复杂性之外,生产环境负载的复杂特性也可能会导致性能问题。在实验室环境很难重现这类情况,或者只能间歇式地重现
  5. 解决复杂的性能问题常常需要全局性的方法。整个系统——包括自身内部和外部的交互——都可能需要被调查研究。这项工作要求有非常广泛的技能,一般不太可能集中在一人身上,这促使性能工程成为一门多变的并且充满智力挑战的工作

可能有多个问题并存

  1. 找到一个性能问题点往往并不是问题本身,在复杂的软件中通常会有多个问题
  2. 性能分析的又一个难点:真正的任务不是寻找问题,而是辨别问题或者说是辨别哪些问题是最重要的
  3. 要做到这一点,性能分析必须量化(quantify)问题的重要程度。某些性能问题可能并不适用于你的工作负载或者只在非常小的程度上适用。理想情况下,你不仅要量化问题,还要估计每个问题修复后能带来的增速。当管理层审查工程或运维资源的开销缘由时,这类信息尤其有用。
  4. 有一个指标非常适合用来量化性能,那就是 延时(latency)

Perfetto 介绍

Perfetto 是一个高级的开源工具,专为性能监测和分析而设计。它配备了一整套服务和库,能够捕获和记录系统层面以及应用程序层面的活动数据。此外,Perfetto 还提供了内存分析工具,既适用于本地应用也适用于 Java 环境。它的一个强大功能是,可以通过 SQL 查询库来分析跟踪数据,让你能够深入理解性能数据背后的细节。为了更好地处理和理解大规模数据集,Perfetto 还提供了一个基于 Web 的用户界面,使你能够直观地可视化和探索多 GB 大小的跟踪文件。简而言之,Perfetto 是一个全面的解决方案,旨在帮助开发者和性能工程师以前所未有的深度和清晰度来分析和优化软件性能。

谷歌在 2017 年开始了第一笔提交,随后的 6 年(截止到 2024)内总共有 100 多位开发者提交了近 3.7W 笔提交,几乎每天都有 PR 与 Merge 操作,是一个相当活跃的项目。 除了功能强大之外其野心也非常大,官网上号称它是下一代面向可跨平台的 Trace/Metric 数据抓取与分析工具。应用也比较广泛,除了 Perfetto 网站,Windows Performance Tool 与 Android Studio,以及华为的 GraphicProfiler 也支持 Perfetto 数据的可视化与分析。 我们相信谷歌还会持续投入资源到 Perfetto 项目,可以说它应该就是下一代性能分析工具了,会完全取代 Systrace。

如果你已经习惯使用 Systrace,那么切换到 Perfetto 会非常顺滑,因为 Perfetto 是完全兼容 Systrace 的。你之前抓的 Systrace 文件,可以直接扔到 Perfetto Viewer 网站里面直接打开。如果你还没有适应 Perfetto ,你也可以从 Perfetto Viewer 一键打开 Systrace。

下图是 Perfetto 的架构图,可以看到 Perfetto 包含了三大块:

  1. Record traces :即数据抓取模块,可以看到抓取的内容和来源非常丰富,Java、 Native 、Linux 都有涉及到,相比 Systrace 要丰富很多。
  2. Analyze traces :主要是 trace 分析模块,包括 Trace 解析、SQL 查询、Metrics 分析等,这部分有专门的命令行工具提供,方便大家直接调用或者在工具链里面去调用。
  3. Visualize Traces:Trace 的呈现、抓取等

这几个模块在后续的系列文章中都会详细介绍

Perfetto 的核心优势和功能亮点:

通过长时间的使用和对比,以及看各种分享,总结了一下 Perfetto 的核心优势和功能两点

  1. 支持长时间数据抓取

    • Perfetto 通过后台服务支持长时间数据抓取,利用 Protobuf 编码存储数据。
  2. 数据来源与兼容性

    • 基于 Linux 内核的 Ftrace 机制,记录用户空间与内核空间的关键事件。
    • 兼容 Systrace 的功能,并有望最终取代它。
  3. 全面的数据支持

    • 支持 Trace、Metric 和 Log 类型的数据。
    • 提供多种数据抓取方式,包括网页、命令行工具、开发者选项以及 Perfetto Trigger API。
  4. 高效的数据分析

    • 提供数据可视化网页,支持大文件渲染,优于 Systrace。
    • Trace 文件可转换为 SQLite 数据库文件,支持 SQL 查询和脚本执行。
    • 提供 Python API,允许将数据导出为 DataFrame 格式,为深入分析提供便利。
    • 支持函数调用堆栈展示。
    • 支持内存堆栈展示。
    • 支持 pin 住你感兴趣的行到最上面,不用一直上下翻(通过脚本可以一打开就自动 pin)
    • 支持可视化 Binder 调用和跳转
    • 支持很方便的查询唤醒源
    • 支持 Critical Task 的可视化查询
  5. Google 的持续更新

    • Google 的工具团队在持续更新 Perfetto,版本 Release 和 Bugfix 都非常及时,可以在 Github 上观察。

这里专门提一下 SQL,Perfetto 可以使用 SQL 这是一个巨大的改进,他在解析 Trace 文件的时候,会内建许多 SQL 表和图,方便使用 SQL 语句进行查询,比如下面这几个查询,就是非常实用的(图来自内核工匠)。

另外他的官方文档里面,介绍到对应的部分,也会把对应的 SQL 以及查询结果示例贴出来。

有了这个,就再也不怕老板说你没有数据了,分分钟 SQL 查出来,表格转图标,一份高质量的 Report 就出来了:优化前后,xxx 指标下降了 xx%,属实是非常方便的。

相比 Systrace 没那么好用的地方

Vsync-App 没那么直观

Vsync-App 在 Perfetto 相对来说没那么直观,比如你看习惯了 Systrace 中 Vsync-App 那条贯穿整个 Trace 的竖线,你再看 Perfetto 就没有这个,就会觉得怪怪的:

Perfetto 中,你可以把 Vsync-App Pin 到最上面来看 Vsync 信息

Systrace 中,Vsync 以竖线的方式贯穿整个 Trace,很容易辨别:

当然 Perfetto 取消这个也是有理由的:Vsync-App 其实并不能说明 App 有性能问题,Perfetto 使用了另外一个方式来展示,如果你用 Perfetto 命令抓的 Trace,就会有下面这个信息,记录了 App 一帧的 Expected Timeli 和 Actual Timeline 。相比 Vsync-App,这两指标更能说明问题原文档

  1. 预期时间线每个切片代表应用程序用于渲染帧的时间。为了避免系统出现卡顿,应用程序需要在这个时间范围内完成。开始时间是调度 Choreographer 回调的时间。
  2. 实际时间线这些切片代表了应用程序完成帧的实际时间(包括 GPU 工作)并将其发送到 SurfaceFlinger 进行合成的时间。开始时间是应用程序开始运行的时间。这里的切片的结束时间代表的是。后处理时间是应用程序的帧被发布到 SurfaceFlinger 的时间。

通过看 Expected Timeli 和 Actual Timeline 的差异,我们可以很快速定位到卡顿的点(红色标识的 Actual Timeline 那一帧就是卡顿)

其计算方式如下,看了图你就知道为什么这两个是更准确的(包含了 GPU 执行时间)

相对应的,SurfaceFlinger 也有这两个指标

折叠功能比较烂,比较废屏幕

如果你是普通的宽屏,打开 Perfetto 随便 Pin 几个关键线程到最上面,你下面的可操作空间就很小了,如果碰到某个关键线程堆栈比较长,那就更是顶级折磨了,而且他这个堆栈还不能折叠(Systrace 可以)

解决办法:

  1. 少 Pin 几个关键线程 (那还有啥乐趣)
  2. 把显示器竖起来(宽度就打折了)

最终我们找到了完美的方案:换成 LG 那个魔方屏幕,16:18 ,看 Perfetto 简直是绝配(办公室已经被我安利有三台了)

28MQ780

  1. 不差钱:LG 28MQ780 - 3599
  2. 平替:[联合创新 28C1Q - 2999](https://item.jd.com/100058985199.html)

参考文档

  1. Perfetto Github 库
  2. Perfetto 官方文档
  3. 内核工匠 - Perfetto 进阶

关于我 && 博客

  1. 关于我 , 非常希望和大家一起交流 , 共同进步 .
  2. 博客内容导航
  3. 优秀博客文章记录 - Android 性能优化必知必会

一个人可以走的更快 , 一群人可以走的更远

Android Perfetto 系列目录

随着 Google 宣布 Systrace 工具停更,推出 Perfetto 工具,Perfetto 在我的日常工作中已经基本能取代 Systrace 工具。同时 Oppo、Vivo 等大厂也已经把 Systrace 切换成了 Perfetto,许多新接触 Android 性能优化的小伙伴对于 Perfetto 那眼花缭乱的界面和复杂的功能感觉头疼,希望我能把之前的那些 Systrace 文章使用 Perfetto 来呈现。

所以就有了这个系列,我也有在星球里面写了几条为什么要更新 Perfetto 系列的原因(之前一直觉得 Systrace 系列就够了):

  1. 目前 Oppo、Vivo 这些手机厂商内部,都已经切换成 Perfetto 了,不管是抓 Trace 还是看 Trace,都在使用 Perfetto ,很多新人接触的都是 Perfetto 而不是 Systrace ,守着之前的老 Systrace 系列会流失这部分读者
  2. 之前的 Systrace 系列,对应的 Code 已经比较老了,全新的 Perfetto 系列可以使用 Android 14 的 Code 来进行更新
  3. 个人对 Perfetto 的使用也没有很深入,有些高阶功能目前还只是浅尝辄止。可以通过重写 Perfetto 系列来进行这部分内容的强化
  4. Perfetto 是个很强大的工具,他的背后是整个 Android + Linux 系统,所以在写这个系列的时候,应该是以他背后的这个 Android + Linux 为主,而不是仅仅局限于 Perfetto 这个工具。工具只是我们观测 Android + Linux 的方式,理解整个 Android 系统运行的规律,思考其运行的原理,通过工具挖掘问题,通过问题思考本质,这才是对开发者来说有意义的
  5. 很多 Android 系统运行相关的内容,Perfetto 的官方文档还是没有讲,这部分我这边可以作为补足;另外官方文档是英文版本的,中文博客可以补充这方面。
  6. Perfetto 系列写好了,可以拿到 Google Dev Fest 上作为演讲内容~。

Paul Graham 说:要么给大部分人提供有点想要的东西,要么给小部分人提供非常想要的东西。Perfetto 其实就是小部分人非常想要的东西,那就开始写吧,欢迎大家多多交流和沟通,发现错误和描述不准确的地方请及时告知我,我会及时修改,以免误人子弟。

本系列旨在通过 Perfetto 这个工具,从一个新的视角审视 Android 系统的整体运作方式。此外,它还旨在提供一个不同的角度来学习 App 、 Framework、Linux 等关键模块。尽管你可能已经阅读过许多关于 Android Framework、App 、性能优化的文章,但或许因为难以记住代码或不明白其运行流程,你仍感到困惑。通过 Perfetto 这个图形化工具,你可能会获得更深入的理解。

Perfetto 系列目录

  1. Android Perfetto 系列 1:Perfetto 工具简介
  2. Android Perfetto 系列 2:Perfetto Trace 抓取
  3. Android Perfetto 系列 3:熟悉 Perfetto View
  4. 待更新

欢迎大家在 关于我 页面加入微信群或者星球,讨论你的问题、你最想看到的关于 Perfetto 的部分,以及跟各位群友讨论所有 Android 开发相关的内容

Systrace 系列

另外 Systrace 工具尽管已经不更新了,但是之前的 Systrace 系列文章,内容依然没有过时,还是有很多公司在使用 Systrace 来分析各种系统问题,Systrace 工具是分析 Android 性能问题的利器,它可以从一个图形的角度,来展现整机的运行情况。Systrace 工具不仅可以分析性能问题,用它来进行 Framework 的学习也是很好的。

  1. Systrace 简介
  2. Systrace 基础知识 - Systrace 预备知识
  3. Systrace 基础知识 - Why 60 fps ?
  4. Systrace 基础知识 - SystemServer 解读
  5. Systrace 基础知识 - Input 解读
  6. Systrace 基础知识 - Vsync 产生与工作机制解读
  7. Systrace 基础知识 - Vsync-App :基于 Choreographer 的渲染机制详解
  8. Systrace 基础知识 - MainThread 和 RenderThread 解读
  9. Systrace 基础知识 - Binder 和锁竞争解读
  10. Systrace 基础知识 - Triple Buffer 解读
  11. Systrace 基础知识 - CPU Info 解读
  12. Systrace 基础知识 - SystemServer 解读
  13. Systrace 基础知识 - SurfaceFlinger 解读
  14. Systrace 流畅性实战 1 :了解卡顿原理
  15. Systrace 流畅性实战 2 :案例分析: MIUI 桌面滑动卡顿分析
  16. Systrace 流畅性实战 3 :卡顿分析过程中的一些疑问
  17. Systrace 响应速度实战 1 :了解响应速度原理
  18. Systrace 响应速度实战 2 :响应速度实战分析-以启动速度为例
  19. Systrace 响应速度实战 3 :响应速度延伸知识
  20. Systrace 线程 CPU 运行状态分析技巧 - Runnable 篇
  21. Systrace 线程 CPU 运行状态分析技巧 - Running 篇
  22. Systrace 线程 CPU 运行状态分析技巧 - Sleep 和 Uninterruptible Sleep 篇

关于我 && 博客

  1. 关于我 , 非常希望和大家一起交流 , 共同进步 .
  2. 博客内容导航
  3. 优秀博客文章记录 - Android 性能优化必知必会

一个人可以走的更快 , 一群人可以走的更远

2023 年的方方面面

今年偷个懒,找了个模版,主要从以下几个方面回顾过去一年:健康 / 锻炼、工作 / 职业、友情 / 社交、个人生活 / 家庭、学习 / 知识管理、旅游 / 文化、兴趣 / 创造、情绪 / 精神状况、财务状况。

内容更多是自己对于 2023 年的一个记录,算不上总结,文采也不好。不过很多事情,如果你不记录,就慢慢消失了。希望每次我翻看这篇记录的时候,都会感慨 2023 年真是丰富多彩的一年:有难忘的瞬间、有低谷、有朋自远方来、有去看大山大川;也会感慨有些事情做得很糟糕,如此这般其实可以做得更好;也会责备自己的懒惰,明明知道怎么做是对的,却因为懒惰没有去坚持。

各位看官一笑而过即可~

健康 / 锻炼

今年由于公司有骑行活动比赛,持续一整年,再加上成都环城绿道去年贯通,今年一整年的活动就是骑行。年初在闲鱼收了一个美利达瑞克多 4000,准备今年好好骑车。年初的目标是一圈(97km)骑到 3h 内,挑战目标是 2h 50min,没想到最终都达到了(总共骑了 35 圈绿道,最快用时是 2h 47min),如愿以偿在公司内部比赛中拿了第一名。同时把媳妇也带进了坑,一起骑了几圈。

自身叠加的那些 Debuff:哮喘、鼻炎,并没有明显的改善;不过最值得开心的是年底由于肺炎+甲流,住了 4 天院,打了四天吊瓶之后,鼻炎导致的味觉消失也被治好了,同时血氧也恢复到了 96% 以上(之前 always 在 94 以下,给我焦虑得不行)。成都的空气质量真是一言难尽,连华西的医生都直摇头,这一点想移居成都的同学可以慎重考虑一下。

新的一年还是得 骑车+跑步 一起抓,报了个都江堰半马,希望能完赛。减肥依然是主旋律,管住嘴迈开腿很重要,睡前保持饥饿感~

2023 年骑行数据

工作 / 职业

工作方面,今年不算很顺利,做的东西很杂,很多东西也没有最终落地,自己总结了一下,还是因为缺乏规划能力和执行力。不过也算积累了很多知识和做事方法,调研了很多技术方案,与客户也合作完成了几个项目。另外公司内部卧虎藏龙,需要虚心向每一个人学习。

AI 今年算是整了个大新闻,不管是公司还是个人,工作流中都插入了 AI 相关的内容:利用 AI 提升工作效率、创造 AI 相关的工具。不过由于公司性质,AI 还没有产生那种颠覆性的影响,不过我们都知道这一天很快就会来临。

“一种新技术一旦开始流行,你要么坐上压路机,要么成为铺路石。 —— Stewart Brand”

友情 / 社交

今年最重要的一次社交可能就是从成都去深圳参加 深圳 GDG DevFest 技术嘉年华,见到了几位老朋友和各位大佬,吃到了心心念念的砂锅粥和牛肉火锅,跟群里的小伙伴面了基,听了各位 GDE 的主题演讲,可谓是收获满满。

剩下的时间就是跟公司的几个小伙伴骑车了,能让大家周五晚上 12 点还在绿道上疯狂拉扯的,只有骑完之后那一顿火锅/麻辣烫了。@James @Hanzo @天宇 @宣总 @王 @陈大 @祥大 @果哥 @鹏哥 新的一年继续拉扯~

@福滕 和 @小陈 有了小宝宝,@周岩 的新房居然提前交房了(不过依然没有女朋友,狗头~)~,@老崔 跟 @和泉 都在深圳安家了。

交流最多的还是跟微信群里的小伙伴们,基本都是通过微信公众号或者博客添加的,基本都是 Android App 开发者或者国内的系统开发者,5 个群大概 2000 多人吧(虽然 90% 都是资深潜水员)。通过微信群认识了很多业内的大佬,手机圈本身就小,多个朋友多个家(狗头~),同时也感叹真是山外有山,人外有人,啥都别说了学就是了。

最大的感受是:最好跟在同一个频道上的人沟通,会减少很多沟通的成本。

个人生活 / 家庭

小宝宝橘橘快三岁了,橘橘妈也换了新的组(跟我做相同的工作:系统性能优化),一家人开开心心平平安安,就是最大的心愿了。今年由于各种原因,在家里陪宝宝和家人的时间有点少,出游计划也多被搁置。新的一年要提升效率,把时间多用在陪伴家人。

今天读到一个博主的 2023 年终总结,其中一段话让我感触很深,这才是生活的最终目标,不要本末倒置:

我希望多丰富一些体验,做一些没做过的事情,看一些没看过的风景。我希望 有一天可以把时间用在自己身上,而不是用在工作上,不是在那些不重要的人,或者事身上。更具体一点,我希望家人身体健康、平平安安,有爱,有陪伴,我也希望有一天可以走遍中国、走遍世界,看那些没看过的风景,吃那些没吃过的美食。

当我想到这里,我豁然开朗,我知道我终其一生追求的是什么,剩余的,都不重要的。那么,我怎样才可以?我需要时间,我需要钱。

从此开始,我所有的事情都围绕着这个目的展开,只要某件事情,对我的人生最终目的是有推进作用,无论多么艰难,我都必须做,是的,必须,没有任何商量的余地

学习 / 知识管理

今年学习方面一败涂地,英语学习基本上停滞,最后这个月才重新拾起来;技术学习更多停留在读,写和思考总结都比较少;文化学习,比如阅读,书架上的书很多,读完的很少;博客也只更新了几篇文章,费曼学习法那种输出倒逼输入,道理都懂,还是没有克服拖延症。

工作中倒是养成了一个习惯:在公司内部使用 Typora 记录每天的工作内容、技术专项、技术调研、Bug 记录等;新的一年切换到 Loop 之后,我会在上面更详细地记录和思考,以及组内分享,带动组内的技术氛围(今年年初吹下的牛皮年底了最终还是没有实现)。

从我自己的学习经历来看,学习有三大障碍:

  1. 如何获取优秀的输入源:互联网如此发达的年代,如何获取优秀的输入源很重要,这就需要在长期的学习过程中,记录那些优秀的人的博客、优质的 Github 库、高质量的周报、专注在技术输出上的技术团队等(话说我这篇文章:Android 性能优化必知必会 本意也是搜集这些内容的,欢迎大家推荐和自荐)。
  2. 静下心来把一个知识点吃透:短视频类的快消品在争夺人的注意力的同时,也把我们的耐心消耗殆尽,静下心来阅读和思考一篇文章、一个知识点、一本书,都成了一个很不容易的事情。这个只能自己锻炼自己,远离社交网络和短视频,重新夺回注意力,把心思放在真正需要的地方。
  3. 克服拖延症:我们常说,道理都懂,依然过不好,拖延症在里面功不可没。今天看到张朝阳分析治疗拖延症的方法,分析出来与君共勉:拖延症的关键关键就在于拖延本质上是因为不熟悉这件事情想要逃避,因而产生恐惧和焦虑,那战胜它的方法就是在想要拖延时,先在脑子里过一遍要做的事情,梳理好脉络,构想出细节,让自己的神经元兴奋,立即行动。这样可以战胜拖延,并感受到正反馈

年初看了李自然的一个视频:人生如逆旅,我亦是行人,视频主要是讲了下面几个点,当时感触很深,也分享给大家:【李自然说】人生如逆旅,我亦是行人

  1. 不给自己设限,能快速融入到更有潜力的行业
  2. 向顶级的人拼命地学习
  3. 拼命地打开自己的视野和格局
  4. 拥抱变化,甚至主动去求变
  5. 一直坚持做,就会有一个长期的口碑
  6. 提高容错率

旅游 / 文化

今年去了四个地方:四姑娘山,厦门,烟台+威海,乐山。

  1. 厦门:团队旅游目的地,看海,吃沙茶面,吃姜母鸭,不得不说厦门这天气太让人羡慕了,环海路也可以骑车,市内还有步道(可惜没去)。
  2. 烟台+威海:烟台+威海,先去参加 @小婉 的婚礼,然后回母校去看看见了几位老师和老同学,韩餐和海鲜都吃到了,环海路依然风景漂亮,学校后面的沙滩落日很美~
  3. 四姑娘山:开了一天车去到处于川西的四姑娘山,路上要经过海拔 4800 的垭口,宝宝和媳妇高反,没有怎么玩,很快就回来了。我们去的那天晚上下了雪,第二天到了景区后拍照很漂亮,我录了视频在这里:https://www.bilibili.com/video/BV1H84y1Q7oM ,漂亮是真漂亮,值得再去一趟~
  4. 乐山:看乐山大佛和吃小吃~甜皮鸭和炸串真好吃~

带着宝宝出去玩虽然很折腾,但是还是很值的,宝宝在一路上会认识很多新的东西,交新的朋友,吃到新的食物。2024 依然会继续带着宝宝折腾~

兴趣 / 创造

终于来到轻松一点的环节了,今年主要兴趣是骑车,购置了一台大疆 Action4 来拍骑车时候的视频,要技术没有,都是一镜到底,创造力这玩意是真得有天赋才行。

情绪 / 精神状况

自我感觉良好,除了稍微有一些焦虑。自我感觉良好很大程度上得益于家庭的支持,有爸妈在家帮忙看宝宝,我和媳妇双 it,很多决定媳妇都会坚定支持。成都美食比较多,比较杂,想吃哪种都可以吃到,玩的地方也比较多,川西、古镇、都江堰青城山,去重庆也不远;天府新区高新区这边也不怎么排外,呆着很舒服(除了雾霾,这个真的是负分)

2024 继续保持吧,心态要好,睡眠要好。

财务状况

房贷还剩余比较多,每个月工资大半都交给银行了,除了夫妻两个的工资基本没有其他的收入,这也是我目前比较焦虑的点,一旦遇到被辞退或者其他变故,周转就会有困难。所以最终目标还是要管好自己的钱袋子,控制花销。看了一个说法,分别是穷人、中产阶级、富人的资产负债情况:

  • 穷人疲于奔命,收入被衣食住行消耗殆尽。
  • 中产阶级深陷「老鼠赛跑」的陷进,为各种账单、贷款奋斗半辈子。
  • 富人买入并持有优质资产,形成「钱 → 资产 → 钱」的良性循环。

所以最终还是要持有 优质资产,我理解这里的优质资产可以是房产,也可以是知识。结合个人的情况,我思索再三,又重新开启了 知识星球,简介在这里 The Performance 知识星球简介,我并没有做宣传,只在博客中有介绍。我觉得目前最有效的两种学习方法:费曼学习法和公开学习法,知识星球都可以满足我,我会把日常的一些思考、案例、学习的进度、工具等分享到星球上;如果在这个过程中,有些知识能帮助到你,那么我觉得就值了。

最后三项

最骄傲的成就

今年可能最值得拿出来说的就是去了 电子科技大学 ,给研究生们上了三天的课,蹭的当然是公司跟企业合作这个便利,不过过程还是很值得一说的:从接到这个任务,到开始备课(其实就是学习 @鹏哥 去年准备的 PPT),再到每个知识点的学习,再到真正去讲课,还是充满了挑战的,毕竟是第一次,还好没有翻车。

今年好像还是我,这次就没那么紧张了,不过去年的内容要好好更新一下,讲课的方式需要再优化优化,知识点该深入的还是要继续深入,毕竟 Android 从最上层到最底层都讲清楚也不是那么容易的.

最大的挑战

工作方面的就不说了,除了工作方面,最大的挑战应该还是英语口语了,今年有好几次需要用到英语口语的时候,结果都不是那么好,这也刺激我要好好学英语。这个感觉要放到 2024 年最重要的 Task 里面,目前也有一些小的规划在实施中。

明年的目标和愿望

  1. 多陪陪家人,做一些之前没有做过的事情,去一些之前没有去过的地方。
  2. 至少做一次 Google Dev Fest 级别的公开分享
  3. 出一次国
  4. 坚持把知识星球做大做强
  5. 坚持锻炼身体,一次马拉松完赛
  6. 多看书
  7. 坚持每 2 周更新博客,提早把 Perfetto 系列写完
  8. 录视频

文笔有限,借用 aoxiang 的话来做个结尾吧:

很感谢对我的认可,你花时间看到这里,我很希望这篇文章对你有价值。同时,我也很希望你能想清楚「你想要过什么样的人生」,当你有了这个判定标准,你任何一个抉择,都会无比轻松。

「置顶」The Performance 知识星球简介

知识星球名为 The Performance,一个分享 Android 开发领域性能优化相关的圈子,主理人是博主自己,国内一线手机厂商性能优化方面的一线开发者,有多年性能相关领域的知识积累和案例分析经验,可以提供性能、功耗分析知识的一站式服务,涵盖了基础、方法论、工具使用和最宝贵的案例分析。

随着 Android 的发展,性能优化成了所有 Android 手机厂商和 App 厂商的重中之重。然而性能优化又是一个非常宽泛的话题,涉及到的知识非常多,从底层 Kernel 到 Framework 再到 App,每一个环节都有大量的知识点需要了解。所以笔者团队建立了这个专门分享和讨论 Android Performance 相关的技术圈:提供高质量的技术分享和技术讨论,提供系统性的 Android 性能优化相关知识的学习。

所有加入星球的同学,都可以畅所欲言,分享知识和案例,提问或者解答他人的问题,以问题分析带动学习,共同学习,共同进步,所有人都可以分享和讨论下面话题相关的内容,或者享受相关的权益。

目前星球的内容规划如下(两个 ## 之间的是标签,相关的话题都会打上对应的标签,方便大家点击感兴趣的标签查看对应的知识),由于改为个人经营,精力有限,划线部分是暂时删除。

  • Trace 分析 - 加入星球后,可以提供 1v1 的 Trace 教学和分析(Systrace、Perfetto、SimplePerf 等,需要提前预约),另外也会提供各种 Trace 相关的案例分析。
  • #The Performance# — 可以提早阅读「Android 性能优化 - 系统性课程」的电子书,每周会放出已经写好的章节。「Android 性能优化 - 系统性课程」 是我们规划的一本讲 Android 性能优化的电子书,目前开发者社区有相当多高质量的性能优化理论知识和实践文章和开源库,但是目前市面上缺乏一个完整的系统性的包含了性能优化原理工具实践等内容面向初级开发中和中级开发者面向 App 开发者和系统开发者,且持续更新的 Android 性能优化工具书。书的大纲 (暂定) 我们已经基本上列好了,预计会花费一年左右的时间来完成,在星球中会放出写好的章节,让大家提前看到,也欢迎大家一起进行 Review
  • #性能工具# — 分享 Android 开发中使用到的性能分析工具以及其使用方法,同时也提供 1V1 的 Systrace、Perfetto 等性能工具的视频指导。性能工具的使用,最好还是以视频的方式展示会直观很多,文章是静态的,很多地方比较难讲清楚,1V1 的视频会议指导也算是一个学习的方法。
  • #案例分析# — 典型案例分析思路总结、球友提供的案例分析与讨论。案例分析是学习的一个很重要的途径,阅读大量的实际性能案例对以后自己分析和解决性能问题是非常有帮助的,同时也欢迎大家提供案例和解决方法,怕泄露信息的话,我们会对关键信息进行打码。
  • #经典解读# — 经典方案、课程重读,例如优秀的三方库解析、Android 开发高手课重读等。比如可以对方案进行深度的剖析,横向对比等;对 Android 开发高手课进行重读和查漏补缺。
  • #知识分享# — 优秀文章、博客、工具分享。业界有很大大牛的博客、经过实际业务考验的开源方案、各种性能工具等,我们会寻找这些优秀的内容,分享给大家。
  • #知识沉淀# — 微信群聊精华、微信问答、博客留言解答等。
  • #性能面试# — Android 性能相关的面试题搜集和解答,也算是刚需了吧。
  • #编程语言# — 编程语言相关的使用技巧分享。
  • #效能提升# — 效能提升分享,包括开发者开发效能、工作效能提升方法、工程效率、工具推荐等,磨刀不误砍柴工嘛。
  • #行业动态# — 性能相关新技术第一时间解读报告,包括但不限于下面的内容。
    • 行业峰会、学术峰会新思路解读报告
    • 论文、行业、书籍介绍、视频
    • Android 大版本性能相关介绍
    • Android 新硬件性能相关内容介绍
    • Android 性能相关开源项目解读
  • #大咖分享# — 每月定期邀请行业大咖进行经验分享、案例分析。
  • #工作内推# — 各大厂商内推工作机会介绍。

付费星球二维码

微信扫码加入即可(iOS 用户最好用微信扫码)
付费知识星球

免费星球二维码

当然星球还有一个免费的版本,定位是知识分享,感兴趣的也可以加入

image-20231126142045297

微信公众号

当然也欢迎关注微信公众号~

微信扫一扫

微信群

新的微信交流群,没有加之前微信群都可以加这个,方便平时随时沟通和大家相互之间讨论

微信群旨在讨论 Android 及其相关的技术话题,包括但不限于 Android 性能优化课题(响应速度、流畅度、ANR、Crash、内存、耗电、性能监控等)Android App 开发、Framework 开发、Linux、大前端、面试分享、技术招聘等话题

鉴于群里的各位大佬们时间都很宝贵,大家聊天的内容尽量与上面的主题相关,禁止吹水、装机、购机、手机厂商优劣讨论……否则群会被贴上水群的标签,希望大家共同维护群氛围

另外还有 闲聊吹水群、跑步群、读书群、GPT 群,里面大家就随意发挥了,可以私我拉进去

如果群满 200 或者二维码失效,可以加我微信拉各位进去(553000664)

个人其他信息

  1. 博客地址:https://www.androidperformance.com/
  2. 免费知识星球:https://t.zsxq.com/ZZ337Am
  3. 付费知识星球 :https://t.zsxq.com/Fuvvf6y
  4. 知乎地址:https://www.zhihu.com/people/gracker  
  5. 即刻:https://okjk.co/pJbjFa
  6. Android Weekly :https://androidweekly.zhubai.love/
  7. 微信公众号:AndroidPerformance
  8. 掘金 :https://juejin.cn/user/1816846860560749

The Performance Design Of OS

1 Origin

I am embarking on a new series of articles addressing various considerations in OS architecture design. Indeed, these considerations are not limited to OS but are applicable to the design of any large-scale software.

I am limited by my capabilities and knowledge and bring a highly subjective view, and there are undoubtedly inadequacies. I am eager to hear different thoughts and perspectives, and through the collision of ideas, we can achieve a deeper understanding.

In my opinion, the core differences between Android and iOS from the OS perspective are primarily manifested in:

  1. The IPC mechanism between applications and core services
  2. Platform development environment, including programming languages, IDE tools, and the construction of the developer ecosystem
  3. Application lifecycle management mechanisms and strategies
  4. The runtime organizational structure of the kernel and core services

Why do they adopt different strategic decisions? It relates to the factors considered during architectural design. A software architectural decision is a selection of the most suitable decision for the present and foreseeable future amidst a series of current considerations; it is a collection of decisions. Thus, there’s no absolute right or wrong in architectural design, or rather, rational or irrational. Different projects and decision-makers face different considerations and prioritize different aspects. If architects of similar skill levels switch scenarios, they are likely to make similar decisions. This indicates that architectural design is an engineering process and a technical craft, learnable and following certain patterns.

The challenge in architectural design lies in accurately understanding the environment the organization operates within, current and foreseeable considerations, and finding the most suitable methodologies or tech stacks from existing engineering practices. It is evident that considerations play a significant role. What factors need to be considered in software architectural design? These include, but are not limited to, testability, component release efficiency, development efficiency, security, reliability, performance, scalability, etc. Experienced architects, especially those with operational experience in similar businesses, are better at discerning what to focus on at different times, what must be adhered to, and what can be relaxed or even abandoned. Considering the law of diminishing marginal returns, the consideration of influencing factors and decision-making behavior will permeate the entire lifecycle, introducing another art of decision-making.

We can summarize that:

  1. Under different stages and constraints of various considerations, software architectural designs on different projects may differ.
  2. During the entire cycle of software product iteration, such design decisions are always evolving.

Interestingly, one consideration may conflict with another, leading to a situation where one cannot have the best of both worlds. For example, improving component development efficiency might impact program performance. So, what were the considerations for the designers of Android and iOS in the context of mobile OS design? To answer this question, we first need to explain the relationship between the OS, application programs, and the kernel.

2 Mechanisms and Policies

First, it should be noted that the OS is part of the software stack above the hardware. It, along with application programs, constructs the complete software program stack, utilizing the hardware capabilities to provide services to users. From the hardware’s perspective, regardless of the OS or application programs, both are software; however, the OS has higher privileges, allowing it to operate in the CPU’s high-level modes, for tasks such as direct interaction with hardware and executing interrupt handling routines. From the software developer’s perspective, however, the OS and application programs are entirely different entities. Application programs utilize the capabilities provided by the OS to meet their business requirements or use hardware capabilities for tasks like playing music or storing data.

At a higher level, from the user experience perspective, application programs, OS, and hardware are all part of the same entity. When issues arise in their collaboration, ordinary consumers might simply feel that the device is less than ideal. Therefore, all three parties are obligated to cooperate and facilitate each other; only when the consumer is well-served can these entities sustainably profit.

In discussing the OS, it’s crucial to recognize that the vast majority of modern OSes consist of a kernel and system services.

  • In macOS/iOS, the kernel is Darwin, formed from the combination of XNU and the MACH microkernel. Its system services are provided by an array of daemon services, encapsulating kernel capabilities, data management, and higher-level APIs like display.
  • In Android, the kernel is the Linux kernel, with system services comprising C++ written daemon services (e.g., SurfaceFlinger) and Java written daemon services (e.g., SystemServer). They too encapsulate kernel capabilities, data management, and higher-level APIs concerning display rendering and composition.

Current mainstream operating systems include macOS, Windows, and various derivatives of Linux. Clearly, Android belongs to the Linux derivatives, with another renowned version in the developer community being Ubuntu. Due to the complexity and path-dependent nature of a complete OS, derivatives are often deployed on different hardware and application scenarios. For a while, Linux was lauded for its extensive device radiation and wide application scenario spectrum. However, being able to run an OS and running it well—connecting hardware and application programs to offer an optimal user experience—are two different things.

An increasingly common understanding is that the OS’s mechanisms, policies, and closely associated application programs vary greatly depending on the application scenario.

For instance, even if based on the same Linux kernel, the use and system services built upon it for embedded devices, smartwatches, smartphones, large servers, or even smart cars are distinctly different, as are the operating strategies of application programs. The Linux kernel and device drivers can be seen as the bridge between hardware and system services—a standard bridge—but the vehicles and pedestrians traversing it are entirely distinct.

This leads to another classic OS design concept: mechanism and policy.

The “separation principle” noted in UNIX programming specifies the separation of policy from mechanism and interface from the engine. Mechanisms provide capabilities; policies dictate how those capabilities are used.

In this context, the memory management, process management, VFS layer, and network programming interfaces that Linux provides are mechanisms. Memory allocation and release mechanisms, process schedulers, frequency and core allocators, and different file systems are policies. Going further, identifying which processes interact with users and which are background tasks, synchronizing this information to the scheduler to determine the optimal process for the next scheduling window is fundamentally a policy built upon the Linux process management mechanism. Similarly, notifying future computational task requirements to the CPU frequency allocator for dynamic adjustment (DVFS) involves a policy and a mechanism.

For instance, all modern OSes support memory compression capabilities, but different OSes use this mechanism according to their own characteristics to best meet business needs. iOS exhibits process-level compression, while Android relies on Linux’s ZRAM.

Though OS mechanisms might be similar, policies are diverse. The extent of their differences depends on the OS designers’ understanding of their own business—meaning the application programs running on the OS and the kind of experience and services they aim to provide users. Early Android was essentially a desktop architecture, but modifications, especially by domestic manufacturers, have made it increasingly resemble iOS, aligning more with the system capabilities required by mobile device operating systems.

The OS for smartphones and smart cars probably faces a similar scenario—they cannot be directly transplanted.

One interesting aspect of policy is that implementing one policy often brings up another issue, necessitating the introduction of an additional policy. When one policy compensates for another, a chain forms, eventually creating a closed-loop mechanism. In other words, all policies must be in effect simultaneously to maximize the system’s benefits. When learning about a competitor OS’s policies, remembering this aspect is essential; otherwise, we might only grasp the superficial aspects, leading to “negative optimization” once the features are launched.

Now, narrowing it down to Android and iOS, where do their strategy designs originate?

3 Butts Decide Heads

Apple has released a series of operating systems including macOS, iOS, iPadOS, watchOS, and tvOS. The distinctions between them are not merely in brand names but are characterized by specific strategy variations. While they largely share underlying mechanisms, their strategies are distinctly different. For instance, the background running mechanism on iOS is vastly different from that on macOS. iOS resembles a “restricted version of multitasking,” while macOS offers genuine multitasking. Hence, it’s not that iOS can’t implement multitasking but rather a deliberate design decision.

Android, as we refer to it, is actually a project open-sourced by Google, known as AOSP (Android Open Source Project). Device manufacturers adapt AOSP and integrate their services based on their business models and understanding of target users. Apple is singular, but there are numerous device manufacturers, each with their own profit models and interpretations of user needs. They modify AOSP accordingly, and the market decides which version prevails.

From a technical perspective, AOSP is rich in mechanisms but lacks in strategies. Google has implemented these strategies within its GMS services. Users outside mainland China, like those using Pixel or Samsung phones, would experience Google’s suite of services. Although the ecosystem is considered subpar in China due to the proliferation of substandard apps, the situation is somewhat mitigated overseas, but still not comparable to Apple’s ecosystem.

Given Google’s less-than-ideal strategic implementation, domestic manufacturers in China have carved out space for themselves. The intense competition and the sheer volume of phone shipments in mainland China have led manufacturers to prioritize consumer feedback and innovative adaptations of AOSP.

The most significant difference between iOS and Android stems from their respective strategies, rooted in their initial service objectives and developmental goals.

Books like “Steve Jobs” and “Becoming Steve Jobs” touch upon the development of the iPhone and the discussions around AppStore. Jobs was initially resistant to allowing third-party app development on mobile devices due to concerns about power consumption, performance, and security. The initial intent was to create a device that offered an unparalleled user experience, not necessarily catering to every user demand.

As Apple had written the first batch of apps themselves, they amassed a wealth of insights on designing excellent embedded device applications, leading to the creation of effective API systems. This comprehensive approach from hardware to software was not for the sake of exclusivity, but a necessary path to crafting the best user experience.

Contrastingly, during 2007-2008, Android was focused on getting the system up and running. Android’s initial aim was to accommodate a vast array of app developers, leading to its favoring of Java, a popular language among developers and in the embedded device domain. Although Android later shifted to Android Studio, improving the development experience, it still lagged behind Apple’s Xcode in terms of application development and debugging tools.

Apple’s strong control over its app ecosystem, partly attributed to its powerful IDE tools, aids developers in solving problems rather than imposing constraints. Further, initiatives like LLVM, Swift, and SwiftUI underscore Apple’s commitment to facilitating superior app development to enhance the user experience.

The purpose of designing an OS is profit-oriented, and it should facilitate app developers in crafting quality programs. Apple has showcased that offering quality developer services can be instrumental in achieving optimal device experiences. A summary of insights gleaned from Apple’s approach includes:

  1. Building an OS is a means; delivering a complete and excellent experience is the end goal. Both the OS and device manufacturers may need to put in extra effort to achieve this objective.
  2. Serve app developers well, assist them in improving app quality, and even identify and diagnose app issues.
  3. Provide faster and more user-friendly APIs to efficiently meet the needs of app developers.
  4. An excellent IDE tool can serve developers well, enabling the development of superior apps, and ensuring the OS’s survival.

While Apple exercises absolute control, it also offers software services that are significantly above industry standards. Offering an OS is merely a means; understanding the nature of the relationship with developers and providing developer services, such as IDE, is a more profound consideration at the cognitive level.

4 Strategy of “Overload Protection”

The greatest feature of mobile devices is their portability, enabled by battery power. Besides, as handheld devices, they primarily rely on passive cooling since they don’t have an active cooling mechanism (exceptional cases of gaming phones and attachable fans aside). Currently, there are two trends: one, the transistor fabrication process is inching closer to its physical limit, and two, more functionalities are being integrated into a single chip. This increase in the number of active transistors (or their area) leads to a corresponding rise in heat emission, although it wasn’t a primary concern during the early days of smartphones. Now, the balance between power consumption and performance has become a significant challenge for smartphones.

More active threads mean the CPU remains busy, resulting in reduced CPU time slices allocated to user-related programs, thus impacting performance. Therefore, the design of mobile device OSes naturally leads to restrictions on resource utilization by applications. If left unrestricted like servers or desktop computers, it would be impossible to maintain a balance between performance, power consumption, and heat dissipation. The more constrained a device is in terms of performance and power consumption, the stricter the control over application programs, as is the case with smartwatches.

Both Android and iOS have their resource protection mechanisms. In Android, the most common is the OOM (Out Of Memory) mechanism. When the heap memory usage of a Java application exceeds a certain threshold, the system terminates it. Although Android has a mechanism to detect excessive CPU usage, it is somewhat rudimentary and only monitors the CPU usage of regular applications, not system or native thread (written in languages other than Java).

In contrast, iOS has a plethora of mechanisms ranging from CPU, memory, to even restrictions on excessive IO writes, including:

  • Termination when the device overheats
  • Termination of VoIP class applications when there are excessive CPU awakenings
  • Termination during BackgroundTask execution if CPU use exceeds a threshold
  • Termination if BackgroundTask is not completed within the specified time
  • Termination if a program’s thread exceeds CPU use threshold
  • Termination if a program’s disk write volume exceeds a threshold
  • Termination if program’s inter-thread interactions within a unit time exceed a threshold
  • Termination if a program’s memory usage is exceeded
  • Termination under excessive system memory pressure
  • Termination if a program opens too many files
  • Termination during PageCache Thrashing

iOS outlines these behaviors in developer documentation to clarify the reasons for unexpected application exits.

Google’s lax approach to Android’s design has provided ample room for domestic manufacturers to introduce their overload protection strategies (similar to iOS’s, with minor variations) to ensure phones are not compromised by substandard applications. However, the issue lies in the lack of transparency about system termination behaviors. Developers are often in the dark about why their applications are terminated. Even if they are aware of the reasons, the lack of debugging information during termination impedes improvement efforts since no manufacturer releases this information.

Consequently, application developers resort to various “black technologies” to keep their applications alive and bypass the system’s detection mechanisms. What should have been a collaborative ecosystem building effort has turned into a battleground. In the end, both parties suffer, with consumers bearing the brunt of the damage.

In an ideal world:

  1. Overload protection mechanisms should be documented and explained in application development guides.
  2. Debugging information context should be saved when the system executes overload protection, and developers should have access to this information (with specific permissions, scope, and validity to be determined).
  3. Manufacturers should provide convenient and user-friendly debugging tools for developers to fix issues locally during development.
  4. Developers should be mandated to fix issues when they exceed the quality standards set by the manufacturers, failing which their applications should be delisted.

Manufacturers and developers should be partners. Manufacturers may need to do more to assist developers, as many capabilities are exclusive to them. Blaming developers solely for poor quality is not a competitive approach for manufacturers.

The fault, in this case, is at the cognitive level.

5 Strategy on “Lifecycle Management”

Different device forms pursue varied user experience requirements, leading to diverse OS design necessities. In desktop OS, the lifecycle of an application is entirely under its control, aiming to maximize the program’s potential. This design is viable because desktop computers are not constrained by power consumption and heat dissipation and rarely face performance bottlenecks. Their primary concern is exploiting the machine’s capabilities to the fullest.

On the contrary, smartphones are a different story due to their limitations in power consumption and heat generation. Similarly, smartwatches also suffer from these restrictions but to a more stringent degree. No one desires a watch that heats up their wrist and cannot last a day on a full charge. Moreover, their performance and memory limitations mean that too many apps can’t remain active in the background, necessitating a centralized management module to uniformly implement services for most common applications, known as a hosted architecture. While smart cars aren’t constrained by performance, power, or heat, they require high stability. Unless completely powered down, core system services must remain operational, emphasizing the importance of system anti-aging design.

A core strategy in smartphone OS design revolves around lifecycle management, determining the entire journey of an application from its inception to termination. Android leans towards desktop system design, offering a “looser” strategy and more room for developers to maneuver. In contrast, iOS imposes more restrictions; an application relegated to the background only has about 5 seconds to perform background tasks before entering the Suspend state. In this state, the application is denied CPU scheduling, rendering it “quiet” when in the background.

Chinese manufacturers, after obtaining AOSP code, have replicated a mechanism similar to iOS’s Suspend. However, due to the lack of native support in AOSP, compromises were made, resulting in an implementation not as thorough as iOS. Android interprets this running strategy as the developers’ responsibility to create well-crafted applications – a notion I find naive and impractical. By this logic, human societal development would never have required laws, an idea that contradicts human nature. Fortunately, Google might have realized this issue, gradually enhancing the so-called “freezing” strategy in their annual updates, albeit less effective than improvements made by domestic manufacturers. The progress in AOSP is slow, and substantial changes in this area aren’t expected in the next two to three years.

So, if an application is Suspended in the background on iOS, how can it perform required background computations? iOS introduced the BackgroundTask mechanism, allowing applications to request permission for background task execution, with the system intelligently scheduling these tasks. Hence, iOS offers a strategy for application background operation but places the final decision in the system’s hands. This allows the system to schedule background tasks based on the phone’s current status, avoiding task execution during high system load periods to reduce overall load. The system also assigns daily quotas to each application, incorporating execution frequency and duration as crucial factors. Generally, tasks are allowed about 30 seconds of execution before being terminated by the system.

However, background tasks aren’t limited to computations. How are requirements like playing music or location tracking addressed? Applications needing these services must declare them explicitly in the IDE, with the App Store checking for a match between the application and requested permissions – a mismatch leads to rejection. The App Store is central to iOS’s lifecycle management mechanism, enabling quality control during the application’s listing and operational phases. Applications identified as subpar are flagged for the developers to fix, facing delisting otherwise. Post-Suspend, the system may also terminate applications as part of overload protection. The most common reason is memory reclamation, especially given the expense of memory chips; without opting for larger memory, terminating applications is the only way to free up more memory.

So, if the application isn’t even running, how are background tasks executed, and messages received? Thanks to BackgroundTask design, even if an application is terminated, the system will automatically restart it to execute background tasks when conditions are met. Message reception is achieved through notification mechanisms, with two kinds: one displaying detailed content in the notification bar, activating the application only upon user interaction; the other is for VoIP class applications, capable of actively restarting terminated applications.

Android possesses a similar mechanism but requires the integration of its GMS service. Due to uncertain reasons, this service is inaccessible in China, forcing domestic apps to rely on various “dark arts” and commercial collaborations to keep their programs alive in the background for message reception. This has led to a grotesque scenario where head applications, often used by users, are greenlit by manufacturers, who, upon realizing this trend, keep intensifying various services, treating the phone as their playground and squeezing every bit of system memory. Could manufacturers offer a notification service akin to this? They could, but the construction and operational costs are disproportionately high compared to their sales profits, leading to the only option of increasing memory capacity, passing the price pressure onto consumers. The overall cost of a complete machine has an upper limit; bolstering memory means cutting corners elsewhere. For domestic manufacturers to break into the high-end market, recognizing the issues in the entire loop and co-building the ecosystem with applications is the sole breakthrough.

Looking at iOS’s design, compared to macOS, it restricts application freedom but isn’t a one-size-fits-all solution. It offers various “windows of opportunity” or “unified solutions” to cater to different developers’ needs. The objective is to allow developers to operate within reasonable boundaries, not to drain users’ battery and performance.

Summarizing the principles beyond the technology:

  • Mobile devices have many constraints; therefore, application “freedom” must be restricted but not completely cut off, requiring corresponding solutions.
  • Common tasks among applications should be provided uniformly by the system, saving overall system load, especially crucial for devices with many constraints.
  • The final execution power of a program should be determined by the system, which, after synthesizing various information, schedules uniformly, benefiting the ultimate user experience protection.

At this point, it seems like a clash between two regimes: one valuing freedom and individual priority, and the other advocating unified arrangement and scheduling. Regardless of the regime type, the ultimate objective must be considered. If the aim is to offer the best device user experience, evidently, the latter regime has been proven right by the market.

6 Above Design

Looking back at the history of electronic consumer products, the development has mainly followed two themes: the democratization of professional equipment and the integration of multifunctionality (N in 1 style). The reliance on CPU computation is gradually being replaced by Domain Specific Architecture (DSA). Upon DSA, domain-specific programming languages and compilers are constructed, with GPU and Shader Language in the graphic processing domain serving as prime examples. The era where software reaps the benefits of CPU performance enhancement is drawing to a close, and DSA appears to be the opportunity for the next “great leap” in the coming decade.

M1 epitomizes the dividends brought by regular microarchitecture and manufacturing process, but its impact is magnified due to the subpar performance of competing products. When a product’s core components are supplied by specific manufacturers, its developmental ceiling is essentially predetermined. This underscores the oft-repeated adage that core technologies must be self-controlled. Besides its CPU capabilities, M1 excels in multimedia processing, especially in video stream processing scenarios, outperforming Intel chips substantially. These performance enhancements are attributed to the processor’s performance uplift in specific scenarios.

However, this doesn’t signify the end of the road for performance enhancements based on CPUs. As CPU performance enhancements stagnate, precise understanding of demands and optimizations of matrices and architectural designs to boost performance on existing CPUs become imperative. Profound insights into hardware, compilers, algorithms, and operating systems (both frameworks and kernels) are increasingly crucial. After optimizing business codes to a certain extent, focus inevitably shifts towards the underlying layers.

Accumulated experience from numerous failures is essential to anticipate issues and design optimal architectures and optimization matrices proactively. An optimization matrix refers to the necessity of an ensemble of complementary technologies, not just an OS, to deliver an exceptional experience. This includes IDEs, cloud collaboration, and accurate cognition. Offering a supreme experience is a daunting task, but the more one learns, the more possibilities become apparent. By the same token, maintaining a perpetual “awareness of one’s unawareness” is equally pivotal.

However, all these are contingent upon the designers’ ability to keep pace with their cognition.

Charlie Munger once articulated that investment isn’t merely about scrutinizing financial statements and trend charts. Psychology, sociology, political science, and even biology are intricately linked to it. Only by dismantling the barriers between disciplines and integrating contents from multiple fields without reservations can one perceive a world invisible to others. While I haven’t attained such an enlightenment, Munger’s insights offer invaluable lessons worthy of our learning. Deliberate cross-disciplinary and cross-field practice, coupled with reflective thinking, significantly augments the learning process.

“I leave my sword to those who can wield it.” - Charlie Munger

About Me && Blog

  1. About Me: I am eager to interact and progress together with everyone.
  2. Follow me on Twitter
  3. Blog Content Navigation
  4. Record of Excellent Blog Articles - Essential Skills and Tools for Android Performance Optimization

An individual can move faster, a group can go further.

OS 设计之性能设计

本文是之前星球里 Yingyun 大佬的文章,由于星球已经关闭,所以把这个关于 OS 性能设计的系列文章发到博客上

Yingyun 是资深性能优化专家,他对于系统优化有非常深入的见解,本身在国内各个手机大厂都呆过,他本人的博客还在休整中,等休整好了我再发出来,目前他在我们的微信群里很活跃,对本文有什么建议或者意见,或者说想咨询问题的可以加我们的微信群(加我微信 553000664,备注博客加群,我会拉你进去)

1 缘起

新开系列文章,OS 架构设计中的各种考量因素。其实不止 OS,在设计任何大型软件都涉及到此类内容。

能力与知识面有限,而且还带了非常主观的看法,肯定有不足之处。希望听到不同的思路与观点,通过观点的碰撞进而达到更进一步的认知。

我认为,Android 与 iOS 在 OS 角度看最核心的差异主要表现为:

  1. 应用与核心服务之间的 IPC 机制
  2. 平台开发环境,包括编程语言、IDE 工具、开发者生态建设
  3. 应用生命周期管理机制与策略
  4. 内核与核心服务的运行时组织结构

他们为什么会有不同的策略决策呢?这跟架构设计时的考量因素有关。一个软件架构设计决策是在当前一系列考虑因素中选择了对当前与可见的未来选择的最合适的决策,是一系列决策的集合。所以,架构的设计上没有绝对的对与错,或者说合理与不合理。因为不同项目、不同决策者所面临的的考虑因素、追求的侧重点是都不尽相同。 如果架构师的水平差不多,把他们互换下情境,那大概率上所做出的决策是差不多的。这说明架构设计是一个工程,是一个技术手艺,它是可以被习得且有规律可循的。

架构设计中的挑战,可能更多的是在于准确理解组织所处的环境、当前与可见未来所要满足的考量因素,并从已有工程实践中找出最合适的方法论或者技术栈。由此可见,考虑因素就起了重要作用,在软件架构设计里要考虑哪些因素呢?包括但不限于,可测试性、组件发布效率、组件开发效率、安全性、可靠性、性能、扩容性等等。有经验的架构师,特别是对类似业务有操盘经验,他更能把握好不同时期应该注重什么,哪些是必须坚持的,哪些是适当放开甚至舍弃的。考虑到边际收益递减,影响因素的考量与决策行为会贯穿整个生命周期,这又是另一个「决策艺术」了。

我们可以总结出:

  1. 不同阶段与不同考量因素的限制下,不同项目上软件架构设计可能是不同的。
  2. 软件产品迭代的整个周期内,这种设计决策是随时会发生。

有意思的是一个考量因素可能会与另外一个有冲突,会造成鱼和熊掌不可兼得局面。比如提高了组件开发效率但有可能会影响到程序性能。那针对一个移动 OS 的设计,当初 Android 与 iOS 的设计者们的考量因素是什么呢?为了回答这个问题,首先要解释 OS 与应用程序以及内核之间的关系。

2 机制与策略

首先要说明的是 OS 是硬件之上的软件栈的一部分,它与应用程序一道构建了完整的软件程序栈,通过发挥硬件的能力为用户提供服务。从硬件的角度看,甭管 OS 还是应用程序,它们都是软件,只是 OS 的权限比较高,可以在 CPU 的高级别模式下运行,比如用于直接跟硬件打交道、执行中断处理程序等。但是在软件开发者角度来看,OS 与应用程序,那可是完全不一样的。应用程序利用 OS 提供的能力,实现自身的业务需求、或者使用硬件的能力,比如播放音乐、存储数据等。

再拔高一个层次,在用户体验角度来看,应用程序、OS 以及硬件,都是一回事情。 当他们协作出现问题,普通消费者可能就觉得这台设备就不够理想。因此,这三方都有义务互相配合好、互相为彼此提供便利,只有把消费者伺候舒服了,这三家才有可持续的利润可赚。

当我们说到 OS,绝大部分现代 OS 是由内核(Kernel)跟系统服务组成。

  • 在 macOS/iOS 中,它的内核是 Darwin,而 Darwin 又是由 XNU 与 MACH 微内核组而成。它的系统服务,是由一大堆 daemon 服务提供,他们封装了内核的能力与数据管理、界面显示等级别的 API。
  • 在 Android 中,它的内核是 Linux 内核,它的系统服务既有 C++ 编写的 daemon 服务(如,SurfaceFlinger)、又有 Java 编写的 daemon 服务( 如,SystemServer),他们同样也是封装了内核的能力与数据管理、界面渲染与合成等级别的 API。

现在主流的操作系统有 macOS、Windows 以及基于 Linux 的各种衍生版本。显然,Android 是属于基于 Linux 的衍生版本,当然还有个在开发者圈子中更有名的延伸版本,那就是 Ubuntu。 由于一个完整的 OS 的复杂性与路径依赖特性,往往会将一个延伸版本部署到不同的硬件与不同的应用场景上。有一阵子 Linux 就是以此为标榜,即它辐射到了多少台设备,应用场景有多广之类。能运行一个 OS 跟是否运行得好,即把硬件、应用程序连接起来,提供了最优的用户体验,完全是两码事情。

一个越来越普遍的认知是,不同的应用场景下,所需要的 OS 的机制与策略以及与之紧密配合的应用程序,是完全不一样的。

比如,即使是基于同一个 Linux 内核,用于嵌入式设备、智能手表以及智能手机、大型服务器甚至是智能汽车,它们使用 Linux 的方式与构建在它之上的系统服务均是不一样的,当然应用程序的运行策略也不尽相同。Linux 内核与设备驱动可以理解为硬件与系统服务之间的桥梁,是一个标准的桥梁,但是跑在它上面的车辆与行人,是完全不同的。

这就要引申出另一个非常经典的 OS 设计理念,机制与策略。

UNIX 编程一书中有提到「分离原则:策略同机制分离,接口同引擎分离」,机制提供能力,策略提供能力方法。

其中,Linux 提供的内存管理、进程管理、VFS 层、网络编程接口均是机制。内存分配与释放机制、进程调度器、频率与核分配器以及不同的文件系统,他们均是策略。更进一步,由系统服务识别出哪些进程是跟用户有交互、哪些是后台任务,将此类信息同步到调度器后找出下一个调度周期窗口里的最佳进程,本质上也是基于 Linux 进程管理机制之上的策略。 同样道理,根据未来所需的计算任务需求将其信息通知到 CPU 频率分配器进行动态调整(DVFS),前者是策略后者是机制。

再比如,所有的现代 OS 都支持内存压缩能力,但是不同的 OS 要根据自身的特点来使用此机制,目的是尽可能满足业务特点。iOS 中可以看到针对进程级别的压缩,而 Android 中反倒是依赖 Linux 的 ZRAM。

OS 的机制或许类似,但是策略千差万别,他们之间的差异有多大,取决于 OS 设计者对自身业务的理解。 自身业务,指的是运行在 OS 之上的应用程序,到底要为用户提供什么样的体验与服务。早期的 Android 其实就是桌面机架构,随着国内厂家对它的魔改,反倒是越来越像 iOS 了,越来越符合一个移动设备操作系统所需要的系统能力了。

智能手机、智能汽车的 OS,估计也是同样局面,不可生搬硬套。

策略还有个很有意思的特点,当你实施一个策略的时候会引申出另外一个问题,为此你要引入另一种策略。当一个策略弥补另外一个策略,逐渐会形成一个链条,你会发现你形成了一个闭环的机制。 即,所有的策略同时生效,才能使你的系统发挥出最大的效益。 当我们学习竞品 OS 的策略的时候,一定要记得这一点,否则只学会了皮毛,功能上线后会带来更大的「负优化」。

那具体到 Android 与 iOS,他们的策略设计是从何而来?

3 屁股决定脑袋

苹果推出的操作系统有 macOS,iOS,iPadOS,watchOS 与 tvOS。它们之间并不是单纯的品牌名称差别,而是有具体的策略差异。底层的机制大部分有共享,但是策略却截然不同。iOS 上的后台运行机制与 macOS 就截然不同,iOS 更像是「限制版多任务」,而 macOS 是真正的多任务。所以,iOS 并不是不能实现多任务,而是它的有意为之。

我们所说的安卓,其实是谷歌开源的项目,即 AOSP(Android Open Source Project)。设备厂商拿到 AOSP 与与硬件的相关的代码之后会在此基础上加入自己的各种服务,这是基于它们自身的商业模式、目标用户的理解,所创造出来的。苹果只有一个苹果,但是设备厂家就有很多,它们各自的盈利模式跟对目标用户理解不同,在 AOSP 基础上魔改了一遭,至于哪个好,就让市场先生来做判断吧。

回到技术本身,AOSP 中有大量的机制但是缺乏策略。谷歌把这些策略实现在了 GMS 服务中。 如果你在非大陆地区使用安卓手机,如 Pixel、三星手机,会体验到谷歌的全家桶。大家都会说国内的生态比较烂,垃圾应用比较多,到了海外这可能会缓解。 其实也就那样,谷歌的生态控制跟影响能力跟苹果是没法比的。

连谷歌自身的策略表现不尽人意,那就更为国内厂商发挥拳脚腾出了空间。中国大陆手机出货量累计合是全球最大的,而且竞争尤为激烈。因此它们会非常重视消费者的反馈,各种各样的需求与痛点挖掘,自然不在话下。 简单总结就是,国内厂商更懂消费者的需求,这也是国内厂家对 AOSP 做各种魔改与优化成立的底层逻辑了。

所以当你再次见到有个老板说 “做手机很简单嘛,拿开源安卓跟厂商的方案整合一下就行了”,离他赶紧远一点,跟着他混简直就是枉费青春。

iOS 与安卓之间两者最大的差异来自于策略,他们之间拥有的机制都差不多顶多效率上可能有差异,但更大的差异来自于策略上。

这跟它两刚开始时不同的服务对象与发展目标,导致了技术选型上的巨大差异。

「乔布斯传」与「成为乔布斯」两本书中,关于 iPhone 研发章节中都提到过关于 AppStore 的讨论。起初乔布斯坚持认为移动设备上由于功耗 / 性能与安全的考虑,不允许让三方应用开发程序。由于系统复杂,所以直接采用了 macOS 的内核以此实现多媒体、浏览器,以及播放音频与视频等功能。macOS 内核本身的运行成本较高,在此情况下再让三方应用运行,硬件根本吃不消。他们原本可以基于 iPod 上的系统实现 iPhone,但乔布斯又要实现世人从未见过的智能手机,上马 macOS 也是他不得已的选择。

随着第一代 iPhone 在用户侧的成功(商业上成功还没有开始),大家都在呼吁在 iTunes 上可以下载应用程序。其实第一代黑客们就是这么做的,因为很多 API 是跟 macOS 共享,因此通过一些逆向手段观察到了 iPhone 上编写应用程序的方法。但乔布斯坚决反对,因为还是担心这会破坏安全性跟设备使用体验。从此处就能看出,乔布斯的目的是打造一个拥有完美用户体验的设备,用户的呼吁或者需求,其实是并不是首要的。

但 VP 们不这么想,由于之前的 iTunes + iPod 组合的成功,VP 们私底下开始安排相关的工程研究了。直到后来来乔布斯也没有再坚持反对,只是说自己不再管了。

对 UX 界面的优雅性,特别是图标与界面的一流体验是刻在苹果骨子里的基因。即使是开放出 API,他们也对整个应用运行机制做了修改,从此开始与 macOS 上的程序执行策略有差异了。

由于第一批应用都是苹果自己写的,因此他们积攒了大量在嵌入式设备上良好设计的应用应该是怎样的,也设计出了非常有效的 API 体系。 在这种局面下,苹果有自己的 OS、自己的 IDE、自己的商店系统(当时还是跟 iTunes 共用),自然而然会设计出「最佳应用」应该长什么样。

这里头缺一不可,还记得前面提到过的观点吗? 当你要实施一个策略的时候,可需要另一个策略来解决前一个策略带来的问题,当策略变多的时候就有可能形成了一个环路。

从这儿可看出,为了打造出一个完美的体验,从硬件到软件全部打通,是必然的结果。 这不是为了封闭而封闭,而是为了打造最佳体验而做出的唯一一条路。

反观 07 - 08 年的 Android 阵营,他们还在忙着如何让系统跑起来。

在由 Cheet 著作的 「The Team That Built the Android Operating Systems」书中讲述了安卓从零开始被 Andy Rubin 创建的过程。它是由 Andy Rubin 离职后创业的公司,起初目标是给相机提供 OS。但是随着市场的演变,他们的目标变成了提供给移动设备,特别是手机的移动操作系统。Andy 当初的目标是创建一种可以平衡开发者与设备制造商以及运营商利益的真正意义上的完全开放的操作系统。这就要求它尽可能采用市面上已有的组件,将他们简单改在后适应嵌入式环境后快速部署上线。毕竟是有创业压力嘛,也不可能精雕细琢,只能用快速发展来解决各种体验问题了(主要是这时候 iPhone 还没出来)。再加上从零开始,他们没有配套的 IDE,也只能先提供简单的基于命令行的工具来构建应用程序, 因此从开始他们就缺乏整个应用运行环境的管控能力。不过这也是相对于苹果而言,毕竟两者的目的完全不同。

Android 的目标之一就是有大量应用程序可用,因此照顾到市面上人群最多的开发者是很想当然的思考方式。当时市场上开发者最多的编程语言是 Java,而 Java 在嵌入式领域里也是很受欢迎的。你可能很难相信,07 年的时候嵌入式设备性能很差,但为什么会是受欢迎的编程语言呢? 个人理解原因是,除特殊设备之外大部分设备其实不关心性能,基本维持在能用就行的程度。而且 Java 的可移植性,也大大降低了开发者的负担。为了使 Java 速度更快,Andy 团队还聘请了一位大神重新写一套适合嵌入式设备的虚拟机,这在当时看来都是正确的选择,只是没有 iPhone 出来之前。 不过运气好在,智能手机刚好碰上了黄金的 CPU 单核性能与制程爆发的十年,因此它跟 iOS 相比并没有逊色太多。

在安卓开发的早期,使用的是基于 Eclipse 的构建与开发工具,虽然谈不上非常优秀但是够用。但是痛苦的根源来源于对比,苹果很早之前开始构建自己的 IDE 工具,即 Xcode。这套工具里集成了大量的应用开发与调试以及分发功能,这极大的提高了应用开发工程师的效率。 虽然安卓将开发环境切入到 AndroidStudio 之后相比之前进步了很多,但这主要还是得益于 IntelliJ 本身的优秀,单纯应用开发角度来看跟 Xcode 相比还是弱了一些。Xcode 提供了非常方便的编写与调试程序性能的工具,这会使开发者通过简单的学习就能快速找出程序上低性能的代码段,大大提高了程序的质量而且还使整个过程很愉快,这在安卓上可不是这么一回事了。

由此可见,苹果能够在应用生态管控上的强势,其中一个重要的原因是得益于它的强大的 IDE 工具,提供方便的来帮助开发者解决问题,而不是一味地给他们压力。更进一步,LLVM、Swift 以及 SwiftUI,这些都是苹果了编写出更好地应用而所做的基础工具与语言。 目的当然是为了自身应用生态的发展,为消费者提供最佳的体验。 它的思路是尽可能服务好开发者,让他们编写更能契合系统机制的应用程序,即给你限制又给你解决方案。

设计 OS 的目的是盈利,因此要想办法帮助应用开发者开发好程序。很多 OS 提供了能力之后,应用如何编写就不归他们管了,他们往往会把这个责任放到应用开发者身上,从苹果身上可以看到,这种做法可能不利于整个设备的最优体验,吃亏的还是消费者自己以及厂商,因为把消费者给磨没了。

所以当我看到苹果的强大时候,除了硬件的强大,在软件生态的建设上面的思路是非常值得借鉴的,简单总结就是:

  1. 构建 OS 是手段,提供完整且优秀的体验是目的,双方通力合作才能达到此目的。特别是 OS 与设备制造商,可能要做出更多的努力。
  2. 服务好应用开发者,努力帮助他们写好应用,甚至发现与诊断能出应用的问题,协助开发者改进应用程序。
  3. 提供更快更好用的 API,尽可能高效的满足应用开发者的需求。
  4. 通过优秀的 IDE 工具服务好开发者,让他们在此基础上开发更多更优秀的应用,OS 才能有更好的机会存活下去。

可以看到虽然苹果有绝对的话语权,但同时也提供了远超于行业平局水平的软件服务。 再次强调,提供 OS 只是手段,要认识到与开发者建立怎样的关系、提供怎样的开发者服务(如 IDE),是在认知层面更为有意的事情。

4 策略之「过载保护」

移动设备的最大特性就是可移动,它是由电池供电实现了可移动性。除此之外,由于是手持设备因此散热基本靠被动散热,没有主动散热一说(奇葩的游戏手机与外挂式风扇另说)。现在有两个趋势,其一是晶体管的制作工艺越来越趋近于物理极限,其二是越来越多的功能直接封装在同一颗芯片上。处于活跃状态的晶体管数量变大(或者面积)之后发热量也是蹭蹭往上涨,这在智能手机刚开始普及那一会儿倒不是主要的矛盾。对于智能手机来说,现在更大的矛盾是,功耗与性能的平衡。

活跃的线程多了,就会使 CPU 一直处于工作状态,当然分给用户相关程序的 CPU 时间片也会少一些,性能也就受到影响了。所以移动设备 OS 的设计上,就自然的引申出了要对应用程序的资源使用上的限制,如像服务器、台式机一样完全放开,性能与功耗是无法保证了(当然还有发热)。越是性能跟功耗约束大的设备,对应用程序的管控就越严苛,比如智能手表。

Android 与 iOS 各自均有资源保护机制,Android 中最为常见的当属 OOM 机制了。当 Java 应用的堆内存使用超过一定阈值之后,就会被系统终止。它也有 CPU 使用过度的检测,但从实现上比较简陋,而且只会监听普通应用程序的 CPU 使用量,不监控系统以及由 Native 编写的线程(不用 Java 写)。

iOS 中可谓百花齐放,从 CPU 到内存,甚至 IO 过多写入也有限制,具体为:

  • 设备过热时被终止
  • VoIP 类应用有过多 CPU 唤醒时被终止
  • 执行 BackgroundTask 时使用 CPU 超过阈值时会被终止(备注: BackgroundTask 是 iOS 上后台执行时的状态)
  • 执行 BackgroundTask 时没有在规定时间内完成时会被终止
  • 程序的线程使用 CPU 超过阈值时被终止
  • 程序写数据到磁盘的量超过阈值时被终止
  • 单位时间内程序的线程之间的交互超过阈值时被终止(如两个线程互相唤醒)
  • 程序的内存超标时被终止
  • 系统内存压力过大时被终止
  • 程序打开了过多的文件时被终止
  • 系统遭受 PageCache Thrashing 时被终止

显然不止于此(可见未来,iOS 会增加更多限制),但以上是跟普通应用开发者最为密切的。iOS 将这些行为写在了开发者文档,让开发者知道自己的应用被异常退出时的原因。

谷歌对 Android 设计上的” 放松 “ ,可就给国内厂家留出了很多发挥空间。各家都有各自的资源过载保护策略(与 iOS 的类似,仅有或多或少的差异),它们尽可能保护手机不会被垃圾应用给搞坏了。但问题也恰恰出在这部分,由于系统的查杀行为没有明文化,开发者不知道自己的应用为什么会被终止。 即使知道了原因,也无法获取被终止时的调试信息,也就没办法做改进,因为没有哪家会把这类信息开放给应用开发者。

这导致的结果是,应用开发者不得不想出各种各样的所谓黑科技来使自己保活、绕过系统的各种检测机制。本应该由开发者一起共建的生态,现在变成了两家的攻防战了。到最后,是两败俱伤,而其中最受伤的就是消费者。

理想中的世界:

  1. 明文化资源过载保护机制,写在应用开发文档上。
  2. 当系统进行过载保护时将上下文调试信息保存下来,开发者可以查阅此类信息(具体权限、范围、有效期可以另定。总之要有方法,可以由开发者拿到此类调试信息)。
  3. 厂商提供方便好用的调试工具,可以由开发者在本地进行开发时修复问题使用。
  4. 当超出厂商制定的质量标准水位线,责令开发者进行修复,若不修复则下架应用。

厂商跟开发者应当是合作关系,可能厂商要做更多的事情用于帮助开发者,因为很多能力只有厂家才有。只是一味地责怪质量差是开发者的问题,这种厂商我觉得不太会有竞争力。

在认知维度上,就已经错了。

5 策略之「生命周期管理」

不同的设备形态所追求的体验要求不同,因此对 OS 的设计要求也不尽相同。在桌面机 OS 中一个应用程序的生命周期完全是由自己掌控的,目的是尽可能发挥程序的能力。能这么设计的原因是桌面机里没有功耗跟散热的限制,很少也会有性能上的瓶颈。对它来说首要考虑的问题是如何把机器的能力榨干。

而在智能手机上却是另一种情况,原因是它有功耗跟发热的限制。与此类似,智能手表上也有功耗与散热的限制,但是它比手机设备更为严苛。谁都不希望手腕里戴着一个会发热的表,而且续航一天都撑不了。除此之外,由于它的性能跟内存受限,不能驻留太多的程序在后台,因此需要有一个集中式管理的模块来统一实现绝大部分常见应用的服务,即所谓的托管式架构。智能汽车虽然没有性能、功耗以及发热的限制,但是它对稳定性的要求非常高。除非是汽车彻底断电,核心系统服务需要保持一直运行,因此对系统防老化的设计尤为重要。

智能手机 OS 设计中一个核心策略是关于生命周期管理的,它决定了应用程序的由生到死的整个过程。Android 的设计上更偏向于桌面机系统,因此策略的设计上比较「宽松」,留给开发者的发挥空间比较多。而 iOS 上限制比较多,一个应用退到后台之后只有 5 秒左右的时间用于执行后台任务,随后便进入到 Suspend 状态。在这种状态下应用程序是得不到 CPU 调度执行,因此在后台的时候应用会比较「安静」。

国内厂家拿到 AOSP 代码之后实现了类似 iOS 的这种 Suspend 机制,不过碍于 AOSP 原生的不支持,因此做了很多让步,这导致了整体效果上不如 iOS 来的彻底。Android 把这种运行策略解释为把应用写好应用开发者的责任,而我觉得这个想法是幼稚且不切实际的。如果这个逻辑成立的话,人类发展历史上都不需要有法律了,这是违背人性的事情。 不过好在谷歌可能意识到了问题,每年的更新中也逐步完善了俗称「冻结」的策略。不过能力奇差,远不及国内厂商所做的改进。AOSP 的进步也是比较缓慢,目测未来两三年内,这部分的进步速度也会一直缓慢,没有实质性的改变。

如果应用在后台被 Suspend 住了,那在 iOS 上如何实现需要后台计算的任务呢? 它引入了 BackgroundTask 的机制,让应用程序申请后台执行任务权限,由系统智能的调度执行应用程序的后台任务。所以,iOS 是给了一套策略让应用程序执行后台任务,但是决定权是交给系统执行的。这有利于系统根据当时手机的不同的状态调度后台任务,比如系统负载比较高的时候就不会执行后台任务了,目的是降低系统整体的负载。系统给每个应用还设置了每日配额的概念,比如一天之内允许你最多执行多少次等等,当然执行时间也是其中一个很重要的考量因素。一般允许执行 30 秒左右,超过之后就会被系统终止了。

但是后台任务不止于计算一种,播放音乐、位置定位,这种需求如何处理? 应用想要使用此类服务,需要在 IDE 中显示声明之后才可以使用,App Store 会检查应用与所申请权限是否匹配,不匹配时不给予通过。App Store 是 iOS 能够实现这套生命周期管理机制的很核心的一环,通过它实现了在上架期与运行期间的质量管控。当发现一个应用的质量较差的时候,会通知开发者让其修复,否则就会下架应用。 继 Suspend 之后系统也会随之终止应用程序,目的是过载保护。最常见的理由是回收内存,毕竟内存芯片非常贵,不上大内存的前提 下只能通过终止应用来腾出更多的内存了。

那我连应用程序都不执行了,又怎么执行后台任务?接收消息呢? 得益于 BackgroundTask 的设计,即使应用被终止了,当条件满足的时候系统还会自动的拉起你的程序执行后台任务。至于消息接收,则是通过消息通知机制来实现。分为两种,一种是在通知栏里能看到具体的内容,只有用户当点击此通知的时候才会唤醒应用程序。另一种则是 VoIP 类应用,可以主动拉起被终止的应用程序。

其实 Android 也有类似的机制,但是需要配合它的 GMS 服务使用,由于不确定的原因这个服务在国内是无法使用。因此国内的 App 不得不又要上各种各样的黑科技、商业合作等手段,使自己的程序在后台保活用于接收消息。这就造成了一个非常畸形的局面,头部应用由于是用户常用的,因此厂商也对它一路开绿灯。而厂家也发现这个现象之后,不断加码各类的服务,把手机当做自己的来用,尽可能榨干系统内存。 那有没有可能厂商自己提供类似的通知服务呢? 有,但是由于建设与运营成本跟自己的销售利润完全不成比例,大家也就只能加大内存容量了,可以把价格压力传递到消费者身上。整机的成本是有上限的,在内存这部分加大那就要在其他地方减弱。国内厂家要突破高端,首先要意识到整个环路的问题所在,与应用共建整个生态才是唯一的破局之道。

纵观 iOS 的设计,相比于 macOS, 限制了应用的自由度,但也不是一刀切方案。而是尽可能的提供了各种各样的「窗口期」或者「统一的解决方案」,以满足开发者的不同需求。目的是尽可能让开发者在合理的范围内做事情,而不是榨干用户的电量与性能。

总结下技术之上的设计原则

  • 移动设备受限因素多,因此要对应用「自由度」给予限制但不能一刀切,需要给予对应的解决方案。
  • 应用之间的共性任务要由系统统一提供,可节省系统整体负担,这对限制因素较多设备尤为重要。
  • 程序最终执行权交由系统而定,由他综合各类信息之后统一调度,这有利于保护最终的用户体验。

写到此处,似乎是两个体制的碰撞,一个崇尚自由,个体优先、一个崇尚统一安排与调度。无论是哪种体制,要看最终目的是什么,如果是要提供最佳的设备用户体验,显然后者体制被市场证明是正确的。

6 设计之上

纵观电子消费品的发展史,以专业设备平民化、 N in 1 式的功能整合,两个主旋律方向发展。纯靠 CPU 的计算也会被专用硬件代替,比如 DSA (Domain Specific Architecture)。在 DSA 之上,会构建领域专用的编程语言与编译器,与之最接近的就是图形处理领域,如 GPU 与 Shader Language。 软件吃 CPU 性能提升的红利已经接近了尾声,下一个十年的「大飞跃」,目前看来也就这 DSA 机会点了。

M1 本身代表了正常的微架构与制程工艺带来的红利,只是友商阵营太拉跨,把这种差距拉大了。当一个产品的核心部件由某几个特定供应商提供的时候,基本上也判定了其发展上限。这也就是常说的核心技术要掌握自己手里,是同样的道理。M1 中除 CPU 能力外,它在多媒体处理,特别是视频流的处理场景下相比 Intel 芯片性能指标超出一大截,能实现这些性能提升的得益于处理器的特定场景下的性能提升。

但这不代表基于 CPU 的性能提升已经走到尽头,正是因为 CPU 性能提升的停滞,通过对需求的准确理解,优化矩阵与架构设计来实现在已有 CPU 上的性能提升,变得更为紧迫。对硬件、编译器、算法以及操作系统(框架与内核)的理解,变得越来越重要。因为当你优化到一定层度的业务代码之后,注意力必然会往底层走。

只有相当多的失败的经验,才能未雨绸缪,以高屋建瓴的方式设计出最佳的架构与优化矩阵。 优化矩阵是指为了提供一个极佳的体验,并不是由一个 OS 就能搞定,他要有相配套的其他技术一起支撑才能做好。比如 IDE、比如云端配合、以及正确的认知。 想要提供一个极致的体验,是非常难的事情,但也正因为如此,你会发现了解越多可做的事情就越多。同样道理,也有别样的说法 → 使自己始终处于「知道自己不知道」的状态。

不过以上成立的前提,是设计者的认知要跟得上。

查理芒格说过,投资不是看看财报,看看走势图就能做好的。除经济学与金融学外,心理学、社会学、政治学、甚至生物学都有关系。只有当你踏平学科间的隔阂,不设边界地把多个学科内容融合在一起之后,才能看到别人看不到的世界。 我当然也没达到这种境界,芒格给世人的经验是我们值得学习的宝贵经验。努力跨学科、跨领域的刻意练习,如果能在此基础上做到思考输出,那对学习更有帮助。

我的剑留给能够挥舞它的人 - 查理 芒格

关于我 && 博客

  1. 关于我 , 非常希望和大家一起交流 , 共同进步 .
  2. 博客内容导航
  3. 优秀博客文章记录 - Android 性能优化必知必会

一个人可以走的更快 , 一群人可以走的更远

微信扫一扫

当 App 有了系统权限,真的可以为所欲为?

前一段时间有个 App 很火,是 Android App 利用了 Android 系统漏洞,获得了系统权限,做了很多事情。想看看这些个 App 在利用系统漏洞获取系统权限之后,都干了什么事,于是就有了这篇文章。由于准备仓促,有些 Code 没有仔细看,感兴趣的同学可以自己去研究研究,多多讨论,对应的文章和 Code 链接都在下面:

  1. 深蓝洞察:2022 年度最 “不可赦” 漏洞
  2. XXX apk 内嵌提权代码,及动态下发 dex 分析
  3. Android 反序列化漏洞攻防史话

关于这个 App 是如何获取这个系统权限的,Android 反序列化漏洞攻防史话,这篇文章讲的很清楚,就不再赘述了,我也不是安全方面的专家,但是建议大家多读几遍这篇文章

序列化和反序列化是指将内存数据结构转换为字节流,通过网络传输或者保存到磁盘,然后再将字节流恢复为内存对象的过程。在 Web 安全领域,出现过很多反序列化漏洞,比如 PHP 反序列化、Java 反序列化等。由于在反序列化的过程中触发了非预期的程序逻辑,从而被攻击者用精心构造的字节流触发并利用漏洞从而最终实现任意代码执行等目的。

这篇文章主要来看看 XXX apk 内嵌提权代码,及动态下发 dex 分析 这个库里面提供的 Dex ,看看 App 到底想知道用户的什么信息?总的来说,App 获取系统权限之后,主要做了下面几件事(正常 App 无法或者很难做到的事情),各种不把用户当人了。

  1. 自启动、关联启动相关的修改,偷偷打开或者默认打开:与手机厂商斗智斗勇。
  2. 开启通知权限。
  3. 监听通知内容。
  4. 获取用户的使用手机的信息,包括安装的 App、使用时长、用户 ID、用户名等。
  5. 修改系统设置。
  6. 整一些系统权限的工具方便自己使用。

另外也可以看到,这个 App 对于各个手机厂商的研究还是比较深入的,针对华为、Oppo、Vivo、Xiaomi 等终端厂商都有专门的处理,这个也是值得手机厂商去反向研究和防御的。

最好我还加上了这篇文章在微信公众号发出去之后的用户评论,以及知乎回答的评论区(问题已经被删了,但是我可以看到:如何评价拼多多疑似利用漏洞攻击用户手机,窃取竞争对手软件数据,防止自己被卸载? - Gracker的回答 - 知乎 https://www.zhihu.com/question/587624599/answer/2927765317,目前为止是 2471 个赞)可以说是脑洞大开(关于 App 如何作恶)。

0. Dex 文件信息

本文所研究的 dex 文件是从 XXX apk 内嵌提权代码,及动态下发 dex 分析 这个仓库获取的,Dex 文件总共有 37 个,不多,也不大,慢慢看。这些文件会通过后台服务器动态下发,然后在 App 启动的时候进行动态加载,可以说是隐蔽的很,然而 Android 毕竟是开源软件,要抓你个 App 的行为还是很简单的,这些 Dex 就是被抓包抓出来的,可以说是人脏货俱全了。

由于是 dex 文件,所以直接使用 https://github.com/tp7309/TTDeDroid 这个库的反编译工具打开看即可,比如我配置好之后,直接使用 showjar 这个命令就可以

showjar 95cd95ab4d694ad8bdf49f07e3599fb3.dex

默认是用 jadx 打开,就可以看到反编译之后的内容,我们重点看 Executor 里面的代码逻辑即可

打开后可以看到具体的功能逻辑,可以看到一个 dex 一般只干一件事,那我们重点看这件事的核心实现部分即可

1. 通知监听和通知权限相关

1.1 获取 Xiaomi 手机通知内容

  1. 文件 : 95cd95ab4d694ad8bdf49f07e3599fb3.dex
  2. 功能 :获取用户的 Active 通知
  3. 类名 :com.google.android.sd.biz_dynamic_dex.xm_ntf_info.XMGetNtfInfoExecutor

1. 反射拿到 ServiceManager

一般我们会通过 ServiceManager 的 getService 方法获取系统的 Service,然后进行远程调用

2. 通过 NotificationManagerService 获取通知的详细内容

通过 getService 传入 NotificationManagerService 获取 NotificationManager 之后,就可以调用 getActiveNotifications 这个方法了,然后具体拿到 Notification 的下面几个字段

  1. 通知的 Title
  2. 发生通知的 App 的包名
  3. 通知发送时间
  4. key
  5. channelID :the id of the channel this notification posts to.

可能有人不知道这玩意是啥,下面这个图里面就是一个典型的通知

其代码如下

可以看到 getActiveNotifications 这个方法,是 System-only 的,普通的 App 是不能随便读取 Notification 的,但是这个 App 由于有权限,就可以获取

当然微信的防撤回插件使用的一般是另外一种方法,比如辅助服务,这玩意是合规的,但是还是推荐大家能不用就不用,它能帮你防撤回,他就能获取通知的内容,包括你知道的和不知道的

1.2. 打开 Xiaomi 手机上的通知权限(Push)

  1. 文件 :0fc0e98ac2e54bc29401efaddfc8ad7f.dex
  2. 功能 :可能有的时候小米用户会把 App 的通知给关掉,App 想知道这个用户是不是把通知关了,如果关了就偷偷打开
  3. 类名 :com.google.android.sd.biz_dynamic_dex.xm_permission.XMPermissionExecutor

这么看来这个应该还是蛮实用的,你个调皮的用户,我发通知都是为了你好,你怎么忍心把我关掉呢?让我帮你偷偷打开吧

App 调用 NotificationManagerService 的 setNotificationsEnabledForPackage 来设置通知,可以强制打开通知
frameworks/base/services/core/java/com/android/server/notification/NotificationManagerService.java

然后查看 NotificationManagerService 的 setNotificationsEnabledForPackage 这个方法,就是查看用户是不是打开成功了
frameworks/base/services/core/java/com/android/server/notification/NotificationManagerService.java

还有针对 leb 的单独处理~ 细 !

1.3. 打开 Vivo 机器上的通知权限(Push)

  1. 文件 :2eb20dc580aaa5186ee4a4ceb2374669.dex
  2. 功能 :Vivo 用户会把 App 的通知给关掉,这样在 Vivo 手机上 App 就收不到通知了,那不行,得偷偷打开
  3. 类名 :com.google.android.sd.biz_dynamic_dex.vivo_open_push.VivoOpenPushExecutor

核心和上面那个是一样的,只不过这个是专门针对 vivo 手机的

1.4 打开 Oppo 手机的通知权限

  1. 文件 :67c9e686004f45158e94002e8e781192.dex
  2. 类名 :com.google.android.sd.biz_dynamic_dex.oppo_notification_ut.OppoNotificationUTExecutor

没有反编译出来,看大概的逻辑应该是打开 App 在 oppo 手机上的通知权限

1.5 Notification 监听

  1. 文件 :ab8ed4c3482c42a1b8baef558ee79deb.dex
  2. 类名 :com.google.android.sd.biz_dynamic_dex.ud_notification_listener.UdNotificationListenerExecutor

这个就有点厉害了,在监听 App 的 Notification 的发送,然后进行统计

监听的核心代码

这个咱也不是很懂,是时候跟做了多年 SystemUI 和 Launcher 的老婆求助了....@史工

1.6 App Notification 监听

  1. 文件 :4f260398-e9d1-4390-bbb9-eeb49c07bf3c.dex
  2. 类名 :com.google.android.sd.biz_dynamic_dex.notification_listener.NotificationListenerExecutor

上面那个是 UdNotificationListenerExecutor , 这个是 NotificationListenerExecutor,UD 是啥?

这个反射调用的 setNotificationListenerAccessGranted 是个 SystemAPI,获得通知的使用权,果然有权限就可以为所欲为

1.7 打开华为手机的通知监听权限

  1. 文件 :a3937709-b9cc-48fd-8918-163c9cb7c2df.dex
  2. 类名 :com.google.android.sd.biz_dynamic_dex.hw_notification_listener.HWNotificationListenerExecutor

华为也无法幸免,哈哈哈

1.8 打开华为手机通知权限

  1. 文件 :257682c986ab449ab9e7c8ae7682fa61.dex
  2. 类名 :com.google.android.sd.biz_dynamic_dex.hw_permission.HwPermissionExecutor

2. Backup 状态

2.1. 鸿蒙 OS 上 App Backup 状态相关,保活用?

  1. 文件 :6932a923-9f13-4624-bfea-1249ddfd5505.dex
  2. 功能 :Backup 相关

这个看了半天,应该是专门针对华为手机的,收到 IBackupSessionCallback 回调后,执行 PackageManagerEx.startBackupSession 方法

查了下这个方法的作用,启动备份或恢复会话

2.2. Vivo 手机 Backup 状态相关

  1. 文件 :8c34f5dc-f04c-40ba-98d4-7aa7c364b65c.dex
  2. 功能 :Backup 相关

3. 文件相关

3.1 获取华为手机 SLog 和 SharedPreferences 内容

  1. 文件 : da03be2689cc463f901806b5b417c9f5.dex
  2. 类名 :com.google.android.sd.biz_dynamic_dex.hw_get_input.HwGetInputExecutor

拿这个干嘛呢?拿去做数据分析?

获取 SharedPreferences

获取 slog

4. 用户数据

4.1 获取用户使用手机的数据

  1. 文件 : 35604479f8854b5d90bc800e912034fc.dex
  2. 功能 :看名字就知道是获取用户的使用手机的数据
  3. 类名 :com.google.android.sd.biz_dynamic_dex.usage_event_all.UsageEventAllExecutor

看核心逻辑是同 usagestates 服务,来获取用户使用手机的数据,难怪我手机安装了什么 App、用了多久这些,其他 App 了如指掌

那么他可以拿到哪些数据呢?应有尽有~,包括但不限于 App 启动、退出、挂起、Service 变化、Configuration 变化、亮灭屏、开关机等,感兴趣的可以看一下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
frameworks/base/core/java/android/app/usage/UsageEvents.java
private static String eventToString(int eventType) {
switch (eventType) {
case Event.NONE:
return "NONE";
case Event.ACTIVITY_PAUSED:
return "ACTIVITY_PAUSED";
case Event.ACTIVITY_RESUMED:
return "ACTIVITY_RESUMED";
case Event.FOREGROUND_SERVICE_START:
return "FOREGROUND_SERVICE_START";
case Event.FOREGROUND_SERVICE_STOP:
return "FOREGROUND_SERVICE_STOP";
case Event.ACTIVITY_STOPPED:
return "ACTIVITY_STOPPED";
case Event.END_OF_DAY:
return "END_OF_DAY";
case Event.ROLLOVER_FOREGROUND_SERVICE:
return "ROLLOVER_FOREGROUND_SERVICE";
case Event.CONTINUE_PREVIOUS_DAY:
return "CONTINUE_PREVIOUS_DAY";
case Event.CONTINUING_FOREGROUND_SERVICE:
return "CONTINUING_FOREGROUND_SERVICE";
case Event.CONFIGURATION_CHANGE:
return "CONFIGURATION_CHANGE";
case Event.SYSTEM_INTERACTION:
return "SYSTEM_INTERACTION";
case Event.USER_INTERACTION:
return "USER_INTERACTION";
case Event.SHORTCUT_INVOCATION:
return "SHORTCUT_INVOCATION";
case Event.CHOOSER_ACTION:
return "CHOOSER_ACTION";
case Event.NOTIFICATION_SEEN:
return "NOTIFICATION_SEEN";
case Event.STANDBY_BUCKET_CHANGED:
return "STANDBY_BUCKET_CHANGED";
case Event.NOTIFICATION_INTERRUPTION:
return "NOTIFICATION_INTERRUPTION";
case Event.SLICE_PINNED:
return "SLICE_PINNED";
case Event.SLICE_PINNED_PRIV:
return "SLICE_PINNED_PRIV";
case Event.SCREEN_INTERACTIVE:
return "SCREEN_INTERACTIVE";
case Event.SCREEN_NON_INTERACTIVE:
return "SCREEN_NON_INTERACTIVE";
case Event.KEYGUARD_SHOWN:
return "KEYGUARD_SHOWN";
case Event.KEYGUARD_HIDDEN:
return "KEYGUARD_HIDDEN";
case Event.DEVICE_SHUTDOWN:
return "DEVICE_SHUTDOWN";
case Event.DEVICE_STARTUP:
return "DEVICE_STARTUP";
case Event.USER_UNLOCKED:
return "USER_UNLOCKED";
case Event.USER_STOPPED:
return "USER_STOPPED";
case Event.LOCUS_ID_SET:
return "LOCUS_ID_SET";
case Event.APP_COMPONENT_USED:
return "APP_COMPONENT_USED";
default:
return "UNKNOWN_TYPE_" + eventType;
}
}

4.2 获取用户使用数据

  1. 文件:b50477f70bd14479a50e6fa34e18b2a0.dex
  2. 类名:com.google.android.sd.biz_dynamic_dex.usage_event.UsageEventExecutor

上面那个是 UsageEventAllExecutor,这个是 UsageEventExecutor,主要拿用户使用 App 相关的数据,比如什么时候打开某个 App、什么时候关闭某个 App,6 得很,真毒瘤

4.3 获取用户使用数据

  1. 文件:1a68d982e02fc22b464693a06f528fac.dex
  2. 类名:com.google.android.sd.biz_dynamic_dex.app_usage_observer.AppUsageObserver

看样子是注册了 App Usage 的权限,具体 Code 没有出来,不好分析

5. Widget 和 icon 相关

经吃瓜群众提醒,App 可以通过 Widget 伪造一个 icon,用户在长按图标卸载这个 App 的时候,你以为卸载了,其实是把他伪造的这个 Widget 给删除了,真正的 App 还在 (不过我没有遇到过,这么搞真的是脑洞大开,且不把 Android 用户当人)

5.1. Vivo 手机添加 Widget

  1. 文件:f9b6b139-4516-4ac2-896d-8bc3eb1f2d03.dex
  2. 类名:com.google.android.sd.biz_dynamic_dex.vivo_widget.VivoAddWidgetExecutor

这个比较好理解,在 Vivo 手机上加个 Widget

5.2 获取 icon 相关的信息

  1. 文件:da60112a4b2848adba2ac11f412cccc7.dex
  2. 类名:com.google.android.sd.biz_dynamic_dex.get_icon_info.GetIconInfoExecutor

这个好理解,获取 icon 相关的信息,比如在 Launcher 的哪一行,哪一列,是否在文件夹里面。问题是获取这玩意干嘛???迷

5.3 Oppo 手机添加 Widget

  1. 文件:75dcc8ea-d0f9-4222-b8dd-2a83444f9cd6.dex
  2. 类名:com.google.android.sd.biz_dynamic_dex.oppoaddwidget.OppoAddWidgetExecutor

5.4 Xiaomi 手机更新图标?

  1. 文件:5d372522-b6a4-4c1b-a0b4-8114d342e6c0.dex
  2. 类名:com.google.android.sd.biz_dynamic_dex.xm_akasha.XmAkashaExecutor

小米手机上的桌面 icon 、shorcut 相关的操作,小米的同学来认领

6. 自启动、关联启动、保活相关

6.1 打开 Oppo 手机自启动

  1. 文件:e723d560-c2ee-461e-b2a1-96f85b614f2b.dex
  2. 类名:com.google.android.sd.biz_dynamic_dex.oppo_boot_perm.OppoBootPermExecutor

看下面这一堆就知道是和自启动相关的,看来自启动权限是每个 App 都蛋疼的东西啊

6.2 打开 Vivo 关联启动权限

  1. 文件:8b56d820-cac2-4ca0-8a3a-1083c5cca7ae.dex
  2. 类名:com.google.android.sd.biz_dynamic_dex.vivo_association_start.VivoAssociationStartExecutor

看名字就是和关联启动相关的权限,vivo 的同学来领了

直接写了个节点进去

6.3 关闭华为耗电精灵

  1. 文件:7c6e6702-e461-4315-8631-eee246aeba95.dex
  2. 类名:com.google.android.sd.biz_dynamic_dex.hw_hide_power_window.HidePowerWindowExecutor

看名字和实现,应该是和华为的耗电精灵有关系,华为的同学可以来看看

6.4 Vivo 机型保活相关

  1. 文件:7877ec6850344e7aad5fdd57f6abf238.dex
  2. 类名:com.google.android.sd.biz_dynamic_dex.vivo_get_loc.VivoGetLocExecutor

猜测和保活相关,Vivo 的同学可以来认领一下

7. 安装卸载相关

7.1 Vivo 手机回滚卸载

  1. 文件:d643e0f9a68342bc8403a69e7ee877a7.dex
  2. 类名:com.google.android.sd.biz_dynamic_dex.vivo_rollback_uninstall.VivoRollbackUninstallExecutor

这个看上去像是用户卸载 App 之后,回滚到预置的版本,好吧,这个是常规操作

7.2 Vivo 手机 App 卸载

  1. 文件:be7a2b643d7e8543f49994ffeb0ee0b6.dex
  2. 类名:com.google.android.sd.biz_dynamic_dex.vivo_official_uninstall.OfficialUntiUninstallV3

看名字和实现,也是和卸载回滚相关的

7.3 Vivo 手机 App 卸载相关

  1. 文件:183bb87aa7d744a195741ce524577dd0.dex
  2. 类名:com.google.android.sd.biz_dynamic_dex.vivo_official_uninstall.VivoOfficialUninstallExecutor

同上

其他

SyncExecutor

  1. 文件:f4247da0-6274-44eb-859a-b4c35ec0dd71.dex
  2. 类名:com.google.android.sd.biz_dynamic_dex.sync.SyncExecutor

没看懂是干嘛的,核心应该是 Utils.updateSid ,但是没看到实现的地方

UdParseNotifyMessageExecutor

  1. 文件:f35735a5cbf445c785237797138d246a.dex
  2. 类名:com.google.android.sd.biz_dynamic_dex.ud_parse_nmessage.UdParseNotifyMessageExecutor

看名字应该是解析从远端传来的 Notify Message,具体功能未知

6.3 TDLogcatExecutor

  1. 文件
    1. 8aeb045fad9343acbbd1a26998b6485a.dex
    2. 2aa151e2cfa04acb8fb96e523807ca6b.dex
  2. 类名
    1. com.google.android.sd.biz_dynamic_dex.td.logcat.TDLogcatExecutor
    2. com.google.android.sd.biz_dynamic_dex.td.logcat.TDLogcatExecutor

没太看懂这个是干嘛的,像是保活又不像,后面有时间了再慢慢分析

6.4 QueryLBSInfoExecutor

  1. 文件:74168acd-14b4-4ff8-842e-f92b794d7abf.dex
  2. 类名:com.google.android.sd.biz_dynamic_dex.query_lbs_info.QueryLBSInfoExecutor

获取 LBS Info

6.5 WriteSettingsExecutor

  1. 文件:6afc90e406bf46e4a29956aabcdfe004.dex
  2. 类名:com.google.android.sd.biz_dynamic_dex.write_settings.WriteSettingsExecutor

看名字应该是个工具类,写 Settings 字段的,至于些什么应该是动态下发的

6.6 OppoSettingExecutor

  1. 文件:61517b68-7c09-4021-9aaa-cdebeb9549f2.dex
  2. 类名:com.google.android.sd.biz_dynamic_dex.opposettingproxy.OppoSettingExecutor

Setting 代理??没看懂干嘛的,Oppo 的同学来认领,难道是另外一种形式的保活?

6.7 CheckAsterExecutor

  1. 文件:561341f5f7976e13efce7491887f1306.dex
  2. 类名:com.google.android.sd.biz_dynamic_dex.check_aster.CheckAsterExecutor

Check aster ?不是很懂

6.8 OppoCommunityIdExecutor

  1. 文件:538278f3-9f68-4fce-be10-12635b9640b2.dex
  2. 类名:com.google.android.sd.biz_dynamic_dex.oppo_community_id.OppoCommunityIdExecutor

获取 Oppo 用户的 ID?要这玩意干么?

6.9 GetSettingsUsernameExecutor

  1. 文件:4569a29c-b5a8-4dcf-a3a6-0a2f0bfdd493.dex
  2. 类名:com.google.android.sd.biz_dynamic_dex.oppo_get_settings_username.GetSettingsUsernameExecutor

获取 Oppo 手机用户的 username,话说你要这个啥用咧?

6.10 LogcatExecutor

  1. 文件:218a37ea-710d-49cb-b872-2a47a1115c69.dex
  2. 类名:com.google.android.sd.biz_dynamic_dex.logcat.LogcatExecutor

配置 Log 的参数

6.11 VivoBrowserSettingsExecutor

  1. 文件:136d4651-df47-41b4-bb80-2ec0ab1bc775.dex
  2. 类名:com.google.android.sd.biz_dynamic_dex.vivo_browser_settings.VivoBrowserSettingsExecutor

Vivo 浏览器相关的设置,不太懂要干嘛

评论区比文章更精彩

微信公众号评论区

image-20230514203931411

image-20230514203940833

image-20230514203951666

image-20230514204055973

image-20230514204002395

image-20230514204022808

image-20230514204042836

image-20230514204123412

image-20230514204200492

知乎评论区

知乎回答已经被删了,我通过主页可以看到,但是点进去是已经被删了:如何评价拼多多疑似利用漏洞攻击用户手机,窃取竞争对手软件数据,防止自己被卸载? - Gracker的回答 - 知乎 https://www.zhihu.com/question/587624599/answer/2927765317

image-20230514205638861

image-20230514205909534

image-20230514205857945

image-20230514205937705

image-20230514205947268

image-20230514210010062

image-20230514210020926

image-20230514210040479

image-20230514210107839

image-20230514210122906

image-20230514210141653

image-20230514210152755

image-20230514210226176

image-20230514210235233

image-20230514210255912

image-20230514210344475

iOS 和 Android 哪个更安全?

这里就贴一下安全大佬 sunwear 的评论

img

关于我 && 博客

  1. 关于我 , 非常希望和大家一起交流 , 共同进步 .
  2. 博客内容导航
  3. 优秀博客文章记录 - Android 性能优化必知必会

一个人可以走的更快 , 一群人可以走的更远

微信扫一扫

Systrace 线程 CPU 运行状态分析技巧 - Sleep 和 Uninterruptible Sleep 篇

本文是 Systrace 线程 CPU 运行状态分析技巧系列的第三篇,本文主要讲了使用 Systrace 分析 CPU 状态时遇到的 SleepUninterruptible Sleep 状态的原因排查方法与优化方法,这两个状态导致性能变差概率非常高,而且排查起来也比较费劲,网上也没有系统化的文档。

本系列的目的是通过 Systrace 这个工具,从另外一个角度来看待 Android 系统整体的运行,同时也从另外一个角度来对 Framework 进行学习。也许你看了很多讲 Framework 的文章,但是总是记不住代码,或者不清楚其运行的流程,也许从 Systrace 这个图形化的角度,你可以理解的更深入一些。Systrace 基础和实战系列大家可以在 Systrace 基础知识 - Systrace 预备知识 或者 博客文章目录 这里看到完整的目录

  1. Systrace 线程 CPU 运行状态分析技巧 - Runnable 篇
  2. Systrace 线程 CPU 运行状态分析技巧 - Running 篇
  3. Systrace 线程 CPU 运行状态分析技巧 - Sleep 和 Uninterruptible Sleep 篇

Linux 中的 Sleep 状态是什么

TASK_INTERUPTIBLE vs TASK_UNINTERRUPTIBLE

一个线程的状态不属于 Running 或者 Runnable 的时候,那就是 Sleep 状态了(严谨来说,还有其他状态,不过对性能分析来说不常见,比如 STOP、Trace 等)。

在 Linux 中的Sleep 状态可以细分为 3 个状态:

  • TASK_INTERUPTIBLE → 可中断
  • TASK_UNINTERRUPTIBLE → 不可中断
  • TASK_KILLABLE → 等同于 TASK_WAKEKILL | TASK_UNINTERRUPTIBLE

 "图 1: 性能之巅 2 CPU 优化"

在 Systrace/Perfetto 中,Sleep 状态指的是 Linux 中的TASK_INTERUPTIBLE,trace 中的颜色为白色。Uninterruptible Sleep 指的是 Linux 中的 TASK_UNINTERRUPTIBLE,trace 中的颜色为橙色。

本质上他们都是处于睡眠状态,拿不到 CPU的时间片,只有满足某些条件时才会拿到时间片,即变为 Runnable,随后是 Running。

TASK_INTERRUPTIBLE 与 TASK_UNINTERRUPTIBLE 本质上都是 Sleep,区别在于前者是可以处理 Signal 而后者不能,即使是 Kill 类型的Signal。因此,除非是拿到自己等待的资源之外,没有其他方法可以唤醒它们。 TASK_WAKEKILL 是指可以接受 Kill 类型的Signal 的TASK_UNINTERRUPTIBLE。

Android 中的 Looper、Java/Native 锁等待都属于 TAKS_INTERRUPTIBLE,因为他们可以被其他进程唤醒,应该说绝大部分的程序都处于 TAKS_INTERRUPTIBLE 状态,即 Sleep 状态。 看看 Systrace 中的一大片进程的白色状态就知道了(trace 中表现为白色块),它们绝大部分时间都是在 Runnning 跟 Sleep 状态之间转换,零星会看到几个 Runnable 或者 UninterruptibleSleep,即蓝色跟橙色。

TASK_UNINTERRUPTIBLE 作用

似乎看来 TASK_INTERUPTIBLE 就可以了,那为什么还要有 TASK_UNINTERRUPTIBLE 状态呢?

中断来源有两个,一个是硬件,另一个就是软件。硬件中断是外围控制芯片直接向 CPU 发送了中断信号,被 CPU 捕获并调用了对应的硬件处理函数。软件中断,前面说的 Signal、驱动程序里的 softirq 机制,主要用来在软件层面触发执行中断处理程序,也可以用作进程间通讯机制。

一个进程可以随时处理软中断或者硬件中断,他们的执行是在当前进程的上下文上,意味着共享进程的堆栈。但是在某种情况下,程序不希望有任何打扰,它就想等待自己所等待的事情执行完成。比如与硬件驱动打交道的流程,如 IO 等待、网络操作。 这是为了保护这段逻辑不会被其他事情所干扰,避免它进入不可控的状态

Linux 处理硬件调度的时候也会临时关闭中断控制器、调度的时候会临时关闭抢占功能,本质上为了 防止程序流程进入不可控的状态。这类状态本身执行时间非常短,但系统出异常、运行压力较大的时候可能会影响到性能。

https://elixir.bootlin.com/linux/latest/ident/TASK_UNINTERRUPTIBLE

可以看到内核中使用此状态的情况,典型的有 Swap 读数据、信号量机制、mutex 锁、内存慢路径回收等场景。

分析时候的注意点

首先要认识到 TASK_INTERUPTIBLE、TASK_UNINTERRUPTIBLE 状态的出现是正常的,但是如果这些这些状态的累计占比达到了一定程度,就要引起注意了。特别是在关键操作路径上这类状态的占比较多的时候,需要排查原因之后做相应的优化。 分析问题以及做优化的时候需要牢牢把握两个关键点,它类似于内功心法一样:

  1. 原因的排查方法
  2. 优化方法论

你需要知道是什么原因导致了这次睡眠,是主动的还是被动的?如果是主动的,通过走读代码调查是否是正常的逻辑。如果是被动的,故事的源头是什么? 这需要你对系统有足够多的认识,以及分析问题的经验,你需要经常看案例以增强自己的知识。

以下把 TASK_INTERUPTIBLE 称之为 Sleep,TASK_UNINTERRUPTIBLE称之为 UninterruptibleSleep,目的是与 Systrac 中的用词保持一致。

初期分析 Sleep 与 UninterruptibleSleep 状态的经验不足时你会感到困惑,这种困惑主要是来自于对系统的不了解。你需要读大量的框架层、内核层的代码才能从 Trace 中找出蛛丝马迹。目前并没有一种 Trace 工具能把整个逻辑链路描述的很清楚,而且他们有时候还有不准的时候,比如 Systrace 中的 wakeup_from 信息。只有广泛的系统运行原理做为支持储备,再结合 Trace 工具分析问题,才能做到准确定位问题根因。否则就是我经常说的「性能优化流氓」,你说什么是什么,别人也没法证伪。反复折磨测试同学复测,没测出来之后,这个问题也就不了了之了。

本文没办法列举完所有状态的原因,因此只能列举最为常见的类型,以及典型的实际案例。更重要的是,你需要掌握诊断方法,并结合源代码来定位问题。

Trace 中的可视化效果

Pefetto 中支持显示的状态

Systrace 支持显示的状态

Sleep 状态分析

图 1: UIThread 等待 RenderThread

图 2: Binder 调用等待

诊断方法

通过 wakeup from tid: ***查看唤醒线程

Sleep 最常见的有图 1(UIThread 与 RenderThread 同步)的情况与图 2(Binder 调用)的情况。 Sleep 状态一般是由程序主动等待某个事件的发生而造成的,比如锁等待,因此它有个比较明确的唤醒源。比如图 1,UIThread 等待的是 RenderThread,你可以通过阅读代码来了解这种多线程之间的交互关系。虽然最直接,但是对开发者的要求非常高,因为这需要你熟读图形栈的代码。这可不是一般的难度,是追求的目标,但不具备普适性。

更简单的方法是通过所谓的 wakeup from tid: *** 来调查线程之间的交互关系。从前面的 Runnable 文章 中讲过,任何线程进入 Running 之前会先进入到 Runnable 状态,由此再转换成 Running。从 Sleep 状态切换到 Running,必然也要经过 Runnable。

进入到 Runnable 有两种方式,一种是 Running 中的程序被抢占了,暂时进入到 Runnable。还有一种是由另外一个线程将此线程(处于 Sleep 的线程)变成了 Runnable。

我们在调查Sleep 唤醒线程关系的时候,应用到的原理是第二种情况。在 Systrace 中这种是被 wakeup from tid: *** 信息所呈现。线程被抢占之后变成 Runnable,在 Systrace 中是被 Running Instead 呈现。

需要特别注意的是 wakeupfrom 这个有时候不准,原因是跟具体的 tracepoint 类型有关。分析的时候要注意甄别,不要一味地相信这个数据是对的。

其他方法

  1. Simpleperf 还原代码执行流
  2. 在 Systrace 寻找时间点对齐的事件

方法 1 适合用来看程序到底在执行什么操作进入到这种状态,是 IO 还是锁等待?球里连载 Simpleperf 工具的使用方法,其中「Simpleperf 分析篇 (1): 使用 Firefox Profiler 可视分析 Simpleperf 数据」介绍了可以按时间顺序看函数调用的可视化方法。其他使用也会陆续更新,直接搜关键字即可。

方法 2 是个比较笨的方法,但有时候也可以通过它找到蛛丝马迹,不过缺点是错误率比较高。

耗时过长的常见原因

  • Binder 操作 → 通过打开 Binder 对应的 trace,可方便地观察到调用到远端的 Binder 执行线程。如果 Binder 耗时长,要分析远端的 Binder 执行情况,是否是锁竞争?得不到CPU 时间片?要具体问题具体分析
  • Java\futex锁竞争等待 → 最常见也是最容易引起性能问题,当负载较高时候特别容易出现,特别是在 SystemServer 进程中。这是 Binder 多线程并行化或抢占公共资源导致的弊端。
  • 主动等待 → 线程主动进入 Sleep 状态,等待其它线程的唤醒,比如等待信号量的释放。优化建议:需要看代码逻辑分析等待是否合理,不合理就要优化掉。
  • 等待 GPU 执行完毕 → 等 GPU 任务执行完毕,Trace 中可以看到等 GPU fence 时间。常见的原因有渲染任务过重、 GPU 能力弱、GPU 频率低等。优化建议:提升 GPU 频率、降低渲染任务复杂度,比如精简 Shader、降低渲染分辨率、降低Texture 画质等。

UninterruptibleSleep 状态分析

诊断方法

本质上UninterruptibleSleep 也是一种 Sleep,因此分析 Sleep 状态时用到的方法也是通用的。不过此状态有两个特殊点与 Sleep 不同,因此在此特别说明。

  1. UninterruptibleSleep 分为 IOWait 与 Non-IOWait
  2. UninterruptibleSleep 有 Block reason

UninterruptibleSleep 分为 IOWait 与 Non-IOWait

IO 等待好理解,就是程序执行了 IO 操作。最简单的,程序如果没法从 PageCache 缓存里快速拿到数据,那就要与设备进行 IO 操作。CPU 内部缓存的访问速度是最快的,其次是内存,最后是磁盘。它们之间的延迟差异是数量级差异,因此系统越是从磁盘中读取数据,对整体性能的影响就越大。

非 IO 等待主要是指内核级别的锁等待,或者驱动程序中人为设置的等待。Linux 内核中某些路径是热点区域,因此不得不拿锁来进行保护。比如Binder 驱动,当负载大到一定程度,Binder 的内部的锁竞争导致的性能瓶颈就会呈现出来。

Block Reason

谷歌的 Riley Andrews(riandrews@google.com) 15年左右往内核里提交了一个 tracepoint 补丁,用于记录当发生 UninterruptibleSleep 的时候是否是 IO 等待、调用函数等信息。Systrace 中的展示的 IOWait 与 BlockReason,就是通过解析这条 tracepoint 而来的。这条代码提交的介绍如下(由于这笔提交未合入到 Linux 上游主线,因此要注意你用的内核是否单独带了此补丁):

1
2
3
4
5
6
7
sched: add sched blocked tracepoint which dumps out context of sleep.
Decare war on uninterruptible sleep. Add a tracepoint which
walks the kernel stack and dumps the first non-scheduler function
called before the scheduler is invoked.

Change-Id: [I19e965d5206329360a92cbfe2afcc8c30f65c229](https://android-review.googlesource.com/#/q/I19e965d5206329360a92cbfe2afcc8c30f65c229)
Signed-off-by: Riley Andrews [riandrews@google.com](mailto:riandrews@google.com)

在 ftrace(Systrace 使用的数据抓取机制) 中的被记录为

1
sched_blocked_reason: pid=30235 iowait=0 caller=get_user_pages_fast+0x34/0x70 

这句话被 Systrace 可视化的效果为:

主线程中有一段 Uninterruptible Sleep 状态,它的 BlockReason 是 get_user_pages_fast。它是一个 Linux 内核中函数的名字,代表着是线程是被它切换到了 UninterruptibleSleep 状态。为了查看具体的原因,需要查看这个函数的具体实现。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
/**
* get_user_pages_fast() - pin user pages in memory
* @start: starting user address
* @nr_pages: number of pages from start to pin
* @gup_flags: flags modifying pin behaviour
* @pages: array that receives pointers to the pages pinned.
* Should be at least nr_pages long.
*
* Attempt to pin user pages in memory without taking mm->mmap_lock.
* If not successful, it will fall back to taking the lock and
* calling get_user_pages().
*
* Returns number of pages pinned. This may be fewer than the number requested.
* If nr_pages is 0 or negative, returns 0. If no pages were pinned, returns
* -errno.
*/
int get_user_pages_fast(unsigned long start, int nr_pages,
unsigned int gup_flags, struct page **pages)
{
if (!is_valid_gup_flags(gup_flags))
return -EINVAL;

/*
* The caller may or may not have explicitly set FOLL_GET; either way is
* OK. However, internally (within mm/gup.c), gup fast variants must set
* FOLL_GET, because gup fast is always a "pin with a +1 page refcount"
* request.
*/
gup_flags |= FOLL_GET;
return internal_get_user_pages_fast(start, nr_pages, gup_flags, pages);
}
EXPORT_SYMBOL_GPL(get_user_pages_fast);

从函数解释上可以看到,函数首先是通过无锁的方式pin 应用侧的 pages,如果失败的时候不得不尝试持锁后走慢速执行路径。此时,无法持锁的时候那就要等待了,直到先前持锁的人释放锁。那之前被谁持有了呢?这时候可以利用之前介绍的Sleep 诊断方法,如下图。

UninterruptibleSleep 状态相比 Sleep 有点复杂,因为它涉及到 Linux 内部的实现。可能是内核本身的机制有问题,也有可能是应用层使用不对,因此要联合上层的行为综合诊断才行。毕竟内核也不是万能的,它也有自己的能力边界,当应用层的使用超过其边界的时候,就会出现影响性能的现象。

IOWait 常见原因与优化方法

1. 主动IO 操作

  • 程序进行频繁、大量的读或者写 IO 操作,这是最常见的情况。
  • 多个应用同时下发 IO 操作,导致器件的压力较大。同时执行的程序多的时候 IO 负载高的可能性也大。
  • 器件本身的 IO 性能较差,可通过 IO Benchmark 来进行排查。 常见的原因有磁盘碎片化、器件老化、剩余空间较少(越是低端机越明显)、读放大、写放大等等。
  • 文件系统特性,比如有些文件系统的内部操作会表现为 IO 等待。
  • 开启 Swap 机制的内核下,数据从 Swap 中读取。

优化方法

  • 调优 Readahead 机制
  • 指定文件到 PageCache,即 PinFile 机制
  • 调整 PageCache 回收策略
  • 调优清理垃圾文件策略

2. 低内存导致的 IO 变多

内存是个非常有意思的东西,由于它的速度比磁盘快,因此 OS 设计者们把内存当做磁盘的缓存,通过它来避免了部分IO操作的请求,非常有效的提升了整体 IO 性能。有两个极端情况,当系统内存特别大的时候,绝大部分操作都可以在内存中执行,此时整体 IO 性能会非常好。当系统内存特别低,以至于没办法缓存 IO 数据的时候,几乎所有的 IO 操作都直接与器件打交道,这时候整体性能相比内存多的时候而言是非常差的。

所以系统中的内存较少的时候 IO 等待的概率也会变高。所以,这个问题就变成了如何让系统中有足够多的内存?如何调节磁盘缓存的淘汰算法?

优化方法

  • 关键路径上减少 IO 操作
  • 通过Readahead 机制读数据
  • 将热点数据尽量聚集在一起,使被 Readahead 机制命中的概率高
  • 最后一个老生常谈的,减少大量的内存分配、内存浪费等操作

系统中的内存是被各个进程所共用。当app 只考虑自己,肆无忌惮的使用计算资源,必然会影响到其他程序。这时候系统还是会回来压制你,到头来亏损的还是自己。 不过能想到这一步的开发者比较少,也不现实。明文化的执行系统约定,可能是个终极解决方案。

Non-IOWait 常见原因

  • 低内存导致等待 → 低内存的时候要回收其他程序或者缓存上的内存。
  • Binder 等待 → 有大量 Binder 操作的时候出现概率较高。
  • 各种各样的内核锁,不胜枚举。结合「诊断方法」来分析。

系统调度与 UninterruptibleSleep 耦合的问题

当线程处于 UninterruptibleSleep 非 IO等待状态(即内核锁),而持有该锁的其他线程因 CPU 调度原因,较长时间处于 Runnable 状态。这时候就出现了有意思的现象,即使被等待的线程处于高优先级,它的依赖方没有被调度器及时的识别到,即使是非常短的锁持有,也会出现较长时间的等待。

规避或者彻底解决这类问题都是件比较难的事情,不同厂家实现了不同的解决方案,也是比较考虑厂家技术能力的一个问题。

附录

Linux 线程状态释义

线程状态描述
SSLEEPING
R、R+RUNNABLE
DUNINTR_SLEEP
TSTOPPED
tDEBUG
ZZOMBIE
XEXIT_DEAD
xTASK_DEAD
KWAKE_KILL
WWAKING
DK
DW

案例: 从 Swap 读取数据时的等待

案例: 同进程的多个线程进行 mmap

共享同一个 mm_struct 的线程同时执行 mmap() 系统调用进行 vma 分配时发生锁竞争。

mmap_write_lock_killable() 与 mmap_write_unlock() 包起来的区域就是由锁受保护的区域。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
unsigned long vm_mmap_pgoff(struct file *file, unsigned long addr,
unsigned long len, unsigned long prot,
unsigned long flag, unsigned long pgoff)
{
unsigned long ret;
struct mm_struct *mm = current->mm;
unsigned long populate;
LIST_HEAD(uf);

ret = security_mmap_file(file, prot, flag);
if (!ret) {
if (mmap_write_lock_killable(mm))
return -EINTR;
ret = do_mmap(file, addr, len, prot, flag, pgoff, &populate,
&uf);
mmap_write_unlock(mm);
userfaultfd_unmap_complete(mm, &uf);
if (populate)
mm_populate(ret, populate);
}
return ret;
}

关于我 && 博客

  1. 关于我 , 非常希望和大家一起交流 , 共同进步 .
  2. 博客内容导航
  3. 优秀博客文章记录 - Android 性能优化必知必会

一个人可以走的更快 , 一群人可以走的更远

微信扫一扫

Systrace 线程 CPU 运行状态分析技巧 - Running 篇

本文是 Systrace 线程 CPU 运行状态分析技巧系列的第二篇,主要分析了 Systrace 中 cpu 的 Running 状态出现的原因和 Running 过长时的一些优化思路。

本系列的目的是通过 Systrace 这个工具,从另外一个角度来看待 Android 系统整体的运行,同时也从另外一个角度来对 Framework 进行学习。也许你看了很多讲 Framework 的文章,但是总是记不住代码,或者不清楚其运行的流程,也许从 Systrace 这个图形化的角度,你可以理解的更深入一些。Systrace 基础和实战系列大家可以在 Systrace 基础知识 - Systrace 预备知识 或者 博客文章目录 这里看到完整的目录

  1. Systrace 线程 CPU 运行状态分析技巧 - Runnable 篇
  2. Systrace 线程 CPU 运行状态分析技巧 - Running 篇
  3. Systrace 线程 CPU 运行状态分析技巧 - Sleep 和 Uninterruptible Sleep 篇

Running 时间长

显示方式

Trace 中显示绿色,表示线程处于运行态

原因 1: 代码本身复杂度高,执行耗时久

这是最常见的一种方式,当然不排除平台有bug,有时候厂商在libc、syscal等高频核心函数,加了一些逻辑导致了代码运行时间长。

优化建议: 优化逻辑、算法,降低复杂度。为了进一步判断具体是哪个函数耗时,可使用 AS CPU Profiler、simpleperf,或者自己通过 Trace.begin/end() API 添加更多 tracepoint 点

当然不排除有的时候平台有bug,在关键的libc或内核函数加了一些逻辑

原因 2: 代码以解释方式执行

Trace 中看到 「Compiling」字眼时可能意味着它是解释执行方式进行。刚安装的应用(未做 odex)的程序经常会出现这种情况

优化建议: 使用 dex2oat 之后的版本试试,解释执行方式下的低性能暂无改善方法,除非执行 dex2oat 或者提高代码效率本身

除此之外,使用了编程语言的某种特性,如频繁的调用 JNI,反复性反射调用。除了通过积攒经验方式之外,通过工具解决的方法就是通过 CPU Profiler、simpleperf 等工具进行诊断

原因 3: 线程跑小核,导致执行时间长

对 CPU Bound 的操作来说跑在小核可能没法满足性能需求,因为小核的定位是处理非UX 强相关的线程。不过 Android 没办法保证这一点,有时候任务就是会安排在小核上执行。

优化建议:线程绑核、SchedBoost 等操作,让线程跑尽量跑更高算力的核上,比如大核。有时候即使迁核了也不见效,这时候要看看频率是否拉得足够高,见“原因 4”

原因 4: 线程所跑的大核运行频率太低

优化建议:

  1. 优化代码逻辑,主动降低运行负载,CPU 频率低也能流畅运行
  2. 修改调度器升频相关的参数,让 CPU 根据负载提频更激进
  3. 用平台提供的接口锁定 CPU 频率(俗称的「锁频」)

原因 5: 温升导致 CPU 关核、限频

优化建议:

手机因结构原因导致散热能力差或温升参数过于激进时,为了保护体验跟不烫伤人,几乎所有手机厂家的系统会限制 CPU 频率或者直接关核。排查思路是首先需要找到触发温升的原因。

温升的排查的第一步,首先要看是外因导致还是内因导致。外因是指是否由外部高温导致,如太阳底下,火炉边;往往夏天的时候导致手机发热的情况越严重

内因主要由 CPU、Modem、相机模组或者其他发热比较厉害的器件导致的。以 CPU 为例,如果后台某个线程吃满 CPU,那就首先要解决它。如果是前台应用负载高导致大电流消耗,同样道理,那就降低前台本身的负载。其他器件也是同样道理,首先要看是否是无意义的运行,其次是优化业务逻辑本身

除此之外,温升参数过于激进的话导致触发限频关核的概率也会提高,因此通过与竞品对比等方式调优温升参数本身来达到优化目的

原因 6: CPU 算力弱

优化建议:

ARM 处理器在相同频率下不同微架构的配置导致的性能差异是非常明显的,不同运行频率、L1/L2 Cache 的容量均能影响 CPU 的 MIPS(Million Instructions Per Second) 执行结果。

优化思路有两条:

  1. 编译器参数
  2. 优化代码逻辑

第一条比较难,大部分应用开发者来说也不太现实,系统厂商如华为,方舟编译器优化 JNI 的思路本质是不改应用代码情况下提高代码执行效率来达到性能上的提升

第二条可以通过 simpleperf 等工具,找到热点代码或者观察 CPU 行为后做进一步的改善,如:

  • Cache miss 率过高导致执行耗时,就要优化内存访问相关逻辑
  • 代码复杂指令过多导致耗时,就要优化代码逻辑,降低代码复杂度
  • 设计好业务缓存,尽量提高缓存命中率,避免抖动(反复地申请与释放)

关于我 && 博客

  1. 关于我 , 非常希望和大家一起交流 , 共同进步 .
  2. 博客内容导航
  3. 优秀博客文章记录 - Android 性能优化必知必会

一个人可以走的更快 , 一群人可以走的更远

微信扫一扫

Systrace 线程 CPU 运行状态分析技巧 - Runnable 篇

本文是 Systrace 线程 CPU 运行状态分析技巧系列的第一篇,主要分析了 Systrace 中 cpu 的 runnable 状态出现的原因和 Runnable 过长时的一些优化思路。

本系列的目的是通过 Systrace 这个工具,从另外一个角度来看待 Android 系统整体的运行,同时也从另外一个角度来对 Framework 进行学习。也许你看了很多讲 Framework 的文章,但是总是记不住代码,或者不清楚其运行的流程,也许从 Systrace 这个图形化的角度,你可以理解的更深入一些。Systrace 基础和实战系列大家可以在 Systrace 基础知识 - Systrace 预备知识 或者 博客文章目录 这里看到完整的目录

  1. Systrace 线程 CPU 运行状态分析技巧 - Runnable 篇
  2. Systrace 线程 CPU 运行状态分析技巧 - Running 篇
  3. Systrace 线程 CPU 运行状态分析技巧 - Sleep 和 Uninterruptible Sleep 篇

Runnable 状态说明

Runnable 状态在 Trace 中的显示方式

Perfetto/Systrace: 不同 CPU 运行状态异常原因 101 - Running 长 中讲解了导致 CPU 的 Running 状态耗时久的原因与优化方法,这一节介绍 Runnable 状态切换原理与对应的排查与优化思路。在 Systrace 中显示为蓝色,表示线程处于 Runnable,等待被 CPU 调度执行。

图 1: Systrace 中 Runnable 的可视化效果展示

图 2: 性能之巅 2 CPU 优化

从图 2 可知,一个 CPU 核在某个时刻只能执行一个线程,因此所有待执行的任务都在一个「可执行队列」里排队,一个 CPU 核就有一个队列。能插入到这个队列里排队的,代表着这个线程除了 CPU 资源,其他资源均已获取,如 IO、锁、信号量等。处于「可执行队列」的时候,线程的状态就会被置为 RUNNABLE,也就是 Systrace 里看到的 Runnable 状态。

Linux 内核是通过赋予不同线程执行时间片并通过轮转的方式来达到同时执行多个线程的效果,因此当一个 Running 中的线程的时间片用完时(通常是 ms 级别)将此线程置为 Runnable,等待下一次被调度。也有比较特殊的情况,那就是抢占。有些高优先级的线程可以抢占当前执行的线程,而不必等到此线程的时间片到期。

当一个 CPU 有多个核的时候显然可以多个核同时工作,这时候不必都在一个 CPU 核上排队,根据负载情况(也就是排队情况),将线程迁移到其他核执行是必要的操作。掌管这些调度策略的,是通过 Linux 的调度器来实现的,它具体通过多个调度类(Schedule Class)来管理不同线程的优先级,常见的有:

  1. SCHED_RR、SCHED_FIFO: 实时调度类,整体优先级上高于 NORMAL。
  2. SCHED_NORMAL: 普通调度类,目前常用的是 CFS(Complete Fair Scheduler)调度器。
    实时类的优先级高于普通调度类,高优先级的能抢占低优先级,并且要等待高优先级的执行完才能执行低优先级的。一般情况下 Runnable 的时间都很短,但出异常的的时候它会影响关键线程的关键任务在指定时间内完成。

图 3: AOSP 渲染架构

这个可能不止是一个线程,甚至是多个。特别是涉及到 UI 相关的任务,这种情况就更为复杂了。AOSP 体系下典型的一帧绘制是经过 UI Thread → Render Thread → SurfaceFlinger → HWC(参考 图 3),其中任何一个线程被 Runnable 阻塞导致没有在规定时间内完成渲染任务,都将会导致界面的卡顿(也就是掉帧)。

Runnable 过长的原因和优化思路

我们从实践中总结出以下 5 大门类,系统层面出异常的原因较多,但也见过应用自身逻辑导致 Runnable 过长情况。

原因 1: 优先级设置错误

  • 应用设置了过高的优先级:至于抢占了其他线程的任务,对后者来说显得自己优先级太低了。
  • 应用设置了过低的优先级:当此线程处于「关键链路」时,以 Runnable 执行的概率就越高,导致卡顿概率也高。
  • 系统出 Bug 时把线程优先级设为过高或者过低。

优化思路:

  1. 应用视情况调整线程优先级,可从 Trace 中可以看到是被哪个线程抢占了。
  2. 系统将关键线程调度策略设置成 FIFO。

我们在实践中见到过不少应用因为设置错了优先级反而导致更卡。原因比较复杂,可能开发者所使用的机器用当时的优先级策略没问题,但是在别的厂商的调度器(头部大厂基本都有自己改动调度器)下就会出现水土不兼容的情况。一般情况下,三方应用开发者不建议直接调用这类 API,弄巧成拙,屡见不鲜。

长远看来更靠谱的方式是合理安排自己的任务模型,不要把对实时性要求很高的任务放到 worker 线程上。

原因 2: 绑核不合理

有时候为了让线程运行得更快,会把线程绑定到大核,在前面解决 Running 时间长时也有建议绑大核,但是绑核一定要谨慎,因为一旦把线程绑定在某个核,表示线程只能运行在这个核上即使其它核很空闲。如果多个线程都绑定在某个核,当这个核很繁忙调度不过来时,这些线程就会出现 Runnable 时间很长的情况。所以绑核一定要谨慎!下面是绑核需要注意的一些事项:

  1. 线程绑核不要绑定在单个核上,这样容错率会特别低,因为一旦这个核被其它线程抢占绑定这个核的线程就要等着,所以尽量以 CPU 簇为单位进行绑核,比如线程要绑定大核,可以指定 4-7 大核而不是指定某个一大核。
  2. 2 个大核平台尽可能减少绑定大的核线程数目,不然会使得大核很容易繁忙,把绑核会变成「负优化」。
  3. 要正确区分大小核,比如 8 个核的平台,4-7 不一定就是大核,有的平台可能 0-3 才是大核。
  4. 只能在 CPUSET 允许范围内绑核,如果 CPUSET 只允许进程跑 0-3,如果进程试图绑定在 4-7 会绑核失败,甚至会有一些意料之外的致命错误。

原因 3: 软件架构设计不合理

重申下,Runnable 是指在 CPU 核上的排队耗时,按常识可可知道排队长、频繁排队时出问题概率也就越高。一个绘制任务所依赖的线程数量越多,出问题的概率也越高,因为排队次数变多了嘛。

软件架构不止要满足业务需求,也要在性能、扩展性方面上做思考,从上面推导可知,如果你程序编程模型需要大量线程协同运行来完成关键操作,如绘制,那出问题的概率就越高。

最常见的有,两个线程之间有频繁的有通讯与等待(线程 A 把任务转移到线程 B 执行,A 等待 B 任务执行完后被唤醒), CPU 繁忙时很容易打出 Runnable 等待状态,CPU 越忙概率越高。

优化思路:

  1. 应用调整线程优先级,见「原因 1」。
  2. 优化代码架构/逻辑,免频繁等待其他线程的唤醒,在 Trace 中可以看到线程的依赖关系。可借助 CPU Profiler 探查代码执行逻辑,提高分析唤醒关系的效率。
  3. 平台通过修改调度器来识别有关系链的线程组,优先调度这个组里的线程。

原因 4: 应用自己或系统整体负载高导致排队的任务非常多

从上述的调度原理可知,如果大量任务挤在一个核的「可执行队列」上,显然越是后面,优先级越低的任务排队时间就越长。

排查的时候你可以在 Perfetto/Systrace 的 CPU 核维度任务上,即使在放大后的界面看到排满了密密麻麻的任务,这基本上就意味着系统整体负载较高了。通过计算,可算出 CPU 每时刻的使用量,基本上都会在 90%以上。 你可以通过选择一个区间,以时间来排序,看看都在执行什么任务,以此来逐个排查同时执行大量程序的原因是什么。

简单总结就是,同时执行的任务太多了,主要原因来自两方面:

1.应用自身高占用

应用自身就把 CPU 资源都给占满了,狂开十来个线程来做事情,即使是头部大厂也会做这种事。

优化建议:

  1. 找出应用所有占用高的线程,看看各线程此刻跑起来的行为是否异常,如果异常则要优化它。
  2. 优化线程负载本身,可使用 simpleperf 等工具进行函数级别的定位。
  3. 调整优先级,使用比 CFS 更高优先级的调度器,如设置为 RT。不过它带来的隐患也较多,需要慎重。
  4. 优化软件架构,区分关键与非关键线程,通过合理设置「绑核 & 优先级」来为关键线程让出资源。 如,不重要线程绑到小核运行或设置低优先级、渲染相关线程设置高优先级等,让渲染线程相关的线程能占用到更多的 CPU 资源。设计架构的时候一定要考虑运行环境恶劣的情况,因为安卓从设计上就不敢保证所有资源都优先供给你,肯定有别人跟你抢资源。

2.系统服务高占用

有的厂商 ROM 自己本身就有很多任务,设计不合理的话自己家程序就吃满了大量资源,导致留给应用运行的资源较少。还有些是管控措施设计的一般,以至于留给了大量流氓应用可乘之机,各路神仙利用自己的「黑科技」在后台保活后进行各种拉活同步操作。

3.平台厂家的黑科技

厂家除了要优化自身服务,以做到「点到为止」外,可以实现如下功能来尽可能把资源分配合理化,让出更多资源给前台应用。

  1. 通过 CGROUP 的 CPUSET 子系统,让不同优先级的线程运行在不同的 CPU 核心。AOSP 自带了 CPUSET 分组功能,不过有些缺陷如:
    1. 分组不够精细,很多后台都可以跑满所有核
    2. 没有考虑进程的工作状态,如 音乐、导航、录音、视频、通话、下载
    3. 对 Java 进程 fork 的子进程放任不管
  2. 通过 CGROUP 的 CPUCTL 子系统,进行资源配额,如限制异常进程、普通后台进程的不同量级的 CPU 最高使用量。
  3. 通过线程&进程级别的冻结技术,在应用退出后台之后冻结进程让其拿不到 CPU 资源,类似 iOS 的做法。难点在于:
    1. 切断和恢复各跨进程通信
    2. 进程关系的梳理
    3. 兼容性问题,需要有大量的测试验证
  4. 按需启动系统进程与管控好后台进程自启动。

每一个优化说简单也简单,说难也难,依赖厂家的技术积累。

原因 5: CPU 算力限制、锁频、锁核、状态异常

排队做核酸检测一样,检测窗口多的队列排队时间少。CPU 算力差、关核、限频,导致 Runnable 的概率也更高。通常的原因有:

  1. 场景控制
    • 不同场景模式下的不同频率、核心策略
    • 高温下的锁频锁核
  2. CPU 省电模式:如高通的 Low Power Mode。
  3. CPU 状态切换:如 C2/C1 切换到 C0 耗时久。
  4. CPU 损坏,概率小但也有可能会出现。
  5. 低端机 :安卓上的低端机。

其中:

  1. 原因 1 场景控制, 考验厂家的能力与各自的标准,应用程序能做的还是那句名言 → 降低自己负载,少惹平台。 厂家为了设计好「场景控制」,需要有精细化的场景识别与合理的控制能力,将功耗与性能的平衡做到全局最优化,不同场景下应突出不同的业务能力,而不是一杆子拍死。
  2. 高温下的优化建议请参考「Perfetto/Systrace: 不同 CPU 运行状态异常原因 101 - Running 长」中的「原因 5: 温升导致 CPU 关核、限频」。
  3. 原因 3 CPU 状态切换 是芯片固有的特性,出现的概率小,但也不是不可能,每个芯片架构升级换代的时候就时不时遇到「妥协」版的 CPU 产品。厂家对芯片的评估是个比较隐性的能力,很少会被大众提及,但是非常重要的一个能力。电子消费品历史中,也总是重演关键器件选错了,导致厂家走入万劫不复境地的真实案例。
  4. 原因 5,安卓上的低端机,真的就指配备里低算力的 CPU,这与苹果的做法不一样,它的 CPU 至少跟当期旗舰是一样的。同样参考 「Perfetto/Systrace: 不同 CPU 运行状态异常原因 101 - Running 长」中的「原因 6: 算力弱」。

原因 6: 调度器异常

几乎所有的厂家都做了调度器优化方面的工作,虽然概率小,但也有可能会出异常。场景锁频锁核机制有问题、内核各种 governor 的出问题的时候,会出现明明 CPU 的其他核都很闲,但任务都挤在某几个核上。

系统开发者能做的就是把基础「可观测性技术」建好,出问题时可以快速诊断,因为这类问题一是不好复现,二是现象出现时机较短,可能立马就恢复了。

原因 7: 处理器区分执行 32 位与 64 位进程

有些过渡期的芯片,如最近推出的骁龙 8Gen1 与 天玑 9000,会有非常奇葩的运行限制。32 位的程序只能运行某个特定微架构上,64 位的则畅通无阻。且先不说这种「脑残设计」是处于什么所谓「平衡」,他带来的问题是,当你用的应用大量还是 32 位的时候,很多任务(以进程为单位)都挤在某个核心上运行,结合前面的理论,都挤在一起,出现 Runnable 的概率就更高。

  1. 对应用开发者,建议尽快升级至 64 位程序。如果你用的是第三方方案,尽早通知改进或者改用其他方案。
  2. 对系统开发者,一是根据问题联系应用厂商做更新,二是特殊加强后台管理功能,进一步降低 32 位程序的运行负载。

关于我 && 博客

  1. 关于我 , 非常希望和大家一起交流 , 共同进步 .
  2. 博客内容导航
  3. 优秀博客文章记录 - Android 性能优化必知必会

一个人可以走的更快 , 一群人可以走的更远

微信扫一扫

Techniques, Philosophy, and Tools for Android Performance Optimization

黑客与画家

In his book Hackers & Painters, Paul Graham asserted, “The disparity in the efficiency of languages is becoming more pronounced, hence the rising importance of profilers. Currently, performance analysis isn’t given the attention it deserves. Many still seem to hold onto the belief that the key to accelerating program execution lies in developing compilers that generate faster code. As the gap between code efficiency and machine performance widens, it will become increasingly apparent that enhancing the execution speed of application software hinges on having a good profiler to guide program development.” by Paul Graham, Hackers & Painters

A Google search for “Android optimization tools” yields an abundance of related content. The issue with these results is that they either contain highly repetitive content or directly explain usage methods. Rarely do they introduce a holistic architecture, inadvertently instilling a misguided belief of “one tool fixes all”. Drawing from the extensive experience of my team, I can assert that in the realm of performance analysis, no such magic bullet tool exists. Tools evolve, old problems re-emerge in new forms, and without mastering core logic, one remains on the technological surface.

This article first systematically untangles the observability technology in performance analysis, encompassing data types, capture methods, and analysis techniques. Subsequently, we introduce the “big three” analysis tools provided by Google. The aim is to impart immutable theoretical knowledge and corresponding tools available in the Android environment to the reader. This wealth of information can facilitate a more direct application of predecessors’ experiences, circumventing unnecessary detours.

It’s crucial to note that there are certainly more than these three tools available for performance optimization. However, these three are our “go-to first-hand tools”. Prior to delving into further analysis, you’ll find yourself dependent on these three tools for bottleneck identification. Subsequent analyses, tailored to distinct domain characteristics, should then leverage corresponding tools.

1 Observability Techniques in Performance Analysis

  • Has this operation been executed? How long did it take?
  • Why is there a significant difference between two versions?
  • What operations is the system executing when CPU usage is high?
  • Why has the startup speed slowed down?
  • Why does this page always stutter when scrolling?

You’ve likely been asked similar questions by colleagues or bosses more than once. The most primitive idea might be to obtain the relevant logs and analyze them one by one. Based on past experience, one would search for clues by looking for keywords. If the desired information is not available, the next step is to add logs and attempt to reproduce the issue locally. This approach is not only time-consuming and laborious, but also wastes developmental resources. Have you ever wondered if there is a more efficient method in the industry? A method that can improve efficiency by an order of magnitude, allowing us to spend our time solving problems instead of on mundane, repetitive physical tasks?

Of course, there is (otherwise this article wouldn’t exist)—we refer to it as observability techniques.

As the computer industry has evolved, pioneers in computing have devised a category known as “observability techniques.” It involves utilizing tools to observe the intricate details of complex systems’ operations—the more detailed, the better. Mobile operating systems evolved from embedded systems. Nowadays, the computing power of mid-to-high-end Android phones can catch up with a mainframe from two decades ago, and the resulting software complexity is also immense.

Employing a well-designed and smoothly operating observability technique can significantly accelerate software development efficiency. This is because, despite using a variety of preemptive static code detection and manual code reviews, it is impossible to block software issues 100%. Problems only become apparent after the software is run in a real environment, which might be an automated test case of yours. Even then, you still need to sift through your logs and re-read code to identify the problem. For these reasons, every engineering team needs a fully functional observability tool as one of their fundamental infrastructures.

Observability is a systematic engineering effort that allows you to delve deeper into occurrences within the software. It can be used to understand the internal operational processes of software systems (especially complex business logic or interactive systems), troubleshoot, and even optimize the program by identifying bottlenecks. For complex systems, understanding the entire operational process through code reading can be challenging. A more efficient approach is to utilize observability tools to obtain the software’s operational status most intuitively.

We will explore data types, data acquisition methods, and analysis methods to help you understand observability techniques in the sections below.

1.1 Data Types

Logs can be in the form of key-value pairs, JSON, CSV, relational databases, or any other formats. We recreate the entire state of the system at the time it was running through logs to solve a specific issue, observe the operation of a module, or even depict the behavioral patterns of system users. In observability technology, log types are classified into Log, Metric, and Trace types.

Log Type

Logs are the most rudimentary form of data recording, typically noting what happened at what time in which module, whether the log level is a warning or an error. Nearly all systems, whether embedded devices or computers in cars, utilize this form of log. It is the simplest, most direct, and easiest to implement. Almost all Log types are stored as strings, presenting data in lines of text. Logs are the most basic type, and through conversion, can be turned into Metric or Trace types, though the conversion process can become a bottleneck when dealing with massive amounts of data.

Different log types are usually distinguished by error, warning, and debug levels. Naturally, error logs are your primary concern. However, in practice, this classification is not always strict, as many engineers do not differentiate between them, possibly due to a lack of classification analysis for different log levels in their engineering development environment. In summary, you can grade Log types according to your objectives. It acts like an index, enhancing the efficiency of problem analysis and target information location.

Metric Type

Metric types are more focused compared to Log types, recording numerical changes in a particular dimension. Key points are the “dimension” and “numerical change.” Dimensions could be CPU usage, CPU Cluster operation frequency, or context switch counts. Numerical changes can be instant values at the time of sampling (snapshot type), the difference from the previous sampling, or aggregated statistical values over a period. Statistics are often used in practice, such as when wanting to observe the average CPU usage five minutes before an issue occurred. In this case, an arithmetic mean or weighted average calculation of all values within these five minutes is required.

Aggregation is a useful tool because it’s not possible for a person to analyze all Metric values individually. Determining the existence of a problem through aggregation before conducting detailed analysis is a more economical and efficient method.

Another benefit of the Metric type is its fixed content format, allowing data storage through pre-encoding, utilizing space more compactly and occupying less disk space. The most straightforward application is data format storage; Metric types, using integers or floating numbers of fixed byte data, are more space-efficient than Log types, which generally use ASCII encoding.

In addition to specific values, enumeration values can also be stored (to some extent, their essence is numerical). Different enumeration values represent different meanings, possibly indicating on and off statuses, or different event types.

Trace Type

Trace types indicate the time, name, and duration of an event. Relationships among multiple events identify parent-child or sibling connections. Trace types are the most convenient data analysis method when dissecting complex call relationships across multiple threads.

Trace types are particularly suitable for Android application and system-level analysis scenarios because they can diagnose:

  1. Function call chains
  2. Binder call chains during invocation
  3. Cross-process event stream tracing

In the design of Android’s application running environment, an application can’t perform all functionalities independently; it requires extensive interaction with the SystemServer. Communication with the SystemServer is facilitated through Binder, a communication method detailed later in this article. For now, understand that it involves cross-process calling. Accurate restoration of call relationships requires data from both ends, making Trace the optimal information recording method.

You can manually add starting and ending points for Trace types and insert multiple intervals within a function. With pre-compilation technology or language features, Trace intervals can automatically be instrumented at the beginning and end of functions. In an ideal scenario, the latter is the best approach as it allows for understanding what functions are running in the system, their execution conditions, and call relationships. This information can identify the most frequently called (hottest) functions and the most time-consuming ones. Understandably, this method incurs a significant performance loss due to the frequency and magnitude of function calls, especially in complex systems.

An alternative approach involves approximating the above effect by sampling call stacks. Shorter sampling intervals more closely approximate real call relationships and durations, but they can’t be too short, as obtaining stack operations itself becomes a load due to increased frequency. This method, known as a Profiler in the industry, is the basis for most programming language Profiler tools.

1.2 Data Acquisition Methods

Static Code and Dynamic Tracing

Static code collection is the most primitive method. It’s straightforward to implement but requires recompiling and reinstalling the program each time new content is added. If the information you need to diagnose a problem isn’t available, you have no choice but to repeat the entire process. A more advanced approach is to pre-install data collection points at all potential areas of interest, and use dynamic switches to control their output. This technique balances performance impacts and allows dynamic enabling of logs as needed, albeit at a high cost.

Dynamic tracing technology has always been available but is often considered the “holy grail” in the debugging and tracing field due to its steep learning curve. It demands a deep understanding of low-level technologies, especially in areas like compilation, ELF format, the kernel, and programming languages associated with pre-set probes and dynamic tracing. Indeed, dynamic tracing even has its own set of programming languages to cater to the dynamic implementation needs of developers. This approach balances performance and flexibility and enables dynamic retrieval of desired information even in live versions.

In Android application development and system-level development, dynamic tracing is rarely used and is occasionally employed in kernel development. Typically, only specialized performance analysts might utilize these tools. Two critical elements of dynamic tracing are probes and dynamic languages. The program’s execution permission must be handed over to the dynamic tracing framework at specific probe points during runtime. The logic executed by the framework is written by developers using dynamic languages.

Therefore, your program must first have probes. Linux kernel and other frameworks have embedded corresponding probe points, but Android application layers lack these. Currently, dynamic frameworks like eBPF on Android are mainly used by kernel developers.

Unconditional and Conditional Capture

Unconditional capture is straightforward: data is continuously captured after triggering, regardless of any conditions. The drawback is that when the observed object generates a large volume of data, it could significantly impact the system. In such cases, reducing the volume of data captured can mitigate the impact, striking a balance between meeting requirements and minimizing performance loss.

Conditional capture is often employed in scenarios where anomalies can be identified. For instance, capturing logs is triggered when a specific observed value exceeds a pre-set threshold and continues for a certain duration or until another threshold is reached. This method is a slight improvement over unconditional capture as it only impacts the system when an issue arises, leaving it unaffected at other times. However, it requires the capability to identify anomalies, and those anomalies should not necessitate historical data preceding the occurrence. Lowering the threshold can increase the probability of triggering data capture, leading to the same issues faced with unconditional capture, and requiring a balance of performance loss.

Disk Write Strategy

Continuous disk writing involves storing all data captured during the entire data capture process, which can strain storage resources. If the trigger point, such as an anomaly, can be identified, selective disk writing becomes an option. To ensure the validity of historical data, logs are temporarily stored in a RingBuffer and only written to disk upon receiving a disk write command. This method balances performance and storage pressure but at the cost of runtime memory consumption and the accuracy of the trigger.

1.3 Analysis Methods

Data Visualization Analysis

As the complexity of problem analysis increases, especially with the need to address performance issues arising from the interactions among multiple modules, data visualization analysis methods have emerged. These methods visualize events on respective lanes with time as the horizontal axis, facilitating a clear understanding of when specific events occur and their interactions with other systems. In Android, tools like Systrace/Perfetto and, earlier, KernelShark, are fundamentally of this type. The “Trace Type” mentioned in “Data Types” often employs this kind of visualization.

Systrace’s visualization framework is built on a Chrome subproject called Catapult. The Trace Event Format outlines the data formats supported by Catapult. If you have Trace type data, you can use this framework for data visualization. AOSP build systems and the Android app compilation process also output corresponding Trace files, with visualization effects based on Catapult.

Database Analysis

For extensive data analysis, formatting data and converting it into two-dimensional data tables enables efficient query operations using SQL. In the server domain, technology stacks like ELK offer flexible formatted search and statistical functions. With databases and Python, you can even create an automated data diagnostic toolchain.

From the discussion above, it’s evident that text analysis and database analysis serve different analytical purposes. Text analysis is sufficient for evaluating the time consumption of a single module, visualization tools are needed for interactions among multiple systems, and SQL tools are required for complex database analysis. Regardless of the analysis method, the core is data analysis. In practice, we often convert data using other tools to support different analysis methods, such as transitioning from text analysis to database analysis.

Choosing the right analysis method according to your objectives can make your work highly efficient.

For Android developers, Google provides several essential performance analysis tools to assist both system and app developers in optimizing their programs.

2 Google’s Android Performance Analysis Tools

Based on practical experience, the most commonly used tools are Systrace, Perfetto, and the Profiler tool in Android Studio. Only after identifying the main bottlenecks using these tools would you need to resort to other domain-specific tools. Therefore, we will focus on the application scenarios, advantages, and basic usage of these three tools. For a horizontal comparison between the tools, please refer to the content in the next chapter, “Comprehensive Comparison.”

2.1 First Generation System Performance Analysis Tool - Systrace

Systrace is a visualization analysis tool for the Trace type and represents the first generation of system-level performance analysis tools. It supports all the features facilitated by the Trace type. Before the emergence of Perfetto, Systrace was essentially the only performance analysis tool available. It presents the operating information of both the Android system and apps graphically. Compared to logs, Systrace’s graphical representation is more intuitive; and compared to TraceView, the performance overhead of capturing Systrace can be virtually ignored, minimizing the impact of the observer effect to the greatest extent.

Systrace

Systrace Design Philosophy

Systrace embeds information similar to logs, known as TracePoints (essentially Ftrace information), at key system operations (such as Touch operations, Power button actions, sliding operations, etc.), system mechanisms (including input distribution, View drawing, inter-process communication, process management mechanisms, etc.), and software and hardware information (covering CPU frequency information, CPU scheduling information, disk information, memory information, etc.). These TracePoints depict the execution time of core operation processes and the values of certain variables. The Android system collects these TracePoints scattered across various processes and writes them into a file. After exporting this file, Systrace analyzes the information from these TracePoints to obtain the system’s operational information over a specific period.

In the Android system, some essential modules have default inserted TracePoints, classified by TraceTag, with information sources as follows:

  1. TracePoints in the Framework Java layer are implemented through the android.os.Trace class.
  2. TracePoints in the Framework Native layer are executed using the ATrace macro.
  3. App developers can customize Trace through the android.os.Trace class.

Consequently, Systrace can collect and display all information from both upper and lower layers of Android. For Android developers, Systrace’s most significant benefit is turning the entire Android system’s operational status from a black box into a white box. Its global nature and visualization make Systrace the first choice for Android developers when analyzing complex performance issues.

Practical Applications

The parsed Systrace, rich in system information, is naturally suited for analyzing the performance issues of both Android Apps and the Android system. Android app developers, system developers, and kernel developers can all use Systrace to diagnose performance problems.

  1. From a Technical Perspective:
    Systrace can cover major categories involved in performance, such as response speed, frame drops or janks, and ANR (Application Not Responding) issues.

  2. From a User Perspective:
    Systrace can analyze various performance issues encountered by users, including but not limited to:

    • Application Launch Speed Issues: Including cold start, warm start, and hot start.
    • Slow Interface Transitions: Including slow transitions and janky animations.
    • Slow Non-Transition Click Operations: Such as toggles, pop-ups, long presses, selections, etc.
    • Slow Screen Brightness Adjustment Speed: Including slow on/off speed, slow unlocking, slow face recognition, etc.
    • List Scrolling Jankiness:
    • Window Animation Lag:
    • Interface Loading Jankiness:
    • Overall System Lag:
    • App Unresponsiveness: Including freeze and crash issues.

When encountering the above problems, various methods can be employed to capture Systrace. The parsed file can then be opened in Chrome for analysis.

The ability to trace and visualize these issues makes Systrace an invaluable tool for developers aiming to optimize the performance of Android applications and the system itself. By analyzing the data collected, developers can identify bottlenecks and problematic areas, formulate solutions, and effectively improve the performance and responsiveness of apps and the Android operating system.

2.2 The Next-Generation Performance Analysis Full Stack Tool - Perfetto

Google initiated the first submission in 2017, and over the next four years (up until Dec 2021), over 100 developers made close to 37,000 commits. There are PRs and merges almost daily, marking it as an exceptionally active project. Besides its powerful features, its ambition is significant. The official website claims it to be the next-generation cross-platform tool for Trace/Metric data capture and analysis. Its application is also quite extensive; apart from the Perfetto website, Windows Performance Tool, Android Studio, and Huawei’s GraphicProfiler also support the visualization and analysis of Perfetto data. We believe Google will continue investing resources in the Perfetto project. It is poised to be the next-generation performance analysis tool, wholly replacing Systrace.

Highlighted Features

The most significant improvement of Perfetto over Systrace is its ability to support long-duration data capture. This is made possible by a service that runs in the background, enabling the encoding of collected data using Protobuf and saving it to disk. From the perspective of data sourcing, the core principle is consistent with Systrace, both based on the Linux kernel’s Ftrace mechanism for recording key events in both user and kernel spaces (ATRACE, CPU scheduling). Perfetto supports all functionalities provided by Systrace, hence the anticipation of Systrace being replaced by Perfetto entirely.

Perfetto

Perfetto’s support for data types, acquisition methods, and analysis approaches is unprecedentedly comprehensive. It supports virtually all types and methods. ATRACE enables the support for Trace type, a customizable node reading mechanism supports Metric type, and in UserDebug versions, Log type support is realized by obtaining Logd data.

You can manually trigger capture and termination via the Perfetto.dev webpage or command-line tools, initiate long-duration capture via the developer options in the settings, or dynamically start data capture via the Perfetto Trigger API integrated within the framework. This covers all scenarios one might encounter in a project.

In terms of data analysis, Perfetto offers a data visualization analysis webpage similar to Systrace, but with an entirely different underlying implementation. The biggest advantage is its ability to render ultra-large files, a feat Systrace cannot achieve (it might crash or become extremely laggy with files over 300M). On this visualization webpage, one can view various processed data, execute SQL query commands, and even view logcat content. Perfetto Trace files can be converted into SQLite-based database files, enabling on-the-spot SQL execution or running pre-written SQL scripts. You can even import it into data science tool stacks like Jupyter to share your analysis strategies with colleagues.

For example, if you want to calculate the total CPU consumption of the SurfaceFlinger thread, or identify which threads are running on large cores, etc., you can collaborate with domain experts to translate their experiences into SQL commands. If that still does not meet your requirements, Perfetto also offers a Python API, converting data into DataFrame format, enabling virtually any desired data analysis effect.

With all these offerings, developers have abundant aspects to explore. From our team’s practical experience, it can almost cover every aspect from feature development, function testing, CI/CD, to online monitoring and expert systems. In the subsequent series of articles on our planet, we will focus on Perfetto’s powerful features and the expert systems developed based on it, aiding you in pinpointing performance bottlenecks with a single click.

Practical Application

Perfetto has become the primary tool used in performance analysis, with Systrace’s usage dwindling. Hence, the tool you should master first is Perfetto, learning its usage and the metrics it provides.

However, Perfetto has its boundaries. Although it offers high flexibility, it essentially remains a static data collector and not a dynamic tracing tool, fundamentally different from eBPF. The runtime cost is relatively high because it involves converting Ftrace data to Perfetto data on the mobile device. Lastly, it doesn’t offer text analysis methods; additional analyses can only be performed via webpage visualization or operating SQLite. In summary, Perfetto is powerful, covering almost every aspect of observability technology, but also has a relatively high learning curve. The knowledge points worth exploring and learning are plentiful, and we will focus on this part in our upcoming articles.

2.3 Android Studio Profiler Tool

The integrated development environment for Android application development (officially recommended) is Android Studio (previously it was Eclipse, but that has been phased out). It naturally needs to integrate development and performance optimization. Fortunately, with the iterations and evolution of Android Studio, it now has its own performance analysis tool, Android Profiler. This is a collective tool integrating several performance analysis utilities, allowing developers to optimize performance without downloading additional tools while developing applications in Android Studio.

Currently, Android Studio Profiler has integrated four types of performance analysis tools: CPU, Memory, Network, and Battery. The CPU-related performance analysis tool is the CPU Profiler, the star of this chapter. It integrates all CPU-related performance analysis tools, allowing developers to choose based on their needs. Many people might know that Google has developed some independent CPU performance analysis tools, like Perfetto, Simpleperf, and Java Method Trace. CPU Profiler does not reinvent the wheel; it gathers data from these known tools and parses it into a desired style, presenting it through a unified interface.

Highlighted Features

CPU Profiler integrates performance analysis tools: Perfetto, Simpleperf, and Java Method Trace. It naturally possesses all or part of the functionalities of these tools, such as:

  1. System Trace Recording: Information captured with Perfetto, useful for analyzing process function duration, scheduling, rendering, etc. However, it’s a simplified version, only displaying process-strongly related information and filtering out short-duration events. It’s recommended to export the Trace file for analysis on https://ui.perfetto.dev/.
  2. Java Method Trace Recording: It gathers function call stack information from the virtual machine, used for analyzing Java function calls and duration.
  3. C/C++ Function Trace: Information captured with Simpleperf. Simpleperf gathers data from the CPU’s performance monitoring unit (PMU) hardware component. C/C++ Method Trace has only partial functionalities of Simpleperf, used for analyzing C/C++ function calls and durations.

CPU Profiler

Practical Application

Application performance issues are mainly divided into two categories: slow response and lack of smoothness.

  • Slow response issues include slow app startup, slow page transitions, slow list loading, slow button responses, etc.
  • Lack of smoothness issues include unsmooth list scrolling, page sliding not following hand movements, animation judders, etc.

How to use CPU Profiler in these scenarios? The basic approach is to capture a System Trace first, analyze and locate the issue with System Trace. If the issue can’t be pinpointed, further analysis and location should be done with Java Method Trace or C/C++ Function Trace.

Taking an extremely poor-performing application as an example, suppose Systrace TracePoint is inserted at the system’s critical positions and the code is unfamiliar. How do you identify the performance bottleneck? First, run the application and record a System Trace with CPU Profiler (the tool usage will be introduced in later articles), as shown below:

From the above Trace, it’s evident that the onDrawFrame operation in the egl_core thread is time-consuming. If the issue isn’t apparent, it’s advised to export it to https://ui.perfetto.dev/ for further analysis. By looking into the source code, we find that onDrawFrame is the duration of the Java function onDrawFrame. To analyze the duration of the Java function, we need to record a Java Method Trace, as follows:

From the above Trace, it’s easy to see that a native function called Utils.onDraw is time-consuming. Because it involves C/C++ code, another C/C++ Function Trace needs to be recorded for further analysis, as shown below:

It becomes clear that the code executed a sleep function within the native Java_com_gl_shader_Utils_onDraw, pinpointing the culprit for the poor performance!

The greatest advantage of CPU Profiler in AS is the integration of various sub-tools, enabling all operations in one place. It’s incredibly convenient for application developers. However, system developers might not be so lucky.

2.4 Comparative Analysis

Tool NameApplication ScenarioData TypeData Acquisition MethodAnalysis Method
SystraceAndroid System & App Performance AnalysisTrace TypeUnconditional Capture, Continuous LoggingVisual Analysis
PerfettoAndroid System & App Performance AnalysisMetric Type, Trace TypeUnconditional Capture, Continuous LoggingVisual Analysis, Database Analysis
AS ProfilerAndroid System & App Performance AnalysisTrace TypeUnconditional Capture, Continuous LoggingVisual Analysis
SimplePerfJava/C++ Function Execution Time Analysis, PMU CountersTrace TypeUnconditional Capture, Continuous LoggingVisual Analysis, Text Analysis
Snapdragon Profiler Tools & ResourcesPrimarily for Qualcomm GPU Performance AnalyzerTrace Type, Metric TypeUnconditional Capture, Continuous LoggingVisual Analysis
Mali Graphics DebuggerARM GPU Analyzer (for MTK, Kirin chips)Trace Type, Metric TypeUnconditional Capture, Continuous LoggingVisual Analysis
Android Log/dumpsysComprehensive AnalysisLog TypeConditional Capture, Continuous Capture but not LoggingText Analysis
AGI (Android GPU Inspector)Android GPU AnalyzerTrace Type, Metric TypeUnconditional Capture, Continuous LoggingVisual Analysis
eBPFDynamic Tracing of Linux Kernel BehaviorMetric TypeDynamic Tracing, Conditional Capture, Continuous Capture but not LoggingText Analysis
FTraceLinux Kernel TracingLog TypeStatic Code, Conditional Capture, Continuous Capture but not LoggingText Analysis

3 On “Instruments, Techniques, Philosophy”

Technical revolutions and improvements are often reflected at the “instruments” level. The development direction of tools by the Linux community and Google is towards enhancing the integration of tools so that necessary information can be easily found in one place, or towards the collection of more information. In summary, the development trajectory at the instruments level is traceable and developmental rules can be summarized. We need to accurately understand their capabilities and application scenarios during rapid iterations of tools, aiming to improve problem-solving efficiency rather than spending time learning new tools.

The “techniques” level depends on specific business knowledge, understanding how a frame is rendered, how the CPU selects processes for scheduling, how IO is dispatched, etc. Only with an understanding of business knowledge can one choose the right tools and correctly interpret the information provided by these tools. With rich experience, sometimes you can spot clues even without looking at the detailed information provided by tools. This is a capability that arises when your business knowledge is enriched to a certain extent, and your brain forms complex associative information, elevating you above the tools.

At the “philosophy” level, considerations are about the nature of the problem that needs to be solved. What is the essence of the problem? What extent should be achieved, and what cost should be incurred to achieve what effect? For solving a problem, which path has the highest “input-output ratio”? What is the overall strategy? To accomplish something, what should be done first and what should be done next, and what is the logical dependency relationship?

In subsequent articles, explanations will be provided in the “instruments, techniques, philosophy” manner for a technology or a feature. We aim not only to let you learn a knowledge point but also to stimulate your ability to extrapolate. When faced with similar tools or problems, or even completely different systems, you can handle them with ease. Firmly grasping the essence, you can choose the appropriate tools or information through evaluating the “input-output ratio” and solve problems efficiently.

About Me && Blog

  1. About Me: I am eager to interact and progress together with everyone.
  2. Follow me on Twitter
  3. Blog Content Navigation
  4. Record of Excellent Blog Articles - Essential Skills and Tools for Android Performance Optimization

An individual can move faster, a group can go further.

Android 性能优化的术、道、器

黑客与画家

Paul Graham 在其著作 <黑客与画家> 中断言:“不同语言的执行效率差距正变得越来越大,所以性能分析器(profiler)将变得越来越重要。目前,性能分析并没有受到重视。许多人好像仍然相信,程序运行速度提升的关键在于开发出能够生成更快速代码的编译器。代码效率与机器性能的差距正在不断加大,我们将会越来越清楚地看到,应用软件运行速度提升的关键在于有一个好的性能分析器帮助指导程序开发。”
by Paul Graham 黑客与画家

谷歌搜索 「Android 优化工具」,你会找到很多与此相关的内容。他们的问题在于要么是内容高度重复、要么是直接讲使用方法,很少会给你介绍整体性的架构,一不小心就会让人会种「一个工具搞定一切」的错误认知。以笔者团队的多年经验来看,在性能分析领域这种银弹级别的工具是不存在的。工具在发展,老问题会以新的方式变样出现,不掌握核心逻辑的话始终会让你浮于技术的表面。

本文首先系统性的梳理性能分析中的可观测性技术,它涵盖数据类型、抓取方法以及分析方法等三部分内容,之后是介绍谷歌提供的「三大件」分析工具。目的是想让你了解不变的理论性的知识,以及与之对应的在安卓环境中可用的工具,这些可以让你少走一些弯路,直接复用前辈们的经验。

需要特别说明的是,对于性能优化肯定不止有这三个工具可用,但这个三个工具是我们平时用到的「第一手工具」。进行进一步分析之前,你都需要依赖这三个工具进行瓶颈定位,之后才应不同领域特性选择对应的工具进行下钻分析。

1 性能分析中的可观测性技术

  • 这个操作到底有没有被执行?执行时间有多长?
  • 为什么两个版本的前后差异这么大?
  • 当 CPU 使用量变高的时候系统都在执行什么操作?
  • 为什么启动速度变慢了?
  • 为什么这个页面滑动总是会卡一下?

相信你不止一次被同事、被老板问到过类似的问题。最原始的想法应该是,首先是拿到相关的日志进行逐个分析。根据以往经验,通过查找关键字寻找蛛丝马迹。如果没有想看的信息,那就加上日志尝试本地复现。费时费力不说,也还费研发资源。但你有没有想过行业里有没有更高效的方法?可以提高一个数量级的那种,把我们的时间花在问题解决上而不是无聊的重复性体力活儿上?

答案当然是有的(否则就不会有这篇文章了),我们称他为可观测性技术。

计算机行业发展至今,计算机前辈们捣鼓出了所谓的「可观测性技术」的类别。它研究的是通过工具,来观测复杂系统的运行细节,内容越细越好。 移动操作系统之前是由嵌入式发展而来的,现在的中高端安卓手机算力都能赶得上二十几年前的一个主机的算力,在此算力基础上所带来的软件复杂度也是非常巨大的。

如果你的程序部署了一个精心设计且运行良好的可观测性技术,可以大大加快研发软件的效率,因为即使我们使用了各种各样的前置性静态代码检测、人工代码审查,也无法 100% 拦截软件的问题。只有在真实环境里运行之后才知道是否真正发生了问题,即使这个环境可能是一个你的自动化测试用例。即使这样,你还需要翻阅你的日志,重读代码来找出问题。出于这些原因,每个工程团队都需要有一个功能完备的可观测性工具作为他们的基础设施之一。

可观测性技术是一个系统性工程,它能够让你更深入的了解软件里发生的事情。可用于了解软件系统内部运行过程(特别是对于业务逻辑或者交互关系复杂的系统)、排查问题甚至通过寻找瓶颈点优化程序本身。对于复杂的系统来说,你通过阅读代码来了解整个运行过程其实是很困难的事情,更高效的方法就是借助此类工具,以最直观的的方式获取软件运行的状态。

下面将从 数据类型、数据获取方法、分析方法 这三个主题来帮助你了解可观测性技术。

1.1 数据类型

日志的形式可能是键值对(key=Value),JSON、CSV,关系型数据库或者其他任何格式。其次我们通过日志还原出系统当时运行的整个状态,目的是为了解决某个问题,观察某个模块的运行方式,甚至刻画系统使用者的行为模式。在可观测性技术上把日志类型分类为 Log 类型、Metric 类型,以及 Trace 类型。

数据类型

Log 类型

Log 是最朴素的数据记录方式,一般记录了什么模块在几点发生了什么事情,日志等级是警告还是错误。 绝大部分系统,不管是嵌入式设备还是汽车上的计算机,他们所使用的日志形式几乎都是这种形式。这是最简单,最直接也最好实现的一种方式。几乎所有的 Log 类型是通过 string 类型的方式存储,数据呈现形式是一条一条的文本数据。Log 是最基本的类型,因此通过转换,可以将 Log 类型转换成 Metric 或者 Trace 类型,当然成本就是转换的过程,当数据量非常巨大的时候这可能会成为瓶颈。

为了标识出不同的日志类型等级,一般使用错误、警告、调试等级别来划分日志等级。显然,错误类型的是你首要关注的日志等级。不过实践中也不会严格按照这种方式划分,因为很多工程师不会严格区分他们之间的差异,这可能是他们的工程开发环境中不太会对不同等级的日志进行分类分析有关。总之,你可以根据你的目的,将 Log 类型进行等级划分,它就像一个索引一样,可以进一步可以提高分析问题、定位目标信息的效率。

Metric 类型

Metric 类型相比 Log 类型使用目的上更为聚焦,它记录的是某个维度上数值的变化。知识点是「维度」与「数值」的变化。维度可能是 CPU 使用率、CPU Cluster 运行频率,或者上下文切换次数。数值变化既可以是采样时候的瞬时值(成为快照型)、与前一次采样时的差值(增或减)、或者某个时段区间的统计聚合值。实践中经常会使用统计值,比如我想看问题发生时刻前 5 分钟的 CPU 平均使用量。这时候需要将这五分钟内的所有数值做算数平均计算,或者是加权平均(如: 离案发点越近的样本它的权重就越高)。Log 类型当然可以实现 Metric 类型的效果,但是操作起来非常麻烦而且其性能损耗可能也不小。

聚合是非常有用的工具,因为人不可能逐个分析所有的 Metric 值,因此借助聚合的方式判断是否出了问题之后再进行详细的分析是更为经济高效的方法。

Metric 类型的另外一个好处是它的内容格式是比较固定的,因此可以通过预编码的方式进行数据存储,空间的利用率会更紧凑进而占用的磁盘空间就更少。最简单的应用就是数据格式的存储上,如果使用 Log 类型,一般采用的是 ASCII 编码,而 Metric 使用的是整数或者浮点等固定 byte 数的数据,当存储较大数值时显然 ASCII 编码需要的字节数会多于数字型数据,并且在进行数据处理的时候你可以直接使用 Metric 数据,而不需要把 Log 的 ASCII 转换成数字型后再做转换。

除了是具体的数值之外,也可以存储枚举值(某种程度上它的本质就是数值)。不同的枚举值代表不同的意义,可能是开和关、可能是不同的事件类型。

Trace 类型

Trace 类型标识了事件发生的时间、名称、耗时。多个事件通过关系,标识出了是父与子还是兄弟。当分析多个线程间复杂的调用关系时 Trace 类型是最方便的数据分析方式。

Trace 类型特别适用于 Android 应用与系统级的分析场景,因为用它可以诊断:

  1. 函数调用链
  2. Binder 调用时的调用链
  3. 跨进程事件流跟踪

Android 的应用程序运行环境的设计中,一个应用程序是无法独自完成所有的功能的,它需要跟 SystemServer 有大量的交互才能完成它的很多功能。与 SystemServer 间的通讯是通过 Binder 完成,它的通讯方式后面的文章再详细介绍,到目前为止你只需要知道它的调用关系是跨进程调用即可。这需要本端与远端的数据才能准确还原出调用关系,Trace 类型是完成这种信息记录的最佳方式。

Trace 类型可以由你手动添加开始与结束点,在一个函数里可以添加多个这种区间。通过预编译技术或者编程语言的特性,在函数的开头与结尾里自动插桩 Trace 区间。理想情况下后者是最好的方案,因为我们能知道系统中运行的所有的函数是哪些、执行情况与调用关系是什么。可以拿这些信息统计出调用次数最多(最热点)的函数是什么,最耗时的函数又是什么。可想而知这种方法带来的性能损耗非常大,因为函数调用的频次跟量级是非常大的,越是复杂的系统量级就越大。

因此有一种迂回的方法,那就通过采样获取调用栈的方式近似拟合上面的效果。采样间隔越短,就越能拟合真实的调用关系与耗时,但间隔也不能太小因为取堆栈的操作本身的负载就会变高因为次数变多了。这种方法,业界管他叫 Profiler,你所见过的绝大部分编程语言的 Profiler 工具都是基于这个原理实现的。

1.2 数据获取方法

数据获取方法

静态代码与动态跟踪

静态代码的采集方式是最原始的方式,优点是实现简单缺点是每次新增内容的时候需要重新编译、安装程序。当遇到问题之后你想看的信息恰好没有的话,就没有任何办法进一步定位问题,只能重新再来一遍整个过程。更进一步的做法是预先把所有可能需要的地方上加入数据获取点,通过动态判断开关的方式选择是否输出,这既可以控制影响性能又能够在需要日志的时候可以动态打开,只不过这种方法的成本非常高。

动态跟踪技术其实一直都存在,只是它的学习成本比较高,被誉为调试跟踪领域里的屠龙刀。它需要你懂比较底层的技术,特别是编译、ELF 格式、内核、以及熟悉代码中的预设的探针、动态跟踪所对应的编程语言。对,你没看错,这种技术甚至还有自己的一套编程语言用于「动态」的实现开发者需求。这种方式兼具性能、灵活性,甚至线上版本里遇到异常后可以动态查看你想看的信息。

Android 应用开发、系统级开发中用的比较少,内核开发中偶尔会用一些。只有专业、专职的性能分析人员才可能会用上这类工具。它有两个关键点,探针与动态语言,程序运行过程中需要有对应的探针点将程序执行权限交接到动态跟踪框架,框架执行的逻辑是开发者使用动态语言来编写的逻辑。

所以,你的程序里首先是要有探针,好在 Linux 内核等框架埋好了对应的探针点,但是 android 应用层是没有现成的。所以目前 Android 上能用动态框架,如 eBPF 基本都是内核开发者在使用。

无条件式抓取与有条件式抓取

无条件式抓取比较好理解,触发抓取之后不管发生任何事情,都会持续抓取数据。缺点是被观测对象产生的数据量非常大的时候可能会对系统造成比较大的影响,这种时候只能通过降低数据量的方式来缓解。需要做到既能满足需求,性能损失又不能太大。

有条件式抓取经常用在可以识别出的异常的场景里。比如当系统的某个观测值超过了预先设定的阈值时,此时触发抓取日志并且持续一段时间或者达到另外一种阈值之后结束抓取。这相比于前面一个方法稍微进步了一些,仅在出问题的时候对系统有影响,其他时候没有任何影响点。但它需要你能够识别出异常,并且这种异常是不需要异常发生之前的历史数据。当然你可以通过降低阈值来更容易达到触发点,这可能会提高触发数据抓取的概率,这时候会遇到前面介绍的无条件式抓取遇到的同样的问题,需要平衡性能损失。

落盘策略

持续落盘是存储整个数据抓取过程中的所有数据,代价是存储的压力。如果能知道触发点,比如能够检测到异常点,这时候可以选择性的落盘。为了保证历史数据的有效性,因此把日志先暂存储到 RingBuffer 中,只有接受到落盘指令后再进行落盘存储。这种方式兼顾了性能与存储压力,但成本是运行时内存损耗与触发器的准确性。

1.3 分析方式

分析方式

数据可视化分析

随着问题分析的复杂化,出现了要解决多个模块间交互的性能问题需求,业界就出现了以时间为横轴把对应事件放到各自泳道上的数据可视化分析方法,可以方便的看到所关心事件什么时候发生、与其他系统的交互信息等等。在 Android 里我们常用的 Systrace/Perfetto 以及更早之前的 KernelShark 等工具本质上都是这一类工具。在「数据类型」提到的 「Trace 类型」,经常采用这种可视化分析方法。

Systrace 的可视化框架是基于 Chrome 的一个叫 Catapult 的子项目构建。Trace Event Format 讲述了 Catapult 所支持的数据格式,如果你有 Trace 类型的数据,完全可以使用此框架来展示可视化数据。AOSP 编译系统,安卓应用的编译过程,也都有相应的 Trace 文件输出,它们也都基于 Catapult 实现了可视化效果。

数据库分析

面对大量数据分析的分析,通过对数据进行格式化,把他们转换成二维数据表,借助 SQL 语言可实现高效的查询操作。在服务器领域中 ELK 等技术栈可以实现更为灵活的格式化搜索与统计功能。借助数据库与 Python,你甚至可以实现一套自动化数据诊断工具链。

从上面的讨论可知,从文本分析到数据库分析他们要面对的分析目的是不一样的。单纯的看一个模块的耗时用文本分析就够用了,多个系统间的交互那就要用可视化工具,复杂的数据库分析就要用到 SQL 的工具。无论哪种分析方式,本质上都是针对数据的分析,在实战中我们经常会通过其他工具对数据进行转换以支持不同的分析方式,比如从文本分析方式改成数据库分析方式。

根据自己的目的,选择合适的分析方式才会让你的工作事倍功半。

对于 Android 开发者来说,Google 提供了几个非常重要的性能分析工具,帮助系统开发者、应用开发者来优化他们的程序。

2 谷歌提供的 Andorid 性能分析工具

从实践经验来看最常用的工具有 Systrace,Perfetto 与 Android Studio 中的 Profiler 工具。通过他们定位出主要瓶颈之后,你才需要用到其他领域相关工具。因此,会重点介绍这三个工具的应用场景,它的优点以及基本的使用方法。 工具之间的横向对比,请参考下一个「综合对比」这一章节的内容。

2.1 初代系统性能分析工具 - Systrace

Systrace 是 Trace 类型的可视化分析工具,是第一代系统级性能分析工具。Trace 类型所支持的功能它都有支持。在 Perfetto 出现之前,基本上是唯一的性能分析工具,它将 Android 系统和 App 的运行信息以图形化的方式展示出来,与 Log 相比,Systrace 的图像化方式更为直观;与 TraceView 相比,抓取 Systrace 时候的性能开销基本可以忽略,最大程度地减少观察者效应带来的影响。

Systrace

Systrace 的设计思路

系统的一些关键操作(比如 Touch 操作、Power 按钮、滑动操作等)、系统机制(input 分发、View 绘制、进程间通信、进程管理机制等)、软硬件信息(CPU 频率信息、CPU 调度信息、磁盘信息、内存信息等)的关键流程上,插入类似 Log 的信息,我们称之为 TracePoint(本质是 Ftrace 信息),通过这些 TracePoint 来展示一个核心操作过程的执行时间、某些变量的值等信息。然后 Android 系统把这些散布在各个进程中的 TracePoint 收集起来,写入到一个文件中。导出这个文件后,Systrace 通过解析这些 TracePoint 的信息,得到一段时间内整个系统的运行信息。

Android 系统中,一些重要的模块都已经默认插入了一些 TracePoint,通过 TraceTag 来分类,其中信息来源如下

  1. Framework Java 层的 TracePoint 通过 android.os.Trace 类完成
  2. Framework Native 层的 TracePoint 通过 ATrace 宏完成
  3. App 开发者可以通过 android.os.Trace 类自定义 Trace

这样 Systrace 就可以把 Android 上下层的所有信息都收集起来并集中展示,对于 Android 开发者来说,Systrace 最大的作用就是把整个 Android 系统的运行状态,从黑盒变成了白盒。全局性和可视化使得 Systrace 成为 Android 开发者在分析复杂的性能问题的时候的首选。

实践中的应用情况

解析后的 Systrace 由于有大量的系统信息,天然适合分析 Android App 和 Android 系统的性能问题, Android 的 App 开发者、系统开发者、Kernel 开发者都可以使用 Systrace 来分析性能问题。

  1. 从技术角度来说,Systrace 可覆盖性能涉及到的 响应速度卡顿丢帧ANR 这几个大类。
  2. 从用户角度来说,Systrace 可以分析用户遇到的性能问题,包括但不限于:
    1. 应用启动速度问题,包括冷启动、热启动、温启动
    2. 界面跳转速度慢、跳转动画卡顿
    3. 其他非跳转的点击操作慢(开关、弹窗、长按、选择等)
    4. 亮灭屏速度慢、开关机慢、解锁慢、人脸识别慢等
    5. 列表滑动卡顿
    6. 窗口动画卡顿
    7. 界面加载卡顿
    8. 整机卡顿
    9. App 点击无响应、卡死闪退

在遇到上述问题后,可以使用多种方式抓取 Systrace ,将解析后的文件在 Chrome 打开,然后就可以进行分析

2.2 新一代性能分析全栈工具 - Perfetto

谷歌在 2017 年开始了第一笔提交,随后的 4 年(截止到 2021.12)内总共有 100 多位开发者提交了近 3.7W 笔提交,几乎每天都有 PR 与 Merge 操作,是一个相当活跃的项目。 除了功能强大之外其野心也非常大,官网上号称它是下一代面向可跨平台的 Trace/Metric 数据抓取与分析工具。应用也比较广泛,除了 Perfetto 网站,Windows Performance ToolAndroid Studio,以及华为的 GraphicProfiler 也支持 Perfetto 数据的可视化与分析。 我们相信谷歌还会持续投入资源到 Perfetto 项目,可以说它应该就是下一代性能分析工具了,会完全取代 Systrace。

提供的亮点功能

Perfetto 相比 Systrace 最大的改进是可以支持长时间数据抓取,这是得益于它有一个可在后台运行的服务,通过它实现了对收集上来的数据进行 Protobuf 的编码并存盘。从数据来源来看,核心原理与 Systrace 是一致的,也都是基于 Linux 内核的 Ftrace 机制实现了用户空间与内核空间关键事件的记录(ATRACE、CPU 调度)。Systrace 提供的功能 Perfetto 都支持,由此才说 Systrace 最终会被 Perfetto 替代。

Perfetto

Perfetto 所支持的数据类型、获取方法,以及分析方式上看也是前所未有的全面,它几乎支持所有的类型与方法。数据类型上通过 ATRACE 实现了 Trace 类型支持,通过可定制的节点读取机制实现了 Metric 类型的支持,在 UserDebug 版本上通过获取 Logd 数据实现了 Log 类型的支持。

你可以通过 Perfetto.dev 网页、命令行工具手动触发抓取与结束,通过设置中的开发者选项触发长时间抓取,甚至你可以通过框架中提供的 Perfetto Trigger API 来动态开启数据抓取,基本上涵盖了我们在项目上能遇到的所有的情境。

在数据分析层面,Perfetto 提供了类似 Systrace 操作的数据可视化分析网页,但底层实现机制完全不同,最大的好处是可以支持超大文件的渲染,这是 Systrace 做不到的(超过 300M 以上时可能会崩溃、可能会超卡)。在这个可视化网页上,可以看到各种二次处理的数据、可以执行 SQL 查询命令、甚至还可以看到 logcat 的内容。Perfetto Trace 文件可以转换成基于 SQLite 的数据库文件,既可以现场敲 SQL 也可以把已经写好的 SQL 形成执行文件。甚至你可以把他导入到 Jupyter 等数据科学工具栈,将你的分析思路分享给其他伙伴。

比如你想要计算 SurfaceFlinger 线程消耗 CPU 的总量,或者运行在大核中的线程都有哪一些等等,可以与领域专家合作,把他们的经验转成 SQL 指令。如果这个还不满足你的需求, Perfetto 也提供了 Python API,将数据导出成 DataFrame 格式近乎可以实现任意你想要的数据分析效果。

这一套下来供开发者可挖掘的点就非常多了,从笔者团队的实践来看,他几乎可以覆盖从功能开发、功能测试、CI/CD 以及线上监控、专家系统等方方面面。本星球的后续系列文章中,也会重点介绍 Perfetto 的强大功能与基于它开发的专家系统,可以帮助你「一键解答」性能瓶颈。

实践中的应用情况

性能分析首要用到的工具就是 Perfetto,使用 Systrace 的场景是越来越少了。所以,你首要掌握的工具应该是 Perfetto,学习它的用法以及它提供的指标。

不过 Perfetto 也有一些边界,首先它虽然提供了较高的灵活性但本质上还是静态数据收集器,不是动态跟踪工具,跟 eBPF 还是有本质上的差异。其次运行时成本比较高,因为涉及到在手机中实现 Ftrace 数据到 Perfetto 数据的转换。最后他不提供文本分析方式,只能通过网页可视化或者操作 SQLite 来进行额外的分析了。综合来看 Perfetto 是功能强大,几乎涵盖了可观测性技术的方方面面,但是使用门槛也比较高。值得挖掘与学习的知识点比较多,我们后续的文章中也会重点安排此部分的内容。

2.3 Android Studio Profiler 工具

Android 的应用开发集成环境(官方推荐)是 Android Studio (之前是Eclipse,不过已经淘汰了) ,它自然而然也需要把开发和性能调优集成一起。非常幸运的是,随着 Android Studio 的迭代、演进,到目前,Android Studio 有了自己的性能分析工具 Android Profiler,它是一个集合体,集成了多种性能分析工具于一体,让开发者可以在 Android Studio 做开发应用,也不用再下载其它工具就能让能做性能调优工作。

目前 Android Studio Profiler 已经集成了 4 类性能分析工具: CPU、Memory、Network、Battery,其中 CPU 相关性能分析工具为 CPU Profiler,也是本章的主角,它把 CPU 相关的性能分析工具都集成在了一起,开发者可以根据自己需求来选择使用哪一个。可能很多人都知道,谷歌已经开发了一些独立的 CPU 性能分析工具,如 Perfetto、Simpleperf、Java Method Trace 等,现在又出来一个 CPU Profiler,显然不可能去重复造轮子,CPU Profiler 目前做法就是:从这些已知的工具中获取数据,然后把数据解析成自己想要的样式,通过统一的界面展示出来。

提供的亮点功能

CPU Profiler 集成了性能分析工具:Perfetto、Simpleperf、Java Method Trace,它自然而然具备了这些工具的全部或部分功能,如下:

  1. System Trace Recording,它是用 Perfetto 抓取的信息,可用于分析进程函数耗时、调度、渲染等情况,但是它一个精简版,只能显示进程强相关的信息且会过滤掉耗时短的事件,建议将 Trace 导出文件后在 https://ui.perfetto.dev/ 上进行分析。
  2. Java Method Trace Recording,它是从虚拟机获取函数调用栈信息,用于分析 Java 函数调用和耗时情况。
  3. C/C++ Function Trace,它是用 Simpleperf 抓取的信息,Simpleperf 是从 CPU 的性能监控单元 PMU 硬件组件获取数据。 C/C++ Method Trace 只具备 Simpleperf 部分功能,用于分析 C/C++ 函数调用和耗时情况。

CPU Profiler

实践中的应用情况

应用的性能问题主要分为两类:响应慢、不流畅。

  • 响应慢问题常有:应用启动慢、页面跳转慢、列表加载慢、按钮响应慢等
  • 不流畅问题常有:列表滑动不流畅、页面滑动不跟手、动画卡顿等

CPU Profiler 在这些场景中要如何使用呢?基本的思路是:首先就要抓 System Trace,先用System Trace 分析、定位问题,如果不能定位到问题,再借助 Java Method Trace 或 C/C++ Function Trace 进一步分析定位。

以一个性能极差的应用为例,在系统的关键位置插了 Systrace TracePoint,假设对代码不熟悉,那要怎么找到性能瓶颈呢?我们先把应用跑起来,通过 CPU Profiler 录制一个 System Trace (后面文章会介绍工具的使用方法)如下:

通过上面 Trace 可以知道是在 egl_core 线程中的 onDrawFrame 操作耗时,如果发现不了问题,建议导出到 https://ui.perfetto.dev/ 进一步分析,可以查找源代码看看 onDrawFrame 是什么东西, 我们通过查找发现 onDrawFrame 是 Java 函数 onDrawFrame 的耗时,要分析 Java 函数耗时情况,我们要录制一个 Java Method Trace,如下:

通过上面 Trace 很容易发现是一个叫做 Utils.onDraw 的 native 函数耗时,因为涉及到C/C++ 代码,所以要再录制一个 C/C++ Function Trace 进一步分析,如下:

可以发现在 native 的 Java_com_gl_shader_Utils_onDraw 中代码执行了 sleep,它就是导致了性能低下的罪魁祸首!

AS 中的 CPU Profiler 最大优势是集成了各种子工具,在一个地方就能操作一切,对应用开发者来说是非常方便的,不过对系统开发者来说可能没那么幸运。

2.4 综合对比

工具名称应用场景数据类型获取方法分析方式
SystraceAndroid 系统与应用性能分析Trace 类型无条件抓取 持续落盘可视化分析
PerfettoAndroid 系统与应用性能分析Metric 类型 Trace 类型无条件抓取 持续落盘可视化分析 数据库分析
AS ProfilerAndroid 系统与应用性能分析Trace 类型无条件抓取 持续落盘可视化分析
SimplePerfJava/C++ 函数执行耗时 分析 PMU 计数器Trace 类性无条件抓取 持续落盘可视化分析 文本分析
Snapdragon Profiler Tools & Resources主要是高通 GPU 性能分析器Trace 类型 Metric 类型无条件抓取 持续落盘可视化分析
Mali Graphics DebuggerARM GPU 分析器(MTK、麒麟芯片)Trace 类型 Metric 类型无条件抓取 持续落盘可视化分析
Android Log/dumpsys综合分析Log 类型有条件抓取 持续抓取但不落盘文本分析
AGI(Android GPU Inspector)Android GPU 分析器Trace 类型 Metric 类型无条件抓取 持续落盘可视化分析
eBPFLinux 内核行为动态跟踪Metric 类型动态跟踪 有条件抓取 持续抓取但不落盘文本分析
FTraceLinux 内核埋点Log 类型静态代码 有条件抓取 持续抓取但不落盘文本分析

3 关于「器、术、道」

技术上的变革、改进更多是体现在「器」层面,Linux 社区以及谷歌所开发的工具发展方向朝着提高工具的集成化使得在一个地方可以方便查到所需的信息、或者是朝着获取更多信息的方向发展。总之,器层面他们的发展轨迹是可寻的,可总结出发展规律。 我们需要在工具快速迭代的时候准确的认识到他们能力以及应用场景,其目的是提高解决问题的效率,而不是把时间花在学习新工具上。

「术」层面依赖具体的业务知识,知道一帧是如何被渲染的、CPU 是如何选择进程调度的、IO 是如何被下发的等等。只有了解了业务知识才能正确的选择工具并正确的解读工具所提供的信息。随着经验的丰富,有时候你都不需要看到工具提供的详细信息,也可以查到蛛丝马迹,这就是当你业务知识丰富到一定程度,大脑里形成了复杂的关联性信息之后凌驾于工具之上的一种能力。

「道」层面思考的是要解决什么问题,问题的本质是什么?做到什么程度以及需要投入什么样的成本达成什么样的效果。为了解决一个问题,什么样的路径的「投入产出比」是最高的?整体打法是什么样?为了完成一件事,你首先要做什么其次是做什么,前后依赖关系的逻辑又是什么?

后续的文章中,会依照「器、术、道」方式讲解一个技术、一个功能,我们不止想让你学习到一个知识点,更想激发你举一反三的能力。遇到类似的工具或者类似的问题、更进一步是完全不同的系统,都能够从容应对。牢牢抓住本质,通过评估「投入产出比」选择合适的工具或信息,高效解决问题。

4 关于「The Performance 知识星球」

为了更好地交流与输出高质量文章,我们创建了名为 「The Performance」的知识星球,主理人是三个国内一线手机厂商性能优化方面的一线开发者,有多年性能相关领域的工作经验,提供Android 性能相关的一站式知识服务,涵盖了基础、方法论、工具使用和最宝贵的案例分析。

目前星球的内容规划如下(两个 ## 之间的是标签,相关的话题都会打上对应的标签,方便大家点击感兴趣的标签查看对应的知识)

  • #The Performance# — 可以提早阅读「Android 性能优化 - 系统性课程」的电子书,每周会放出已经写好的章节。「Android 性能优化 - 系统性课程」是我们规划的一本讲 Android 性能优化的电子书,目前开发者社区有相当多高质量的性能优化理论知识和实践文章和开源库,但是目前市面上缺乏一个完整的、系统性的、包含了性能优化原理、工具、实践等内容、面向初级开发中和中级开发者、面向 App 开发者和系统开发者,且持续更新的 Android 性能优化工具书。书的大纲 (暂定) 我们已经基本上列好了,预计会花费一年左右的时间来完成,在星球中会放出写好的章节,让大家提前看到。
    • Part 1: → 性能工程
    • Part 2: → 以性能角度分析 Android 交互与核心系统
    • Part 3: → 以性能角度分析 Linux 内核核心子系统设计与实现
    • Part 4: → 问题场景分析思路
    • Part 5: → 分析与调试工具
    • Part 6: → 质量守护 - 性能监控方法与工具
  • #性能工具# — 分享 Android 开发中使用到的性能分析工具以及其使用方法,同时也提供 1V1 的 Systrace、Perfetto 等性能工具的视频指导。性能工具的使用,最好还是以视频的方式展示会直观很多,文章是静态的,很多地方比较难讲清楚,1V1 的视频会议指导也算是一个学习的方法
  • #案例分析# — 典型案例分析思路总结、球友提供的案例分析与讨论。案例分析是学习的一个很重要的途径,阅读大量的实际性能案例对以后自己分析和解决性能问题是非常有帮助的,同时也欢迎大家提供案例和解决方法,怕泄露信息的话,我们会对关键信息进行打码
  • #经典解读# — 经典方案、课程重读,例如优秀的三方库解析、Android 开发高手课重读等。比如可以对方案进行深度的剖析,横向对比等;对 Android 开发高手课进行重读和查漏补缺
  • #知识分享# — 优秀文章、博客、工具分享。业界有很大大牛的博客、经过实际业务考验的开源方案、各种性能工具等,我们会寻找这些优秀的内容,分享给大家
  • #知识沉淀# — 微信群聊精华、微信问答、博客留言解答等
  • #性能面试# — Android 性能相关的面试题搜集和解答,也算是刚需了吧
  • #编程语言# — 编程语言相关的使用技巧分享
  • #效能提升# — 效能提升分享,包括开发者开发效能、工作效能提升方法、工程效率、工具推荐等,磨刀不误砍柴工嘛
  • #行业动态# — 性能相关新技术第一时间解读报告,包括但不限于下面的内容
    • 行业峰会、学术峰会新思路解读报告
    • 论文、行业、书籍介绍、视频
    • Android 大版本性能相关介绍
    • Android 新硬件性能相关内容介绍
    • Android 性能相关开源项目解读
  • #大咖分享# — 每月定期邀请行业大咖进行经验分享、案例分析
  • #工作内推# — 各大厂商内推工作机会介绍

TeamWork - 付费知识星球

注意: iOS 手机用户不要直接在星球里面付款,在微信界面长按图片扫描二维码加入即可,否则苹果会收取高昂的手续

5 附录

关于我 && 博客

  1. 关于我 , 非常希望和大家一起交流 , 共同进步 .
  2. 博客内容导航
  3. 优秀博客文章记录 - Android 性能优化必知必会

一个人可以走的更快 , 一群人可以走的更远

微信扫一扫

回顾 2021

2021 已经过去,趁着元旦假期,回顾一下 2021,随意一些,想到哪里写哪里吧。主要是对 2021 年的一个回顾,以及 2022 年的展望,2021 年当了爸爸,换了工作(中间还居家无聊了好久),收获了更多的朋友,也算是过的还可以

不过在个人成长方面,甚至感觉有点退步,这让我觉得有点慌,学如逆水行舟,不进则退,2022 年是需要好好深耕的一年,希望能和看到这篇文章的同学一起进步,共勉

另外也盘点了一下知识分享相关的数据,分享了一下这方面的收入,个人新增和推荐的硬件、个人推荐的软件等,感兴趣的可以自取

2021 最大收获 - 小橘子

今年的最大收获那必然是家里多了一个小橘子,体验了一下当爸爸的感觉,多了个小棉袄,双人行变成了三人行,到现在快十个月了,妥妥小天使。我们对小橘子要求不高,健健康康快快乐乐长大就可以了,老父亲老母亲是你坚强的后盾
橘子小棉袄

知识分享数据统计

个人博客数据

博客 2021 新增了 8 篇文章(Systrace 系列总算是完结了,总共 18 篇内容,你们先看,我去准备准备 Perfetto 版本的….)

  1. Systrace 流畅性实战 1 :了解卡顿原理 - https://www.androidperformance.com/2021/04/24/android-systrace-smooth-in-action-1/
  2. Systrace 流畅性实战 2 :案例分析 - MIUI 桌面滑动卡顿分析 - https://www.androidperformance.com/2021/04/24/android-systrace-smooth-in-action-2/
  3. Systrace 流畅性实战 3 :卡顿分析过程中的一些疑问 - https://www.androidperformance.com/2021/04/24/android-systrace-smooth-in-action-3/
  4. Systrace 响应速度实战 1 :了解响应速度原理 - https://www.androidperformance.com/2021/09/13/android-systrace-Responsiveness-in-action-1/
  5. Systrace 响应速度实战 2 :响应速度实战分析 - 以启动速度为例 - https://www.androidperformance.com/2021/09/13/android-systrace-Responsiveness-in-action-2/
  6. Systrace 响应速度实战 3 :响应速度延伸知识 - https://www.androidperformance.com/2021/09/13/android-systrace-Responsiveness-in-action-3/
  7. Android 系统开发系列(1):Android 12 源代码下载、编译和刷机 - https://www.androidperformance.com/2021/10/26/build-android-12/
  8. 一本讲 Android 流畅性的书,应该有什么内容? - https://www.androidperformance.com/2021/10/27/if-i-write-a-book-about-performance/

一年就写了这几篇文章,跟年初定的目标 一周一篇 差的实在是有点远,就离谱(2022 年不能再立这种 Flag 了,量力而行,一个月两篇我觉得还可以一战。

另外去年还维护了一个 Android Weekly 的知乎专栏,感兴趣的也可以订阅一下 https://www.zhihu.com/column/c_1278963991947780096)

博客 AndroidPerformance 使用了 Google Analytics 来进行统计,我看了一下 2021 和 2020 年的对比数据,还是不错的,下面是 Google Analytics 的统计数据

**访问用户数 **对比 2020 年增长了 38.9%,总的来说还是不错的(那几个明显的低谷是新年假期、五一和十一,好好过节,咱不卷)

用户最常访问的页面,还是主要以 Android Systrace 系列为主

微信公众号数据

微信公众号 AndroidPerformance 的关注数目前是 :7364,由于原创文章不多,且有很多转载,所以公众号增长比较慢,活跃的都是老用户了。微信公众号文章由于是封闭的,所以数据没有什么意义,就不贴了,希望 2022 能突破 1W 吧

微信公众号主要是微信里面阅读方便,但是对于写作的人来说就没那么友好了,主要是没法贴微信之外的超链接,这个设定也太 XX 了,把互联网搞成了局域网,无力吐槽

微信扫一扫关注公众号

知乎

知乎 的关注者目前有 2W+ ,不过知乎貌似越来越不重视技术这一块了,所以也就没怎么活跃了,刷到的文章和回答大部分都是搬运工或者水军,遇到好的文章都要赶紧点赞收藏分享一键三连,后续还是刷刷即刻和 Twitter 吧,上面的真实活跃开发者还是多

掘金

掘金 技术氛围还是很浓厚的,我也经常刷,不过总感觉掘金差了点啥,又说不上来是啥… 掘金的粉丝可以忽略不计了,不过后续有技术文章还是会同步上去的(你不同步,就会有人替你同步,当然作者就换人了)

即刻

即友可以加个好友

即刻

其他平台

  1. CSDN ……可以忽略
  2. 微博 ……可以忽略
  3. Twitter :关注了很多国内外的技术大佬,技术氛围还是蛮不错的

赚钱?交个朋友而已

今天听了 Happy Xiao 的播客,讲了他一年下来,通过知识分享的各个平台,每个月大概有 2500 RMB 左右的收入,所以也想了想自己去年一年在这方面的收入,想想也还蛮惨淡的

  1. 博客收入:0 ,甚至应该还是负的,因为还有域名+服务器的费用….
  2. 微信公众号:因为我没有开文中广告,所以广告收入几乎可以忽略不计,主要是靠各位的打赏了,我看了下打赏数据,总共是 1039
  3. 小专栏:总共 560

所以算下来,总收入是 1039 + 560 = 1596 。平均每个月 133,可见是真的不赚钱……用老罗的话来说,交个朋友..不过真心感谢微信打赏的小伙伴,每天早餐加个蛋就靠你们了(各位想赞赏的话,可以扫描文末的二维码,随便找一篇原创的文章打赏即可)

说到交个朋友,确实今年新加了很多技术的小伙伴,拉了四个微信群,时不时在群里水一水,在群里总的感觉是:群除我佬,时常怀疑自己是不是出现在了错的地方。说到底还是太菜,很多东西都不知道,或者一知半解。立个 Flag:今年要把基础打牢,知识体系化,争取跟上群里的大佬们的讨论

微信赞赏码,各位觉得有用,可以加个鸡腿

微信赞赏码

2022 有什么计划?

新年立 Flag 一般就那几样,我也没法免俗,不管怎么说先立了再说,等后续细化成每周每天的行动项,说不定就成了呢?

  1. 健身:应该还是主要以 走路上下班 + 篮球 + 跑步 + 划船机 + 家里的健身器材为主(抱橘橘也算是一种健身了)
  2. 强化英语阅读和听说:最近在有意识地听英文播客、看比较好懂的英文视频、看英文版本的文章和电子书,iPad 上的分屏看英文电子书配合有道词典,左边复制右边自动翻译+加入生词本,还是很不错的
  3. 知识体系化读和写更多的代码读更多的书、写一本 性能相关电子书
  4. **更频繁地更新 博客**:这个 flag 上面已经立了
  5. **跟小团队运营好 The Performance 知识星球(2022-06-20更新:暂时停止付费星球加入)**:一个人的力量还是太小了,跟几个小伙伴搞了一个收费版本的知识星球,希望能提供服务的同时,也给自己一点压力(你不压榨压榨自己,怎么知道自己不能用来榨油呢?)
  6. 尝试一些新鲜的东西:试试播客、视频、VLog 、拍照等
  7. 夯实基础,高效工作:多思考,多总结,多分享,多读书,多写代码,用工具提升工作效率

 TeamWork - 付费知识星球

2021 有什么软件推荐?

2021 用的最舒心的软件

  1. Notion,笔记软件,谁用谁知道:https://www.notion.so/
  2. Typora,笔记软件,Blog 就是用这个写的:https://typora.io/
  3. Github Copilot,你的 AI 编程伴侣:https://copilot.github.com/
  4. flomo,笔记软件,记录转瞬即逝的小想法:https://flomoapp.com/
  5. DeepL,号称全球最准确的翻译:https://www.deepl.com/zh/translator

DeepL

2021 有什么硬件推荐?

2021 还是折腾了不少硬件的,觉得还不错的推荐给大家

  1. NAS,家庭私有云:https://item.jd.com/100014187272.html
  2. 静电容键盘,机械键盘退烧神器,程序员和文字工作者必备:https://item.jd.com/100013910167.html
  3. 小米的 27 寸 4K 显示器,你买不了吃亏,买不了上当:https://item.jd.com/100016659987.html
  4. Apple TV 4K,也就是最新的那款,请注意这玩意有前置条件,如果你都满足,那么我推荐你搞一个,部分满足也行,就是体验会打一些折扣(1. 你有一种科学上网的方法 2. 你有一个软路由或者旁路由 3. 你有一台 NAS 4. 你有一台 4K 电视 5. 你有港区或者美区的 AppleID 6.你有一台 iphone):https://npcitem.jd.hk/100011599035.html
  5. 趣动乐 JOY25 电动升降桌,1.8m 的宽度是真的爽,乐歌就没这么宽的,感觉可以用个 10 年,站累了坐一会,坐累了站一会,吃嘛嘛香,身体倍儿棒!https://item.jd.com/10043115461593.html

我的家庭工作环境

2022 最想要什么?

池大已经替我说了,我感觉我手上这台闲鱼淘的 M1 版本的 Mac Mini,在 M1 Max 芯片的 MacBook Pro 面前瞬间就不香了,操作起来也变卡了……一定是库克在远程施法了

池大的微博

不过想要归想要,需要归需要,要理性消费(Mini 坏了的话就可以换了)

话说这个椅子也太好看了吧!(https://item.taobao.com/item.htm?id=614505490996 各位自取)
躺椅

当然还有最新款的 iPhone 13 Pro Max 谁会拒绝呢?

image-20220104001033091

结尾

2021 总的来说工作上不怎么理想,生活上有了小棉袄还是添加了不少乐趣,个人成长上几乎停滞,有各方面的原因,归根结底还是自己对自己的要求太低了,逆水行舟,不进则退

希望 2022 年能和看到这篇文章的各位一起努力,共勉!

关于我 && 博客

  1. 关于我 , 非常希望和大家一起交流 , 共同进步
  2. 博客内容导航
  3. 优秀博客文章记录 - Android 性能优化必知必会

一个人可以走的更快 , 一群人可以走的更远

微信扫一扫

一本讲 Android 流畅性的书,应该有什么内容?

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

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

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

打造

内容介绍

简单介绍一下这本书的内容,其章节如下

  1. 概述 :简单介绍为何要做性能优化,以及 Android Studio 的配置
  2. 静态代码审查 :大篇幅降了各种静态代码审查工具,比如 Android Lint 、CheckStyle、SpotBugs、PMD 等,除了 Lint 其他的我接触不多,也算是查漏补缺了
  3. 使用 Android Profiler 优化性能 :主要降了 AS Profiler 工具里面的 CPU Profiler、Memory Profiler、Network Profiler、Network Profiler ,这里主要重点是工具的使用,大概性地介绍了一下
  4. 高质量的 App 从架构开始:主要是架构原则、MVC、MVP、MVVM 这些
  5. 优雅地保活 App :简单介绍了下保活相关的技术
  6. 网络性能优化专题 :网络交互与多线程 + 海量数据传输优化
  7. 优化 APK 体积 :老生常谈的 APK 大小优化,多渠道打包 + 优化资源文件 + 代码混淆
  8. App 耗电及 Crash 体验优化:简单介绍了一下

从上面章节标题大家也可以看到,跟流畅性相关的内容比较少,内容相对会比较杂一些,感兴趣的可以买一本看看

我认为一本讲流畅性的书,应该有什么?

如果让我写这么一本书,我肯定是写不来的,非常钦佩能出书的技术小伙伴,给作者点个赞。

不过这并不妨碍我嘴炮打个山响(I am good at it):所以我觉得如果让我来写这本书,我会加入下面这些内容,确保大家通过这本书,就可以深入理解 Android 的流畅性原理,且可以熟练使用各种工具来分析所遇到的流畅性问题

鉴于在讨论 Android 性能问题的时候,卡顿(流畅性)响应速度ANR 这三个性能相关的知识点通常会放到一起来讲,因为引起卡顿、响应慢、ANR 的原因类似,只不过根据重要程度,被人为分成了卡顿(流畅性)、响应慢、ANR 三种,所以我们可以定义广义上的流畅性,包含了卡顿(流畅性)、响应慢和 ANR 三种,所以如果用户反馈说手机卡顿或者 App 卡顿(流畅性),大部分情况下都是广义上的卡顿(流畅性),需要搞清楚,到底出现了哪一种问题

所以我设想的章节应该包含下面的内容

  1. 第一章:Android 流畅性概述:这一章主要会讲性能相关的一些概念,包括从用户角度、开发角度、测试角度、AOSP 的角度、硬件角度等,讲述流畅性的一些概念。这一点很重要,因为在实践中发现,用户和开发、测试往往是同不同的角度来看待流畅度的,思考问题的时候别把自己的思维定在某一个角色,往往会有不一样的结果
  2. 第二章:Android 运行机制概述:这一章主要会讲一些 Android 运行机制相关的内容,了解这些知识点,对于分析 Android 流畅性问题是必须的,当下面这些知识点你非常熟悉之后,碰到流畅性的问题,你的脑海中就有一个图形化的工具在运转:用户怎么操作的、系统怎么反馈的、App 运行到了哪里、最有可能是哪里出现了问题、用什么工具去 Debug 最方便
    1. App 主线程运行原理(主线程和渲染线程)
    2. Message、Handler、MessageQueue、Looper 机制
    3. 屏幕刷新机制和 Vsync
    4. Choreogrepher 机制
    5. Buffer 工作流和 SurfaceFlinger 工作流
    6. Input 流程
    7. ANR 的设计思想
  3. 第三章:性能分析工具介绍:正所谓 工欲善其事必先利其器,趁手的工具对于分析性能问题至关重要,这一章主要会讲性能分析经常遇到的工具,并非是简单的介绍,会结合 Android 系统机制来讲解,工具主要包括但不限于 Systrace(Perfetto)AS ProfilerSimplePerfMATLog 工具(Log 内容分析和 Log 原理)、命令行工具(dumpsys meminfo、dumpsys gfxinfo、dumpsys cpuinfo、dumpsys SurfaceFlinger、dumpsys activity、dumpsys input、dumpsys window 等)、三方性能库(Koom、Matrix、Facebook profilo、BlockCanary、LeakCanary、Tailor/Raphael 等)
  4. 第四章:深入分析 Android 卡顿问题:运行机制和工具都介绍完了,那么接下来就是如何进行实战了,这一章主要会讲卡顿出现的原因、分析卡顿问题的套路、案例分享、编码最佳实践等
  5. 第五章:深入分析 Android 响应速度问题:同上,响应速度问题实战环节,这一章主要会讲响应速度问题出现的原因、分析响应速度问题的套路、案例分享、编码最佳实践等
  6. 第六章:深入分析 Android ANR 问题:ANR 也是用户体验的一部分,这里主要会讲 ANR 的设计思想、ANR 的几种类型、ANR 出现的原因、ANR 问题的分析套路、案例分享、编码最佳实践等(目测会有很大的篇幅)
  7. 第七章:深入分析 Android 内存问题:内存问题同样是影响用户体验一部分,而且是一个比较重要的性能指标,你懂得。本章会介绍 App 的内存占用、App 内存分析工具、内存泄漏分析、内存持续增长分析等,这里面的内容估计会牵扯到比较多的知识点,任重而道远啊….
  8. 第八章:性能测试:从测试的角度来看流畅性问题,这里会讲一些 性能指标获取(侵入式和非侵入式)性能标准制定竞品分析提 Bug 的标准和流程整机测试方法权威第三方的性能测试方法和标准介绍(绿色联盟、鲁大师、友盟、Bugly 等)性能监控工具开发(比如 Matrix、Koom、Fastbot、UI Automator、内存增长测试等),以及一些软技能:如何区分 Android 系统问题和 App 问题如何与开发和 PM 扯皮(开个玩笑)
  9. 第九章:线上性能监控:上一章讲的是本地性能测试,而这一章会讲线上是如何监控流畅度的,跟线下监控有区别的是,线上监控既要能体现真实的用户体验,又要尽量减少对用户的影响,还需要在发现问题的时候,能及时进行数据上报
  10. 第十章:系统性能优化介绍:App 开发者使用各种方法和黑科技来进行性能监控和性能分析,那么 Android 系统开发者又是如何做的呢?这一章会介绍一些各种厂商的性能优化、AOSP 的性能优化、高通和 MTK 的优化等
  11. 第十一章:高效工作指南:内容暂定,包括但不限于
    1. AOSP 代码编译的必要性和流程
    2. 阅读 AOSP 代码的技巧,比如 cs.android.com、导入 AS、导入 vscode 等、画流程图等
    3. Windows、Linux 、Mac 开发环境推荐、配置命令行等
    4. 工作方式推荐:多写、多记、多总结、多分享

嘴炮输出完毕,万事俱备,只欠大佬来完善内容了…

市面上还有哪些讲性能的书?

讲道理目前市面上的书都有点年代了,倒是掘金社区的 Android 性能优化文章非常多,各种大厂也乐意将他们的内部工具开源,给这些热爱分享小伙伴点个赞,让我们站在巨人的肩膀上前行

我本人看过的几本书

  1. 腾讯 TMQ 专项测试团队出的:《移动 App 性能评测与优化》,2016 年出版,专业性和实战拉满,值得一看,https://item.jd.com/11976603.html 微信读书:有电子书
  2. 邓老师的 《深入理解 Android:Java 虚拟机 ART》,ART 虚拟机的大部头书,对于了解 ART 虚拟机的运行有很大的帮助,App 的不少黑科技都会涉及到虚拟机 https://item.jd.com/12510921.html 微信读书:有电子书
  3. 道格・西勒斯(Doug Sillars)的 《高性能 Android 应用开发》,2016 年出版,英文原版更早一些,算是一个比较早的全方位讲解 Android App 性能的书了,感兴趣的可以收藏一本 https://item.jd.com/11995735.html 微信读书:没有电子书
  4. 腾讯大佬出的:《Android 应用性能优化最佳实践》,2017 年出版,内容也是性能相关 https://item.jd.com/12043655.html 微信读书:有电子书
  5. Brendan Gregg 大师新作:《BPF 之巅:洞悉 Linux 系统和应用性能》,中文版 2020 年出版,大部头工具书,屯之 https://item.jd.com/12769029.html 微信读书:没有电子书
  6. 同样是 Brendan Gregg 的 《性能之巅:洞悉系统、企业与云计算》,中文版 2020 年出版,大部头工具书,搞性能的应该人手一本… https://item.jd.com/12749867.html 微信读书:有电子书
  7. 张绍文的《Android 开发高手课https://time.geekbang.org/column/intro/142 最近重新听的感悟:高手就是高手
  8. 倪朋飞的 Linux 性能优化实践

写在最后

  1. 欢迎大家留言分享自己看过的觉得非常不错的 Android 性能相关的书籍、博客、视频课、官方教程等
  2. 欢迎大家留言分享你们认为一本讲 Android 流畅性的书,应该包含哪些内容
  3. 本文不涉及任何推广,大家放心食用
  4. 博客交流不方便,有疑问的可以在知乎或者微信公众号下面留言,或者直接加我微信(553000664),备注 Blog 即可
    1. 本文知乎地址:https://zhuanlan.zhihu.com/p/423605434
    2. 本文微信公众号地址:https://mp.weixin.qq.com/s/WUGWJx5FRJqXboQ2KKGRwA

关于我 && 博客

  1. 关于我 , 非常希望和大家一起交流 , 共同进步 .
  2. 博客内容导航
  3. 优秀博客文章记录 - Android 性能优化必知必会

一个人可以走的更快 , 一群人可以走的更远
微信扫一扫

Android 系统开发系列(1):Android 12 源代码下载、编译和刷机

Android 12 正式版 已经发布:https://mp.weixin.qq.com/s/OiFSWEnc-0N2z7JYWTJluw 。Android 12 正式版的代码也已经发布,官方文档 也进行了更新:https://source.android.google.cn/

本文就带大家下载和编译最新的 Android 12 代码,本地编译的代码有下面几个好处

  1. 可以刷真机,方便开发者进行本地 Debug,同时代码可以导入 Android Studio 进行 Debug
  2. 可以编译 Userdebug 版本,可以 root 和 remount,方便对系统和 App 进行 Debug,Debug 模式下可以看到许多 User 版本上看不到的问题;同时由于可以看到更多的信息,也方便进行 App 竞品分析、App 行为分析
  3. 可以更方便地进行 Android 源代码的学习,本地版本可以打开很多系统级别的 Debug Log,也可以自己加 Log,或者自己修改流程

如果大家没有下载编译 Debug 的需求,只是单纯的看代码的话,推荐使用 cs.android.com 即可。想深入了解 Android 系统的小伙伴和 Android 系统开发初学者可以看看,建议编译配置如下

  1. 闲鱼搞一个二手不带锁的 Pixel 3 以上(Android 12 只支持 Pixel 3 及以上)
  2. 一个有足够大硬盘(最好是 ssd)、足够大内存(最好是 32g,不行就设 swap)、没那么弱的 cpu(否则会影响编译时间)、安装了 Linux 的台式机

1. 代码下载

由于在国内使用 Google 的官方下载站点,会有下不动的情况,有时候 .repo 都下载不下来,所以本教程是以国内的镜像站点为例子,如果你有方法可以爬墙,那么可以简单参考 官方的教程 https://source.android.google.cn/source/downloading

科大 AOSP 镜像站点地址:https://mirrors.ustc.edu.cn/help/aosp.html

下载只需要跟着下面几个步骤走即可(以下方法可以在 Ubuntu、WSL、WSL2、Mac 上运行,但是后面进行代码编译的时候,只能使用 Linux ,所以建议大家还是使用 Ubuntu 这样的 Linux 系统来进行代码的下载、编译、开发工作)

1.1 步骤1:Repo 工具下载

1
2
3
4
mkdir ~/bin
PATH=~/bin:$PATH
curl -sSL 'https://gerrit-googlesource.proxy.ustclug.org/git-repo/+/master/repo?format=TEXT' |base64 -d > ~/bin/repo
chmod a+x ~/bin/repo

1.2 步骤2:配置个人信息

如果没有安装 git,先自己安装一下 git,然后执行下面的命令,填上自己的 Name 和 Email

1
2
git config --global user.name "Your Name" 
git config --global user.email "you@example.com"

比如我填的

1
2
git config --global user.name "Gracker"
git config --global user.email "dreamtale.jg@gmail.com"

1.2 步骤3:创建工程目录

在本地建立一个工作目录(名字任意,这里以 Android_12_AOSP 为例子)

1
2
mkdir Android_12_AOSP
cd Android_12_AOSP

1.4 步骤4:初始化仓库

仓库初始化有两种方式,一种是直接下载,另外一种是加 Tag,下载特定的 Tag 版本,下面会对这两种方法分别进行介绍,大家可以自己选择哪一种方式 (注意:这里的两种下载方式会影响后续的驱动下载,所以要记清楚自己使用的是哪种方式,在 驱动下载 章节选择合适的驱动

1.4.1 直接下载(推荐)

这种方法会下载所有的代码,默认分支是 master ,不愁空间的话,直接用这种方法下载即可

1
2
3
repo init -u git://mirrors.ustc.edu.cn/aosp/platform/manifest
## 如果提示无法连接到 gerrit.googlesource.com,可以编辑 ~/bin/repo,把 REPO_URL 一行替换成下面的:
## REPO_URL = 'https://gerrit-googlesource.proxy.ustclug.org/git-repo'

这里需要注意,默认的 repo 使用的地址是 REPO_URL = ‘https://gerrit.googlesource.com/git-repo‘ ,这里我们需要修改 REPO_URL,否则会出现无法下载的情况

  1. 修改方法1:在你的 rc 文件里面,加入一条配置即可:REPO_URL=”https://gerrit-googlesource.proxy.ustclug.org/git-repo
  2. 修改方法2:直接打开 ~/bin/repo, 把 REPO_URL 一行替换成下面的: REPO_URL = ‘https://gerrit-googlesource.proxy.ustclug.org/git-repo

下载好 .repo 之后会有下面的信息

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
➜  Android12 repo init -u git://mirrors.ustc.edu.cn/aosp/platform/manifest
Downloading Repo source from https://gerrit-googlesource.proxy.ustclug.org/git-repo

... A new version of repo (2.17) is available.
... You should upgrade soon:
cp /home/gracker/Code/Android12/.repo/repo/repo /home/gracker/bin/repo

Downloading manifest from git://mirrors.ustc.edu.cn/aosp/platform/manifest
remote: Enumerating objects: 91965, done.
remote: Total 91965 (delta 0), reused 0 (delta 0)

Your identity is: Gracker <dreamtale.jg@gmail.com>
If you want to change this, please re-run 'repo init' with --config-name

repo has been initialized in /home/gracker/Code/Android12

如果选择了直接下载,那么就不需要看 3.2 了

1.4.2 下载特定的 Tag

这种方法指的是只下载单个 Tag 所对应的代码,这里的 Tag 可以 查看这里 https://source.android.google.cn/setup/start/build-numbers,比如我的开发机是 Google Pixel 3 XL,我在 Tag 列表查看对应的机型都有哪些 TAG,目前 Android 12 只发布了两个,如下

对应的 Tag 分别是 android-12.0.0_r3 和 android-12.0.0_r1 ,所以下载的时候我可以制定对应的 TAG,这样的好处是下载的代码比较少,下载速度会快一些;不方便的点是更新不方便,Google 会定期发邮件告诉你哪些新的 Tag 发布了,你可以根据这个来更新代码

1
repo init -u git://mirrors.ustc.edu.cn/aosp/platform/manifest -b  android-12.0.0_r3

1.5 步骤5 :同步代码

上面步骤三只是下载了 .repo 文件,具体的代码还需要执行 repo sync 来进行下载。由于镜像站的限制和下载过程中可能会遇到的问题,建议大家用 -j4 来下载

1
repo sync -j4

然后就开始了漫长的下载,由于下载过程中可能会出现失败的情况,你可以搞一个 sh 脚步来循环下载,一觉醒来就下载好了

1
2
3
4
5
6
7
8
#!/bin/bash
repo sync -j4
while [ $? -ne 0 ]
do
echo "======sync failed ,re-sync again======"
sleep 3
repo sync -j4
done

具体方法

1
2
3
4
touch repo.sh  # 1. 创建 repo.sh 文件
vim repo.sh # 2. 复制上面的脚本内容到 repo.sh 里面,这里你可以使用你自己喜欢的方法打开并修改文件,比如 vscode
chmod a+x repo.sh #3. 修改权限
./repo.sh # 4. 运行脚本,万事大吉

2. 驱动下载

代码下载完成之后,我们先不着急编译,如果要想在真机上跑,需要下载一些厂商闭源的驱动文件,这样后续编译的代码才可以跑到真机上,此处对应的 官方文档 https://source.android.google.cn/setup/build/downloading#obtaining-proprietary-binaries

上面下载代码的时候,我们提到了两种方式,直接下载和下载特定 Tag,不同的下载方式对应的驱动也不一样

2.1 直接下载方式所对应的驱动

直接下载的代码使用的是 master 分支,驱动程序需要在这里下载 https://developers.google.cn/android/blobs-preview

以我的 pixel 3 XL 为例,我需要下载的驱动是

点击 Link 下载两个文件,然后进行解压到代码根目录,然后执行 sh 脚本释放驱动到合适的位置,二进制文件及其对应的 makefile 将会安装在源代码树的 vendor/ 层次结构中

2.2 下载特定 Tag 的代码所对应的驱动

如果下载的时候加了 -b ,那么就需要查看对应的 tag 所对应的驱动,地址如下:https://developers.google.cn/android/drivers

以我的 pixel 3 XL 为例,下载的 TAG 为 android-12.0.0_r3 (repo init -u git://mirrors.ustc.edu.cn/aosp/platform/manifest -b android-12.0.0_r3)

那么我们需要找到下面的部分,这里的 SP1A.210812.016.A1 跟上面 4.2 节是对应的,即 Tag android-12.0.0_r3 对应的 Build ID 是 SP1A.210812.016.A1。大家可以根据自己下载的 TAG 找到对应的 Build ID,然后根据 Build ID 寻找对应的驱动即可 https://developers.google.cn/android/drivers

跟 4.2 节下载的 Tag 是对应的:

2.3 驱动提取

下载的内容解压后,是两个 sh 文件,以我的 Pixel 3 XL 为例,在代码根目录执行,使用 D 来向下翻页,直到最后手动输入 I ACCEPT

1
2
# 解压缩 extract-google_devices-crosshatch.sh
./extract-google_devices-crosshatch.sh

1
2
# 解压缩  ./extract-qcom-crosshatch.sh
./extract-qcom-crosshatch.sh

3. 代码编译

代码和驱动都下载好之后,就可以开始代码的编译工作了,由于新版本不再支持 Mac 编译,所以建议大家还是使用 Linux 来进行编译,推荐使用 Ubuntu

不再支持Mac编译

3.1 设置编译环境

参考:https://source.android.google.cn/setup/build/initializing

Ubuntu 18.04 以上直接运行:

1
sudo apt-get install git-core gnupg flex bison build-essential zip curl zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 libncurses5 lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z1-dev libgl1-mesa-dev libxml2-utils xsltproc unzip fontconfig

3.2 设置代码编译环境

每次关闭 Shell 之后都需要重新执行下面这个脚本,相当于配置了一下编译环境

1
source build/envsetup.sh

或者

1
. build/envsetup.sh

3.3 选择编译目标

1
lunch

运行 lunch 之后,会有一堆设备出来让你选择,还是以我的 Pixel 3 XL 为例,其代号是 ,在这里可以查看所有机型对应的代号:https://source.android.google.cn/setup/build/running#selecting-device-build
Pixel 3 XL 对应的代号是:crosshatch

所以我选择编译的是 aosp_crosshatch-userdebug ,这里可以输入编号也可以直接输入 aosp_crosshatch-userdebug

lunch 选项

然后脚本会进行一系列的配置,输出下面的内容

3.4 全部编译

使用 m 构建所有内容。m 可以使用 -jN 参数处理并行任务。如果您没有提供 -j 参数,构建系统会自动选择您认为最适合您系统的并行任务计数。

1
m

如上所述,您可以通过在 m 命令行中列出相应名称来构建特定模块,而不是构建完整的设备映像。此外,m 还针对各种特殊目的提供了一些伪目标。以下是一些示例:

  1. droid - m droid 是正常 build。此目标在此处,因为默认目标需要名称。
  2. all - m all 会构建 m droid 构建的所有内容,加上不包含 droid 标记的所有内容。构建服务器会运行此命令,以确保包含在树中且包含 Android.mk 文件的所有元素都会构建。
  3. m - 从树的顶部运行构建系统。这很有用,因为您可以在子目录中运行 make。如果您设置了 TOP 环境变量,它便会使用此变量。如果您未设置此变量,它便会从当前目录中查找相应的树,以尝试找到树的顶层。您可以通过运行不包含参数的 m 来构建整个源代码树,也可以通过指定相应名称来构建特定目标。
  4. mma - 构建当前目录中的所有模块及其依赖项。
  5. mmma - 构建提供的目录中的所有模块及其依赖项。
  6. croot - cd 到树顶部。
  7. clean - m clean 会删除此配置的所有输出和中间文件。此内容与 rm -rf out/ 相同。

运行 m help 即可查看 m 提供的其他命令

输入 m 之后开始第一次全部编译,漫长的等待,编译时间取决于你的电脑配置…主要是 cpu 和内存,建议内存 32G 走起,cpu 也别太烂

编译成功之后,会有下面的输出

4. 刷机

自己编译的 UserDebug 固件用来 Debug 是非常方便的,不管是用来 Debug Framework 还是 App

编译好之后下面开始刷机,以我的测试机器 Pixel 3 XL 为例,依次执行下面的命令

1
2
3
4
5
6
7
adb reboot fastboot

# 等待手机进入 fastboot 界面之后
fastboot flashall -w

# 刷机完成之后,执行 fastboot reboot 长期系统即可
fastboot reboot

刷机截图如下
刷机

之后手机会自动重启,然后进入主界面,至此,我们的代码下载-编译-刷机的这部分就结束了

自己编译的 AOSP 的 Launcher 比较丑,因为没有 Google 闭源的那些套件的加持,看上去还是很简陋的,自带的 App 非常少,而且基本上没怎么维护,给到手机厂商的就是这么一个东西

还是官方的 Pixel 带的 Launcher 好看(Google 开发和维护)

如果在刷机的过程中遇到问题,可刷官方的刷机包拯救 :https://developers.google.cn/android/images

5. End

本文主要是讲如何下载、编译、刷机,后续的代码导入、修改和编译模块、代码 Debug 等,会另起一篇文章来介绍

关于我 && 博客

  1. 关于我 , 非常希望和大家一起交流 , 共同进步 .
  2. 博客内容导航
  3. 优秀博客文章记录 - Android 性能优化必知必会

一个人可以走的更快 , 一群人可以走的更远
微信扫一扫

Android Systrace 响应速度实战 3 :响应速度延伸知识

在讨论 Android 性能问题的时候,卡顿、响应速度、ANR 这三个性能相关的知识点通常会放到一起来讲,因为引起卡顿、响应慢、ANR 的原因类似,只不过根据重要程度,被人为分成了卡顿、响应慢、ANR 三种,所以我们可以定义广义上的卡顿,包含了卡顿、响应慢和 ANR 三种,所以如果用户反馈说手机卡顿或者 App 卡顿,大部分情况下都是广义上的卡顿,需要搞清楚,到底出现了哪一种问题

如果是动画播放卡顿、列表滑动卡顿这种,我们一般定义为 狭义的卡顿,对应的英文描述我觉得应该是 Jank;如果是应用启动慢、亮灭屏慢、场景切换慢,我们一般定义为 响应慢,对应的英文描述我觉得应该是 Slow ;如果是发生了 ANR,那就是 应用无响应问题 。三种情况所对应的分析方法和解决方法不太一样,所以需要分开来讲

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

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

Systrace (Perfetto) 工具的基本使用如果还不是很熟悉,那么需要优先去补一下 Systrace 基础知识系列,本文假设你已经熟悉 Systrace(Perfetto)的使用了

Systrace 系列文章如下

  1. Systrace 简介
  2. Systrace 基础知识 - Systrace 预备知识
  3. Systrace 基础知识 - Why 60 fps ?
  4. Systrace 基础知识 - SystemServer 解读
  5. Systrace 基础知识 - SurfaceFlinger 解读
  6. Systrace 基础知识 - Input 解读
  7. Systrace 基础知识 - Vsync 解读
  8. Systrace 基础知识 - Vsync-App :基于 Choreographer 的渲染机制详解
  9. Systrace 基础知识 - MainThread 和 RenderThread 解读
  10. Systrace 基础知识 - Binder 和锁竞争解读
  11. Systrace 基础知识 - Triple Buffer 解读
  12. Systrace 基础知识 - CPU Info 解读
  13. Systrace 流畅性实战 1 :了解卡顿原理
  14. Systrace 流畅性实战 2 :案例分析: MIUI 桌面滑动卡顿分析
  15. Systrace 流畅性实战 3 :卡顿分析过程中的一些疑问
  16. Systrace 响应速度实战 1 :了解响应速度原理
  17. Systrace 响应速度实战 2 :响应速度实战分析-以启动速度为例
  18. Systrace 响应速度实战 3 :响应速度延伸知识
  19. Systrace 线程 CPU 运行状态分析技巧 - Runnable 篇
  20. Systrace 线程 CPU 运行状态分析技巧 - Running 篇
  21. Systrace 线程 CPU 运行状态分析技巧 - Sleep 和 Uninterruptible Sleep 篇

1. Systrace 中进程三种状态解读

Systrace 中,进程的任务最常见的有三种状态:Sleep、Running、Runnable。在优化的过程中,这几个状态也需要我们关注。进程任务状态在最上面,以颜色来做区分:

  1. 绿色:Running
  2. 蓝色:Runnable
  3. 白色:Sleep

1.1 如何分析 Sleep 状态的 Task

一般白色的 Sleep 有两种,即应用主动 Sleep 和被动 Sleep

  1. nativePoll 这种,一般属于主动 Sleep,因为没有消息处理了,所以进入 Sleep 状态等待 Message,这种一般是正常的,我们不需要去关注。比如两帧之间的那段,就是主动 sleep 的
  2. 被动 Sleep 一般是由用户主动调用 sleep,或者用 Binder 与其他进程进行通信,这个是我们最常见的,也是分析性能问题的时候经常会遇到的,需要重点关注

如下图,这种在启动过程中,有较长时间的 sleep 情况,一般下面就可以看到是否在进行 Binder 通信,如果在启动过程中有频繁的 Binder 通信,那么应用等待的时间就会变长,导致响应时间变慢

QBslSMaNhoheCWfY

这种一般可以点击这个 Task 最下面的 binder transaction 来查看 Binder 调用信息,比如

FqqYKpVnNGUuivrq

有时候没有 Binder 信息,是被其他的等待的线程唤醒,那么可以查看唤醒信息,也可以找到应用是在等待什么

zPFoHiQJvTWMmUuF

放大上图中我们点击的 Runnable 的地方

YJH0UWMlVDuJjSro

1.2 如何分析 Running 状态的 Task

Running 状态的任务就是目前在 CPU 某一个核心上运行的任务,如果某一段任务是 Running 状态,且耗时变长,那么需要分析:

  1. 是否应用的本身逻辑耗时,比如新增了某些代码逻辑
  2. 是否跑在了对应的核心上

NDvF1X4GFiUpC6vN

K49yBsgPUrHkYyw6

在某些 Android 机器上,大家一般会对 App 的主线程和渲染线程进行调度方面的优化:一般前台应用的 UI Thread 和 RenderThread 都是跑在大核上的

1.3 如何分析 Runnable 状态的 Task

一个 Task 要从 Sleep 状态转到 Running 状态,必须先变成 Runnable 状态,其状态转换图如下

3gilFNQA8lh1A7l0

在 Systrace 上的表现如下

GR7crsOwDOy4X8qL

正常情况下,应用进入 Runnable 状态之后,会马上被调度器调度,进入 Running 状态,开始干活;但是在系统繁忙的时候,应用就会有大量的时间在 Runnable 状态,因为 cpu 已经跑满,各种任务都需要排队等待调度

如果应用启动的时候出现大量的 Runnable 任务,那么需要查看系统的状态

2. TraceView 工具在响应速度方面的使用

TraceView 指的是我们在 AS Profiler 里面抓取 CPU 信息的时候出现的那个,大家看下面的截图就知道了

image-20211028011509615

2.1 如何抓取应用启动时候的 TraceView

使用下面的命令可以抓取应用的冷启动,这些命令也可以分开执行,需要把里面的包名和 Activity 名切换成自己应用的包名

1
adb shell am start -n com.aboback.wanandroidjetpack/.splash.SplashActivity --start-profiler /data/local/tmp/traceview.trace --sampling 1 && sleep 10 && adb shell am profile stop com.aboback.wanandroidjetpack && adb pull /data/local/tmp/traceview.trace .

或者分开执行上面的命令

1
2
3
4
5
6
7
8
9
10
// 1. 冷启动 App,sampleing = 1 意思是 1ms 采样一次
adb shell am start -n com.aboback.wanandroidjetpack/.splash.SplashActivity --start-profiler /data/local/tmp/traceview.trace --sampling 1

// 2. 等待应用完全启动之后,结束 profile
adb shell am profile stop com.aboback.wanandroidjetpack

// 3. 将 Trace 文件从手机里面 pull 出来
adb pull /data/local/tmp/traceview.trace .

// 4. 使用 Android Studio 打开 traceview.trace 文件

2.2 TraceView 工具怎么看

抓出来的 TraceView 可以直接在 Android Studio 中打开

其中图里面用绿色标记的函数,就是应用自己的函数,黄色标注的是系统的函数

Application.onCreate

vRpdMHl8CTzCGcxS

Activity.onCreate

Jl9s7vZbMQTTrWIT

doFrame

X4f8vX27JS5x4TyF

WebView 初始化

jxmFl0K9M8cpNCWy

2.3 TraceView 工具的弊端

由于采样比较细,所以会性能损耗比较大,所以抓出来的 TraceView,其中每个方法的执行时间是不准的,所以不可用作为真实的时间参考,但是可以用来定位具体的函数调用栈。

需要跟 Systrace 来进行互补

3. SimplePerf 工具在启动速度分析的使用

使用 SimplePerf 工具也可以抓取启动时候的堆栈信息,既包括 Java 也包括 Native

比如我们要抓取 com.aboback.wanandroidjetpack 这个应用的冷启动,可以执行下面的命令(SimplePerf 的环境初始化参考 https://android.googlesource.com/platform/system/extras/+/master/simpleperf/doc/android_application_profiling.md 这篇文章 ,其中 app_profiler.py 就是 SimplePerf 的工具)

1
python app_profiler.py -p com.aboback.wanandroidjetpack

执行上面的命令之后,需要手动在手机上启动 App,然后主动结束

1
2
3
4
5
$ python app_profiler.py -p com.aboback.wanandroidjetpack  
INFO:root:prepare profiling
INFO:root:start profiling1
INFO:root:run adb cmd: ['adb', 'shell', '/data/local/tmp/simpleperf', 'record', '-o', '/data/local/tmp/perf.data', '-e task-clock:u -f 1000 -g --duration 10', '--log', 'info', '--app', 'com.aboback.wanandroidjetpack'] simpleperf I environment.cpp:601] Waiting for process of app com.aboback.wanandroidjetpack
simpleperf I environment.cpp:593] Got process 32112 for package com.aboback.wanandroidjetpack

抓取结束之后,调用解析脚本来生成 html 报告

1
python report_html.py

就会得到下面这个

itcLtktb5xxv5gp0

不仅可以看到 Java 层的堆栈,也可以看到 Native 的堆栈,这里只是简单的使用,更详细的方法可以参考下面几个文档

SimplePerf 初步试探 https://android.googlesource.com/platform/system/extras/+/master/simpleperf/doc/README.md

  1. Android application profiling https://android.googlesource.com/platform/system/extras/+/master/simpleperf/doc/android_application_profiling.md
  2. Android platform profiling https://android.googlesource.com/platform/system/extras/+/master/simpleperf/doc/android_platform_profiling.md
  3. Executable commands reference https://android.googlesource.com/platform/system/extras/+/master/simpleperf/doc/executable_commands_reference.md
  4. Scripts reference https://android.googlesource.com/platform/system/extras/+/master/simpleperf/doc/scripts_reference.md

4. 其他组件启动时在 Systrace 中的位置

4.1 Service 的启动

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
public final void scheduleCreateService(IBinder token,
ServiceInfo info, CompatibilityInfo compatInfo, int processState) {
updateProcessState(processState, false);
CreateServiceData s = new CreateServiceData();
s.token = token;
s.info = info;
s.compatInfo = compatInfo;
sendMessage(H.CREATE_SERVICE, s);
}

public final void scheduleBindService(IBinder token, Intent intent,
boolean rebind, int processState) {
updateProcessState(processState, false);
BindServiceData s = new BindServiceData();
s.token = token;
s.intent = intent;
s.rebind = rebind;
sendMessage(H.BIND_SERVICE, s);
}

可以看到,代码执行都是往 H 这个 Handler 中发送 Message,所以如果我们在代码里面启动 Service,并不是马上就执行的,而是由 MessageQueue 里面的 Message 顺序决定的

NRY3YuU1Bsgk6wvv

放大真正执行的部分可以看到,其执行的时机是在 MessageQueue 按照 Message 的顺序执行(这里是在应用第一帧执行结束后),后面的 Message 就是应用自己的 Message、启动 Service、执行广播接收器

r463HjnnO0KgdOFl

4.2 执行自己的 Message

执行自定义的 Message 在 Systrace 中的显示

iUZhyqUStVIyZHtf

4.3 启动 Service

Service 启动在 Systrace 中的显示

8RzVxF9ai3r420W0

4.4 启动 BroadcastReceiver

执行 Receiver 在 Systrace 中的显示

kY3rkAhlqk7klnOL

Broadcast 的注册:一般是在 Activity 生命周期函数中注册,在哪里注册就在哪里执行

UR245WLGUvPEcvTz

4.5 ContentProvider 的启动时机

6PdzLLkZ7hdA61Tk

019y0cn5kNNGFVnm

5. AppStartup 是否能优化启动速度?

三方库的初始化

很多三方库都需要在 Application 中进行初始化,并顺便获取到 Application 的上下文

但是也有的库不需要我们自己去初始化,它偷偷摸摸就给初始化了,用到的方法就是使用 ContentProvider 进行初始化,定义一个 ContentProvider,然后在 onCreate 拿到上下文,就可以进行三方库自己的初始化工作了。而在 APP 的启动流程中,有一步就是要执行到程序中所有注册过的 ContentProvider 的 onCreate 方法,所以这个库的初始化就默默完成了。

这种做法确实给集成库的开发者们带来了很大的便利,现在很多库都用到了这种方法,比如 Facebook,Firebase,WorkManager

ContentProvider 的初始化时机如下:

VhpUlBTz1UNteVQz

但是当大部分三方库使用这种方法初始化的时候,就会有下面几个问题

  1. 启动过程中的 ContentProvider 过多
  2. 应用开发者无法控制使用这种方式初始化的库的初始化时机
  3. 无法处理这些三方库的依赖

AppStartup 库

针对上面的情况,Google 推出了 AppStartup 库,AppStartup 库的优点

  • 可以共享单个 Contentprovider
  • 可以明确地设置初始化顺序
  • 通过这个库可以移除三方库的 ContentProvider 启动时候自动初始化的步骤,手动通过 LazyLoad 的方式启动,这样可以起到优化启动速度的作用

根据测算结果来看,使用 AppStartup 库并不能显著加快应用启动速度,除非你有非常多 (50+)的 ContentProvider 在应用启动的时候初始,那么 AppStartup 才会有比较明显的效果

如果三方的 SDK 使用 ContentProvider 初始化耗时,那么可以考虑针对这个 ContentProvider 进行延迟初始化,比如

1
2
3
4
5
6
7
8
<provider
android:name="androidx.startup.InitializationProvider"
android:authorities="${applicationId}.androidx-startup"
android:exported="false"
tools:node="merge">
<meta-data android:name="com.example.ExampleLoggerInitializer"
tools:node="remove" />
</provider>

ExampleLoggerInitializer 的 meta-data 当中加入了一个 tools:node=”remove”的标记

总结

  1. App Startup 的设计是为了解决一个问题:即不同的库使用不同的 ContentProvider 进行初始化,导致 ContentProvider 太多,管理杂乱,影响耗时的问题
  2. App Startup 具体能减少多少耗时时间:根据测试,如果二三十个三方库都集成了 App Startup,减少的耗时大概在 20ms 以内
  3. App Startup 的使用场景应该
    1. APK 有很多的 ContentProvider 在启动时候初始化
    2. APK 中有的三方库 ContentProvider 初始化很耗时,但是又不是必须要在启动的时候初始,可以按需初始化
    3. 应用开发者想自己控制各个库的初始化时机或者初始化顺序

需要 App 开发同学验证

  1. 检查打包出来的 apk 的配置文件里面看一下,有多少个三方库是利用 ContentProvider 初始化的(或者在 AS 的 src\main\AndroidManifest.xml 文件最下面打开 Merged Manifest 标签查看)
  2. 确认这些 ContentProvider 在启动时候的耗时
  3. 确认哪些 ContentProvider 可以延迟加载或者用时加载
  4. 如果需要的话,接入 AppStartup 库

6. IdleHandler 在 App 启动场景下的使用

在启动优化的过程中,idleHandler 可以在 MessageQueue 空闲的时候执行任务,如下图,可以很清晰地查看 idleHandler 的执行时机

XaSQsq3pfgDgCNVe

其使用场景如下:

  1. 在启动的过程中,可以借助 idleHandler 来做一些延迟加载的事情。比如在启动过程中 Activity 的 onCreate 里面 addIdleHandler,这样在 Message 空闲的时候,可以执行这个任务

    7fLroBfAyXPaUu8W

  2. 进行启动时间统计:比如在页面完全加载之后,调用 activity.reportFullyDrawn 来告知系统这个 Activity 已经完全加载,用户可以使用了,比如下面的例子,在主页的 List 加载完成后,调用 activity.reportFullyDrawn

    BN97DrcXfHiqA5DY

    其对应的 Systrace 如下

    1xrN3YMzAY71ZAWi

    这时候得到的应用的冷启动时间才是正常的

    A5mH2AW4U06l43jk

另外系统有些功能,也会依赖于 FullyDrawn,所以建议主动上报(即主动在 App 完全启动后调用 activity.reportFullyDrawn)

系列文章

  1. Systrace 响应速度实战 1 :了解响应速度原理
  2. Systrace 响应速度实战 2 :响应速度实战分析-以启动速度为例
  3. Systrace 响应速度实战 3 :响应速度延伸知识
  4. Systrace 基础知识系列-放个链接在这里方便大家直接点过去

参考文章

  1. Android 应用启动全流程分析
  2. 探究 | App Startup 真的能减少启动耗时吗
  3. Jetpack 新成员,App Startup 一篇就懂
  4. App Startup
  5. Android App 启动优化全记录
  6. Android application profiling

关于我 && 博客

  1. 关于我 , 非常希望和大家一起交流 , 共同进步 .
  2. 博客内容导航
  3. 优秀博客文章记录 - Android 性能优化必知必会

一个人可以走的更快 , 一群人可以走的更远

微信扫一扫

❌