Android Systrace 响应速度实战 2 ：响应速度实战分析-以启动速度为例

在讨论 Android 性能问题的时候，卡顿、响应速度、ANR 这三个性能相关的知识点通常会放到一起来讲，因为引起卡顿、响应慢、ANR 的原因类似，只不过根据重要程度，被人为分成了卡顿、响应慢、ANR 三种，所以我们可以定义广义上的卡顿，包含了卡顿、响应慢和 ANR 三种，所以如果用户反馈说手机卡顿或者 App 卡顿，大部分情况下都是广义上的卡顿，需要搞清楚，到底出现了哪一种问题

如果是动画播放卡顿、列表滑动卡顿这种，我们一般定义为 狭义的卡顿，对应的英文描述我觉得应该是 Jank；如果是应用启动慢、亮灭屏慢、场景切换慢，我们一般定义为 响应慢 ，对应的英文描述我觉得应该是 Slow ；如果是发生了 ANR，那就是 应用无响应问题 。三种情况所对应的分析方法和解决方法不太一样，所以需要分开来讲

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

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

Systrace (Perfetto) 工具的基本使用如果还不是很熟悉，那么需要优先去补一下 Systrace 基础知识系列，本文假设你已经熟悉 Systrace(Perfetto)的使用了

Systrace 系列文章如下

这个案例和对应的 Systrace 偏工程化一些，省略了很多细节，因为应用的启动流程涉及的知识非常广，如果每个都细化的话，会有很大的篇幅。推荐大家看这篇文章，非常详细：Android 应用启动全流程分析

所以这里以 Systrace 为主线，讲解应用启动的时候各个关键模块的大概工作流程。了解大概流程之后，就可以分段去深入自己感兴趣或者自己负责的部分，这里首先放一张 Systrace 和手机截图所对应的图，大家可以先看看这个图，然后再往下看（博客里面 Perfetto 和 Systrace 混合使用）

为了更方便分析应用冷启动，我们需要做下面的准备工作

本文以 在桌面上冷启动一个 Android App 为例，应用冷启动的整个流程包含了从用户触摸屏幕到应用完全显示的整个流程，其中涉及到

上一篇文章有讲到响应速度问题，需要搞清楚 起点 和 终点，对于应用冷启动来说，起点就是 input 事件，终点就是应用完全展示给用户（用户可操作）

下面将从上面几个关键流程，通过 Systrace 的来介绍整个流程

由于我们的案例是在桌面冷启动一个 App，那么在手指触摸手机屏幕的时候，触摸屏会触发中断，这个中断我们最早能在 Systrace 中看到的地方如下：

对应的 cpu ss 区域和 中断区域（加了 irq 的 tag 才可以看到）

一般来说，点击屏幕会触发若干个中断，这些信号经过处理之后，触摸屏驱动会把这些点更新到 EventHub 中，让 InputReader 和 InputDIspatcher 进行进一步的处理。这一步一般不会出现什么问题，厂商这边对触摸屏的调教可能会关注这里

InputReader 和 InputDispatcher 这两个线程跑在 SystemServer 里面，专门负责处理 Input 事件，具体的流程可以参考Android Systrace 基础知识 - Input 解读 这篇文章

这里由于我们是点击桌面上的一个 App 的图标，可以看到底层上报上来的事件包括一个 Input_Down 事件 + 若干个 Input Move 事件 + 一个 Input Up 事件，组成了一个完整的点击事件

由于 Launcher 在进程创建的时候就注册了 Input 监听，且此时 Launcher 在前台且可见，所以 Launcher 进程可以收到这些 Input 事件，并根据 Input 事件的类型进行处理，input 事件在 SystemServer 和 App 的流转在 Systrace 中的具体表现可以参考 Android Systrace 基础知识 - Input 解读 ，这里把核心的两张图放上来

看下图即可，如果要看更详细的，可以查看 Android Systrace 基础知识 - Input 解读

看下图即可，如果要看更详细的，可以查看 Android Systrace 基础知识 - Input 解读

Launcher 处理 Input 事件也是响应时间的一个重要阶段，主要包括两个响应速度指标

另外提一下，滑动桌面到桌面第一帧响应时间（这个指的是滑动桌面的场景，左右滑动桌面的时候，用高速相机拍摄，从手指动开始，到桌面动的第一帧的时间）也是一个很重要的响应速度指标，部分厂商也会在这方面做优化，感兴趣的可以自己试试主流厂商的桌面滑动场景（跟原生的机器对比 Systrace 即可）

在冷启动的场景里面，Launcher 在收到 up 事件后，会进行逻辑判断，然后启动对应的 App（这里主要是交给 AMS 来处理，又回到了 SystemServer 进程）

这个阶段通常也是做系统优化的会比较关注，做 App 的同学还不需要关注到这里（Launcher App 的除外）；另外在最新的版本，应用启动的动画是由 Launcher 和 SystemServer 共同完成的，目的就是可以做一些复杂的动画而没有割裂感，大家可以用慢镜头拍一下启动时候和退出应用的动画，可以看到有的应用图标是分层的，甚至会动，这是之前纯粹由 SystemServer 这边来做动画所办不到的

SystemServer 处理主要是有2部分

这个 SystemServer 进程中的 Binder 调用就是 Launcher 通过 ActivityTaskManager.getService().startActivity 调用过来的

fork 新的进程，则是在判断启动的 Activity 的 App 进程没有启动后，需要首先启动进程，然后再启动 Activity，这里是冷启动和其他启动不一样的地方。fork 主要是 fork Zygote64 这个进程（部分 App 是 fork 的 Zygote32 ）

对应的代码如下，这里就正式进入了 App 自己的进程逻辑了

应用启动后，SystemServer 会记录从 startActivity 被调用到应用第一帧显示的时长，在 Systrace 中的显示如下（注意结尾是应用第一帧，如果应用启动的时候是 SplashActivity -> MainActivity，那么这里的结尾只是 SplashActivity，MainActivity 的完全启动需要自己查看）

通常的大型应用，App 冷启动通常包括下面三个部分，每一个部分耗时都会导致应用的整体启动速度变慢，所以在优化启动速度的时候，需要明确知道应用启动结束的点（需要跟测试沟通清楚，一般是界面保持稳定的那个点）

下面针对这三个阶段来具体分析（当然你的 App 如果简单的话，可能没有 SplashActivity ，直接进的就是主 Activity，那么忽略第二步就可以了）

由于是冷启动，所以 App 进程在 Fork 之后，需要首先执行 bindApplication ，这个也是区分冷热启动的一个重要的点。Application 的环境创建好之后，就开始组件的启动（这里是 Activity 组件，通过 Service、Broadcast、ContentProvider 组件启动的进程则会在 bindApplication 之后先启动这些组件）

Activity 的生命周期函数会在 Activity 组件创建的时候执行，包括 onStart、onCreate、onResume 等，然后还要经过一次 Choreographer#doFrame 的执行（包括 measure、layout、draw）以及 RenderThread 的初始化和第一帧任务的绘制，再加上 SurfaceFlinger 一个 Vsync 周期的合成，应用第一帧才会真正显示（也就是下图中 finishDrawing 的位置），这部分详细的流程可以查看 Android Systrace 基础知识 - MainThread 和 RenderThread 解读

大部分的 App 都有 SplashActivity 来播放广告，播放完成之后才是真正的主 Activity 的启动，同样包括 Activity 组件的创建，包括 onStart、onCreate、onResume 、自有启动逻辑的执行、WebView 的初始化等等等等，直到主 Activity 的第一帧显示

一般来说，主 Activity 需要多帧才能显示完全，因为有很多资源（最常见的是图片）是异步加载的，第一帧可能只加载了一个显示框架、而其中的内容在准备好之后才会显示出来。这里也可以看到，通过 Systrace 不是很方便来判断应用冷启动的终点（除非你跟测试约定好，在某个 View 显示之后就算启动完成，然后你在这个 View 里面打个 Systrace 的 Tag，通过跟踪这个 Tag 就可以粗略判断具体 Systrace 里面哪一帧是启动完成的点）

我制作了一个 Systrace + 截图的方式，来进行演示，方便你了解 App 启动各个阶段都对应在 Systrace 的哪里（使用的是一个开源的 WanAndroid 客户端）

本文重点放在了如何在 Systrace 中展示 App 的完整冷启动流程，方便大家在做 App 的启动优化的时候，可以通过 Systrace 来快速定位到启动瓶颈，也方便进行竞品的对比和分析，

下面是个人的介绍和相关的链接，期望与同行的各位多多交流，三人行，则必有我师!