Android Studio Profiler CPU检测卡顿

前言

Android Studio 3.0 及更高版本中的 Android Profiler 取代了 Android Monitor 工具。Android Profiler工具可提供实时数据,帮助您了解应用的CPU、内存、网络和电池资源使用情况。
在这里插入图片描述

  • 图1

Android Profiler 显示当前正在分析的进程和设备

  • 图2

在Sessions窗格中,选择要查看的会话,或启动一个新的分析会话

  • 图3

使用缩放按钮控制要查看的时间轴范围,或使用 Attach to live 按钮跳转到实时更新

  • 图4

事件时间轴显示与用户输入相关的事件,包括键盘活动、音量控制变化和屏幕旋转

  • 图5

共享时间轴视图,包括 CPU、内存、网络和耗电量图表

此共享时间轴视图只显示时间轴图表。

CPU性能剖析器

使用 CPU 性能分析器在与应用交互时实时检查应用的CPU使用率和线程活动,也可以检查记录的方法轨迹、函数轨迹和系统轨迹的详情。点击上图CPU相关部分图标可进入如下图所示:

功能介绍

在这里插入图片描述

  • 图1:事件时间轴

显示应用中的 activity在其生命周期内不断转换经历各种不同状态的过程,并指示用户与设备的交互,包括屏幕旋转事件

  • 图2:CPU 时间轴

显示应用的实时 CPU 使用率(以占总可用 CPU 时间的百分比表示)以及应用当前使用的线程总数。此时间轴还会显示其他进程(如系统进程或其他应用)的 CPU 使用率,以便您可以将其与您应用的 CPU 使用率进行对比。您可以通过沿时间轴的横轴方向移动鼠标来检查历史 CPU 使用率数据。

  • 图3:线程活动时间轴

列出属于应用进程的每个线程,并使用下面列出的颜色在时间轴上指示它们的活动。

  1. 绿色: 表示线程处于活动状态或准备使用CPU。也就是说,线程处于正在运行或可运行状态。
  2. 黄色: 表示线程处于活动状态,但它正在等待一项 I/O 操作(如磁盘或网络 I/O),然后才能完成它的工作。
  3. 灰色: 表示线程正在休眠且没有消耗任何 CPU 时间。 当线程需要访问尚不可用的资源时,就会出现这种情况。在这种情况下,要么线程主动进入休眠状态,要么内核将线程置于休眠状态,直到所需的资源可用。
  • 图4:记录配置

Callstack Sample Recording(对 C/C++ 函数采样)

捕获应用的原生线程的采样跟踪数据。在内部,此配置使用 simpleperf 跟踪应用的原生代码。

System Trace Recording(跟踪系统调用)

捕获非常翔实的细节,以便您检查应用与系统资源的交互情况。您可以检查线程状态的确切时间和持续时间、直观地查看所有内核的CPU瓶颈在何处,并添加需分析的自定义跟踪事件。

Java/Kotlin Method Trace Recording(跟踪 Java 方法)

在运行时检测应用,从而在每个方法调用开始和结束时记录一个时间戳。系统会收集并比较这些时间戳,以生成方法跟踪数据,包括时间信息和 CPU 使用率。

请注意,与检测每个方法相关的开销会影响运行时性能,并且可能会影响分析数据;对于生命周期相对较短的方法,这一点更为明显。此外,如果应用在短时间内执行大量方法,则分析器可能很快就会超出其文件大小限制,因而不能再记录更多跟踪数据。

Java/Kotlin Method Trace Recording(对 Java 方法采样)

在应用的 Java 代码执行期间,频繁捕获应用的调用堆栈。分析器会比较捕获的数据集,以推导与应用的 Java 代码执行有关的时间和资源使用信息。

基于采样的跟踪存在一个固有的问题,那就是如果应用在捕获调用堆栈后进入一个方法并在下次捕获前退出该方法,分析器将不会记录该方法调用。如果您想要跟踪生命周期如此短的方法,应使用插桩跟踪。

记录

在菜单中选择记录配置,然后点击 Record
在这里插入图片描述
分析结果如下:
在这里插入图片描述
图1 :选定范围

确定需在跟踪数据窗格中检查所记录时间的哪一部分。当您首次记录跟踪数据时,CPU 性能剖析器会自动在CPU时间轴上选择记录的完整长度。如需仅检查已记录的时间范围中的一部分的跟踪数据,请拖动突出显示区域的边缘。

图2 :“Interaction”部分

沿着时间轴显示用户互动和应用生命周期事件。

图3 :“Threads”部分

沿时间轴针对每一个线程显示线程状态活动

图4 :“Analysis”窗格

显示您选择的时间范围和线程/方法调用的跟踪数据。在此窗格中,您可以选择如何查看每个堆栈轨迹(使用“Analysis”标签页),以及如何测量执行时间(使用“Time reference”下拉菜单)。

图5 :“Analysis”窗格标签页

选择如何显示跟踪数据详细信息。 Flame Chart、Top Down、Bottom Up 和 Events 标签页

图6 :"Time reference"菜单

Wall clock time:该时间信息表示实际经过的时间。

Thread time:该时间信息表示实际经过的时间减去线程没有占用 CPU 资源的那部分时间。对于任何给定的调用,其线程时间始终小于或等于其挂钟时间。使用线程时间可以让您更好地了解线程的实际 CPU 使用率中有多少是给定方法或函数占用的。

图7 :"Time reference"菜单

按函数、方法、类或软件包名称过滤跟踪数据

检查线程时间轴时,您可以使用以下快捷方式:
  • 放大: 按 W 或在按住 Ctrl 键的同时滚动鼠标滚轮(在 Mac 上,按住 Command 键)。
  • 缩小: 按 S 或在按住 Ctrl 键的同时向后滚动鼠标滚轮(在 Mac 上,按住 Command 键)。
  • 向左平移: 按 A 键或在按住空格键的同时向右拖动鼠标。
  • 向右平移: 按 D 键或在按住空格键的同时向左拖动鼠标。
  • 展开或收起线程: 双击线程名称,或在选中线程时按 Enter 键。
导入记录

如需导入跟踪文件,请在性能剖析器的 Sessions 窗格中点击 Start new profiler session 图标 ,然后选择 Load from file。
在这里插入图片描述

导出记录

如需从 Sessions 窗格导出跟踪文件,在Sessions窗格中,右键点击需导出的记录的跟踪数据。点击会话条目右侧的 Export method trace 或 Export system trace 按钮。浏览到需保存文件的目标位置,指定文件名,然后点击 OK。
在这里插入图片描述

界面卡顿检测

出现卡顿通常是因为界面线程(在大多数应用中,它是主线程)上存在一些减速或阻塞异步调用。您可以利用系统轨迹(System Trace Recording)找出问题所在。

在 Android 10 及更低版本上检测卡顿

利用 System Trace Recording 检查结果如下:
在这里插入图片描述

  • Frames:此部分显示应用中的界面线程和RenderThread轨迹事件。时长超过 16毫秒的事件会以红色表示,以突出显示潜在的卡顿帧,因为它们超出了以 60 帧/秒 (fps) 的速度进行呈现的截止时间。
  • SurfaceFlinger:此部分显示SurfaceFlinger处理帧缓冲区的时间。SurfaceFlinger是负责将缓冲区内容发送到显示屏的系统进程。
  • VSYNC: 此部分显示VSYNC,这是一个表示与显示流水线保持同步的信号。该轨迹会显示 VSYNC-app信号,这个信号会在应用启动时间过晚时显示。通常情况下,发生这种情况是因为界面线程处于忙碌状态。在动画播放期间,它会导致屏幕上出现可见的闪烁,并且在动画或滚动完成之前,会持续带来额外的输入延迟。
  • BufferQueue:此部分显示有多少帧缓冲区在排队等待 SurfaceFlinger 使用。

检查卡顿方法:

  1. 查看 Display 中的 Frames 轨迹。红色帧是要调查的候选对象。
    在这里插入图片描述
  2. 发现可能存在卡顿的帧后,进行放大直到您看到界面线程和 RenderThread 中的轨迹事件。
    在这里插入图片描述
    从上图分析可知,滚动列表的渲染、绘制页面耗时较长,需要优化页面层级和自定义控件。
在 Android 11 及更高版本上检测卡顿

捕获轨迹后,Android Studio 将显示 Frame Lifecycle 部分
在这里插入图片描述

  • Application:此轨迹显示从缓冲区被应用移出队列到重新回到队列的时间。这通常对应于 RenderThread 中的轨迹事件。
  • Wait for GPU:此轨迹显示 GPU 拥有相应缓冲区的时长。该时长指的是,从相应缓冲区的内容被发送至 GPU,到 GPU 利用相应缓冲区的内容完成其工作,期间所经历的时间。这并不表示 GPU 在此期间仅使用相应缓冲区的内容工作。
  • Composition:此轨迹显示,从 SurfaceFlinger 占有相应缓冲区并发送相应缓冲区的内容以进行合成,到相应缓冲区的内容被发送到显示屏,期间所经历的时间。
  • Frames on display:此轨迹显示相应帧在屏幕上的时长。

Android Studio 还会在 Frames 标签页中以表格格式显示轨迹中的所有帧。
在这里插入图片描述
Frame Duration 列表示从 Application 开始到 Frames on Display开始所经历的时间。这本质上是呈现帧的端到端时长。

检查卡顿方法:

  1. 按 Application 列对 Frames 表进行降序排序,使耗时最长的帧首先显示。

在这里插入图片描述
2. 找到运行时间最长的帧,然后选择表中的一行。这将在左侧的时间轴视图中放大所选的帧。

在这里插入图片描述
3. 在 Frame Lifecycle 和 Threads 部分查看相关线程。

在这里插入图片描述
从上图分析可知,滚动列表布局的渲染、绘制页面耗时较长,需要优化页面层级

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值