区块链技术博客
www.b2bchain.cn

Systrace 响应速度实战 2 :响应速度实战分析 – 以启动速度为例求职学习资料

本文介绍了Systrace 响应速度实战 2 :响应速度实战分析 – 以启动速度为例求职学习资料,有助于帮助完成毕业设计以及求职,是一篇很好的资料。

对技术面试,学习经验等有一些体会,在此分享。

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

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

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

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

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

1. 准备工作

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

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

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

  1. 打开 Binder 调试,方便在 Trace 中显示 Binder 信息(即可以在 Systrace 中看到 Binder 调用的函数)- 需要 Root
    1. 开启 ipc debug: adb shell am trace-ipc start
    2. 抓取结束后,可以执行下面的命令关闭adb shell am trace-ipc stop --dump-file /data/local/tmp/ipc-trace.txt
  2. Trace 命令加入 irq tag,默认的命令不包含 irq,需要自己加 irq 的 TAG,这样打开 Trace 之后,就可以看到 irq 相关的内容,最后的抓 trace 命令如下:
     python /mnt/d/Android/platform-tools/systrace/systrace.py gfx input view webview wm am sm rs bionic power pm ss database network adb idle pdx sched irq freq idle disk workq binder_driver binder_lock -a com.xxx.xxx ,注意这里的 com.xxx.xxx 换成自己的包名,如果不是调试特定的包名,可以去掉 -a com.xxx.xxx
  3. 推荐 :如果要 Debug 的 App 可以进行编译(即可以使用 Gradle 编译,一般自己开发的项目都可以),可以在分析响应速度问题的时候,引入 TraceFix 库(接入方法参考 https://github.com/Gracker/TraceFix)。接入之后,编译的时候就会进行代码插桩,在 App 代码的每一个函数中都插入 Trace 点,这样在分析的时候可以看到更详细的 App 的信息
    1. 使用插件前,只能看到 Framework 里面的 Trace 点
      Systrace 响应速度实战 2 :响应速度实战分析 - 以启动速度为例
    2. 使用插件后,可以看到 Trace 中显示的信息多了很多(App 自身的代码逻辑,Framework 的代码没法插桩)
      Systrace 响应速度实战 2 :响应速度实战分析 - 以启动速度为例

2. Android App 冷启动流程分析

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

  1. 触摸屏中断处理阶段
  2. InputReader 和 InputDispatcher 处理 input 事件阶段
  3. Launcher 处理 input 事件阶段
  4. SystemServer 处理启动事件
  5. 启动动画
  6. 应用启动和自身逻辑阶段

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

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

2.1 触摸屏中断处理阶段

由于我们的案例是在桌面冷启动一个 App,那么在手指触摸手机屏幕的时候,触摸屏会触发中断,这个中断我们最早能在 Systrace 中看到的地方如下:
Systrace 响应速度实战 2 :响应速度实战分析 - 以启动速度为例

对应的 cpu ss 区域和 中断区域(加了 irq 的 tag 才可以看到)
Systrace 响应速度实战 2 :响应速度实战分析 - 以启动速度为例

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

2.2 InputReader 和 InputDispatcher 处理 Input 事件阶段

InputReader 和 InputDispatcher 这两个线程跑在 SystemServer 里面,专门负责处理 Input 事件,具体的流程可以参考Android Systrace 基础知识 – Input 解读 这篇文章
Systrace 响应速度实战 2 :响应速度实战分析 - 以启动速度为例

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

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

2.2.1 Input 事件在 SystemServer 中流转

看下图即可,如果要看更详细的,可以查看 Android Systrace 基础知识 – Input 解读
Systrace 响应速度实战 2 :响应速度实战分析 - 以启动速度为例

2.2.2 Input 事件在 Launcher 进程流转

看下图即可,如果要看更详细的,可以查看 Android Systrace 基础知识 – Input 解读
Systrace 响应速度实战 2 :响应速度实战分析 - 以启动速度为例

2.3 Launcher 进程处理 Input 事件阶段

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

  1. 点击桌面到桌面第一帧响应(一般 Launcher 会在接收到 Down 事件的时候,将 App 图标置灰,以表示接收到了事件;有的定制桌面 App 图标会有一个缩小的动画,表示被按压)
  2. 桌面第一帧响应到启动 App(这段时间指的是桌面在收到 Down 对 App 图标做处理后,到收到 Up 事件判断需要启动 App 的时间)

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

在冷启动的场景里面,Launcher 在收到 up 事件后,会进行逻辑判断,然后启动对应的 App(这里主要是交给 AMS 来处理,又回到了 SystemServer 进程)
Systrace 响应速度实战 2 :响应速度实战分析 - 以启动速度为例

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

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

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

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

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

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

1. 准备工作

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

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

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

  1. 打开 Binder 调试,方便在 Trace 中显示 Binder 信息(即可以在 Systrace 中看到 Binder 调用的函数)- 需要 Root
    1. 开启 ipc debug: adb shell am trace-ipc start
    2. 抓取结束后,可以执行下面的命令关闭adb shell am trace-ipc stop --dump-file /data/local/tmp/ipc-trace.txt
  2. Trace 命令加入 irq tag,默认的命令不包含 irq,需要自己加 irq 的 TAG,这样打开 Trace 之后,就可以看到 irq 相关的内容,最后的抓 trace 命令如下:
     python /mnt/d/Android/platform-tools/systrace/systrace.py gfx input view webview wm am sm rs bionic power pm ss database network adb idle pdx sched irq freq idle disk workq binder_driver binder_lock -a com.xxx.xxx ,注意这里的 com.xxx.xxx 换成自己的包名,如果不是调试特定的包名,可以去掉 -a com.xxx.xxx
  3. 推荐 :如果要 Debug 的 App 可以进行编译(即可以使用 Gradle 编译,一般自己开发的项目都可以),可以在分析响应速度问题的时候,引入 TraceFix 库(接入方法参考 https://github.com/Gracker/TraceFix)。接入之后,编译的时候就会进行代码插桩,在 App 代码的每一个函数中都插入 Trace 点,这样在分析的时候可以看到更详细的 App 的信息
    1. 使用插件前,只能看到 Framework 里面的 Trace 点
      Systrace 响应速度实战 2 :响应速度实战分析 - 以启动速度为例
    2. 使用插件后,可以看到 Trace 中显示的信息多了很多(App 自身的代码逻辑,Framework 的代码没法插桩)
      Systrace 响应速度实战 2 :响应速度实战分析 - 以启动速度为例

2. Android App 冷启动流程分析

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

  1. 触摸屏中断处理阶段
  2. InputReader 和 InputDispatcher 处理 input 事件阶段
  3. Launcher 处理 input 事件阶段
  4. SystemServer 处理启动事件
  5. 启动动画
  6. 应用启动和自身逻辑阶段

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

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

2.1 触摸屏中断处理阶段

由于我们的案例是在桌面冷启动一个 App,那么在手指触摸手机屏幕的时候,触摸屏会触发中断,这个中断我们最早能在 Systrace 中看到的地方如下:
Systrace 响应速度实战 2 :响应速度实战分析 - 以启动速度为例

对应的 cpu ss 区域和 中断区域(加了 irq 的 tag 才可以看到)
Systrace 响应速度实战 2 :响应速度实战分析 - 以启动速度为例

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

2.2 InputReader 和 InputDispatcher 处理 Input 事件阶段

InputReader 和 InputDispatcher 这两个线程跑在 SystemServer 里面,专门负责处理 Input 事件,具体的流程可以参考Android Systrace 基础知识 – Input 解读 这篇文章
Systrace 响应速度实战 2 :响应速度实战分析 - 以启动速度为例

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

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

2.2.1 Input 事件在 SystemServer 中流转

看下图即可,如果要看更详细的,可以查看 Android Systrace 基础知识 – Input 解读
Systrace 响应速度实战 2 :响应速度实战分析 - 以启动速度为例

2.2.2 Input 事件在 Launcher 进程流转

看下图即可,如果要看更详细的,可以查看 Android Systrace 基础知识 – Input 解读
Systrace 响应速度实战 2 :响应速度实战分析 - 以启动速度为例

2.3 Launcher 进程处理 Input 事件阶段

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

  1. 点击桌面到桌面第一帧响应(一般 Launcher 会在接收到 Down 事件的时候,将 App 图标置灰,以表示接收到了事件;有的定制桌面 App 图标会有一个缩小的动画,表示被按压)
  2. 桌面第一帧响应到启动 App(这段时间指的是桌面在收到 Down 对 App 图标做处理后,到收到 Up 事件判断需要启动 App 的时间)

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

在冷启动的场景里面,Launcher 在收到 up 事件后,会进行逻辑判断,然后启动对应的 App(这里主要是交给 AMS 来处理,又回到了 SystemServer 进程)
Systrace 响应速度实战 2 :响应速度实战分析 - 以启动速度为例

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

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

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

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

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

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

1. 准备工作

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

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

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

  1. 打开 Binder 调试,方便在 Trace 中显示 Binder 信息(即可以在 Systrace 中看到 Binder 调用的函数)- 需要 Root
    1. 开启 ipc debug: adb shell am trace-ipc start
    2. 抓取结束后,可以执行下面的命令关闭adb shell am trace-ipc stop --dump-file /data/local/tmp/ipc-trace.txt
  2. Trace 命令加入 irq tag,默认的命令不包含 irq,需要自己加 irq 的 TAG,这样打开 Trace 之后,就可以看到 irq 相关的内容,最后的抓 trace 命令如下:
     python /mnt/d/Android/platform-tools/systrace/systrace.py gfx input view webview wm am sm rs bionic power pm ss database network adb idle pdx sched irq freq idle disk workq binder_driver binder_lock -a com.xxx.xxx ,注意这里的 com.xxx.xxx 换成自己的包名,如果不是调试特定的包名,可以去掉 -a com.xxx.xxx
  3. 推荐 :如果要 Debug 的 App 可以进行编译(即可以使用 Gradle 编译,一般自己开发的项目都可以),可以在分析响应速度问题的时候,引入 TraceFix 库(接入方法参考 https://github.com/Gracker/TraceFix)。接入之后,编译的时候就会进行代码插桩,在 App 代码的每一个函数中都插入 Trace 点,这样在分析的时候可以看到更详细的 App 的信息
    1. 使用插件前,只能看到 Framework 里面的 Trace 点
      Systrace 响应速度实战 2 :响应速度实战分析 - 以启动速度为例
    2. 使用插件后,可以看到 Trace 中显示的信息多了很多(App 自身的代码逻辑,Framework 的代码没法插桩)
      Systrace 响应速度实战 2 :响应速度实战分析 - 以启动速度为例

2. Android App 冷启动流程分析

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

  1. 触摸屏中断处理阶段
  2. InputReader 和 InputDispatcher 处理 input 事件阶段
  3. Launcher 处理 input 事件阶段
  4. SystemServer 处理启动事件
  5. 启动动画
  6. 应用启动和自身逻辑阶段

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

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

2.1 触摸屏中断处理阶段

由于我们的案例是在桌面冷启动一个 App,那么在手指触摸手机屏幕的时候,触摸屏会触发中断,这个中断我们最早能在 Systrace 中看到的地方如下:
Systrace 响应速度实战 2 :响应速度实战分析 - 以启动速度为例

对应的 cpu ss 区域和 中断区域(加了 irq 的 tag 才可以看到)
Systrace 响应速度实战 2 :响应速度实战分析 - 以启动速度为例

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

2.2 InputReader 和 InputDispatcher 处理 Input 事件阶段

InputReader 和 InputDispatcher 这两个线程跑在 SystemServer 里面,专门负责处理 Input 事件,具体的流程可以参考Android Systrace 基础知识 – Input 解读 这篇文章
Systrace 响应速度实战 2 :响应速度实战分析 - 以启动速度为例

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

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

2.2.1 Input 事件在 SystemServer 中流转

看下图即可,如果要看更详细的,可以查看 Android Systrace 基础知识 – Input 解读
Systrace 响应速度实战 2 :响应速度实战分析 - 以启动速度为例

2.2.2 Input 事件在 Launcher 进程流转

看下图即可,如果要看更详细的,可以查看 Android Systrace 基础知识 – Input 解读
Systrace 响应速度实战 2 :响应速度实战分析 - 以启动速度为例

2.3 Launcher 进程处理 Input 事件阶段

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

  1. 点击桌面到桌面第一帧响应(一般 Launcher 会在接收到 Down 事件的时候,将 App 图标置灰,以表示接收到了事件;有的定制桌面 App 图标会有一个缩小的动画,表示被按压)
  2. 桌面第一帧响应到启动 App(这段时间指的是桌面在收到 Down 对 App 图标做处理后,到收到 Up 事件判断需要启动 App 的时间)

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

在冷启动的场景里面,Launcher 在收到 up 事件后,会进行逻辑判断,然后启动对应的 App(这里主要是交给 AMS 来处理,又回到了 SystemServer 进程)
Systrace 响应速度实战 2 :响应速度实战分析 - 以启动速度为例

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

部分转自互联网,侵权删除联系

赞(0) 打赏
部分文章转自网络,侵权联系删除b2bchain区块链学习技术社区 » Systrace 响应速度实战 2 :响应速度实战分析 – 以启动速度为例求职学习资料
分享到: 更多 (0)

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

b2b链

联系我们联系我们