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

Systrace 响应速度实战 3 :响应速度延伸知识求职学习资料

本文介绍了Systrace 响应速度实战 3 :响应速度延伸知识求职学习资料,有助于帮助完成毕业设计以及求职,是一篇很好的资料。

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

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

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

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

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

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

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 通信,那么应用等待的时间就会变长,导致响应时间变慢

Systrace 响应速度实战 3 :响应速度延伸知识

这种一般可以点击这个 Task 最下面的 binder transaction 来查看 Binder 调用信息,比如

Systrace 响应速度实战 3 :响应速度延伸知识

有时候没有 Binder 信息,是被其他的等待的线程唤醒,那么可以查看唤醒信息,也可以找到应用是在等待什么

Systrace 响应速度实战 3 :响应速度延伸知识

放大上图中我们点击的 Runnable 的地方

Systrace 响应速度实战 3 :响应速度延伸知识

1.2 如何分析 Running 状态的 Task

Running 状态的任务就是目前在 CPU 某一个核心上运行的任务,如果某一段任务是 Running 状态,且耗时边长,那么需要分析:

  1. 是否应用的本身逻辑耗时,比如新增了某些代码逻辑
  2. 是否跑在了对应的核心上

Systrace 响应速度实战 3 :响应速度延伸知识

Systrace 响应速度实战 3 :响应速度延伸知识

在某些 Android 机器上,大家一般会对 App 的主线程和渲染线程进行调度方面的优化:一般前台应用的 UI Thread 和 RenderThread 都是跑在大核上的

1.3 如何分析 Runnable 状态的 Task

一个 Task 要从 Sleep 状态转到 Running 状态,必须先变成 Runnable 状态,其状态转换图如下

Systrace 响应速度实战 3 :响应速度延伸知识

在 Systrace 上的表现如下

Systrace 响应速度实战 3 :响应速度延伸知识

正常情况下,应用进入 Runnable 状态之后,会马上被调度器调度,进入 Running 状态,开始干活;但是在系统繁忙的时候,应用就会有大量的时间在 Runnable 状态,因为 cpu 已经跑满,各种任务都需要排队等待调度

如果应用启动的时候出现大量的 Runnable 任务,那么需要查看系统的状态

2. TraceView 工具在响应速度方面的使用

TraceView 指的是我们在 AS Profiler 里面抓取 CPU 信息的时候出现的那个,大家看下面的截图就知道了

Systrace 响应速度实战 3 :响应速度延伸知识

2.1 如何抓取应用启动时候的 TraceView

使用下面的命令可以抓取应用的冷启动,这些命令也可以分开执行,需要把里面的包名和 Activity 名切换成自己应用的包名

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. 冷启动 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

Systrace 响应速度实战 3 :响应速度延伸知识

Activity.onCreate

Systrace 响应速度实战 3 :响应速度延伸知识

doFrame

Systrace 响应速度实战 3 :响应速度延伸知识

WebView 初始化

Systrace 响应速度实战 3 :响应速度延伸知识

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 的工具)

python app_profiler.py -p com.aboback.wanandroidjetpack

执行上面的命令之后,需要手动在手机上启动 App,然后主动结束

$ 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 报告

python report_html.py

就会得到下面这个

Systrace 响应速度实战 3 :响应速度延伸知识

不仅可以看到 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

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

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

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

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

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

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 通信,那么应用等待的时间就会变长,导致响应时间变慢

Systrace 响应速度实战 3 :响应速度延伸知识

这种一般可以点击这个 Task 最下面的 binder transaction 来查看 Binder 调用信息,比如

Systrace 响应速度实战 3 :响应速度延伸知识

有时候没有 Binder 信息,是被其他的等待的线程唤醒,那么可以查看唤醒信息,也可以找到应用是在等待什么

Systrace 响应速度实战 3 :响应速度延伸知识

放大上图中我们点击的 Runnable 的地方

Systrace 响应速度实战 3 :响应速度延伸知识

1.2 如何分析 Running 状态的 Task

Running 状态的任务就是目前在 CPU 某一个核心上运行的任务,如果某一段任务是 Running 状态,且耗时边长,那么需要分析:

  1. 是否应用的本身逻辑耗时,比如新增了某些代码逻辑
  2. 是否跑在了对应的核心上

Systrace 响应速度实战 3 :响应速度延伸知识

Systrace 响应速度实战 3 :响应速度延伸知识

在某些 Android 机器上,大家一般会对 App 的主线程和渲染线程进行调度方面的优化:一般前台应用的 UI Thread 和 RenderThread 都是跑在大核上的

1.3 如何分析 Runnable 状态的 Task

一个 Task 要从 Sleep 状态转到 Running 状态,必须先变成 Runnable 状态,其状态转换图如下

Systrace 响应速度实战 3 :响应速度延伸知识

在 Systrace 上的表现如下

Systrace 响应速度实战 3 :响应速度延伸知识

正常情况下,应用进入 Runnable 状态之后,会马上被调度器调度,进入 Running 状态,开始干活;但是在系统繁忙的时候,应用就会有大量的时间在 Runnable 状态,因为 cpu 已经跑满,各种任务都需要排队等待调度

如果应用启动的时候出现大量的 Runnable 任务,那么需要查看系统的状态

2. TraceView 工具在响应速度方面的使用

TraceView 指的是我们在 AS Profiler 里面抓取 CPU 信息的时候出现的那个,大家看下面的截图就知道了

Systrace 响应速度实战 3 :响应速度延伸知识

2.1 如何抓取应用启动时候的 TraceView

使用下面的命令可以抓取应用的冷启动,这些命令也可以分开执行,需要把里面的包名和 Activity 名切换成自己应用的包名

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. 冷启动 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

Systrace 响应速度实战 3 :响应速度延伸知识

Activity.onCreate

Systrace 响应速度实战 3 :响应速度延伸知识

doFrame

Systrace 响应速度实战 3 :响应速度延伸知识

WebView 初始化

Systrace 响应速度实战 3 :响应速度延伸知识

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 的工具)

python app_profiler.py -p com.aboback.wanandroidjetpack

执行上面的命令之后,需要手动在手机上启动 App,然后主动结束

$ 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 报告

python report_html.py

就会得到下面这个

Systrace 响应速度实战 3 :响应速度延伸知识

不仅可以看到 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

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

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

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

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

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

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 通信,那么应用等待的时间就会变长,导致响应时间变慢

Systrace 响应速度实战 3 :响应速度延伸知识

这种一般可以点击这个 Task 最下面的 binder transaction 来查看 Binder 调用信息,比如

Systrace 响应速度实战 3 :响应速度延伸知识

有时候没有 Binder 信息,是被其他的等待的线程唤醒,那么可以查看唤醒信息,也可以找到应用是在等待什么

Systrace 响应速度实战 3 :响应速度延伸知识

放大上图中我们点击的 Runnable 的地方

Systrace 响应速度实战 3 :响应速度延伸知识

1.2 如何分析 Running 状态的 Task

Running 状态的任务就是目前在 CPU 某一个核心上运行的任务,如果某一段任务是 Running 状态,且耗时边长,那么需要分析:

  1. 是否应用的本身逻辑耗时,比如新增了某些代码逻辑
  2. 是否跑在了对应的核心上

Systrace 响应速度实战 3 :响应速度延伸知识

Systrace 响应速度实战 3 :响应速度延伸知识

在某些 Android 机器上,大家一般会对 App 的主线程和渲染线程进行调度方面的优化:一般前台应用的 UI Thread 和 RenderThread 都是跑在大核上的

1.3 如何分析 Runnable 状态的 Task

一个 Task 要从 Sleep 状态转到 Running 状态,必须先变成 Runnable 状态,其状态转换图如下

Systrace 响应速度实战 3 :响应速度延伸知识

在 Systrace 上的表现如下

Systrace 响应速度实战 3 :响应速度延伸知识

正常情况下,应用进入 Runnable 状态之后,会马上被调度器调度,进入 Running 状态,开始干活;但是在系统繁忙的时候,应用就会有大量的时间在 Runnable 状态,因为 cpu 已经跑满,各种任务都需要排队等待调度

如果应用启动的时候出现大量的 Runnable 任务,那么需要查看系统的状态

2. TraceView 工具在响应速度方面的使用

TraceView 指的是我们在 AS Profiler 里面抓取 CPU 信息的时候出现的那个,大家看下面的截图就知道了

Systrace 响应速度实战 3 :响应速度延伸知识

2.1 如何抓取应用启动时候的 TraceView

使用下面的命令可以抓取应用的冷启动,这些命令也可以分开执行,需要把里面的包名和 Activity 名切换成自己应用的包名

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. 冷启动 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

Systrace 响应速度实战 3 :响应速度延伸知识

Activity.onCreate

Systrace 响应速度实战 3 :响应速度延伸知识

doFrame

Systrace 响应速度实战 3 :响应速度延伸知识

WebView 初始化

Systrace 响应速度实战 3 :响应速度延伸知识

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 的工具)

python app_profiler.py -p com.aboback.wanandroidjetpack

执行上面的命令之后,需要手动在手机上启动 App,然后主动结束

$ 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 报告

python report_html.py

就会得到下面这个

Systrace 响应速度实战 3 :响应速度延伸知识

不仅可以看到 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

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

赞(0) 打赏
部分文章转自网络,侵权联系删除b2bchain区块链学习技术社区 » Systrace 响应速度实战 3 :响应速度延伸知识求职学习资料
分享到: 更多 (0)

评论 抢沙发

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

b2b链

联系我们联系我们