Android专项测试之崩溃测试（CPU）

崩溃问题类型

❖ ANR：❖ 主线程5s内没响应
❖ Java Crash： ❖ 未捕获的android vm异常
❖ Native Crash： ❖ 未处理的native异常

应对方案：

可以使用腾讯的bugly

adb logcat *:S

只看Android异常信息

adb logcat *:E

查看当前页是那个应用

adb logcat | grep display11-24 16:33:46.839  1927  4078 E DollieAdapterService: notifyActivityState pkg:com.bilibili/com.bilibili.ui.main.MainActivity state:2 fg:true mUid:10623
11-24 16:33:46.839  1249  1755 E HiDATA_HiNetwork: onAppStart packageName is com.bilibili

只查看com.bilibili包的日志

adb shell ps | grep com.bilibili

根据进程id跟踪日志信息

adb logcat | grep 4534

查询包名

adb shell dumpsys activity top | less

发布前检测办法

❖ 健壮性测试：monkey、maximadb shell monkey -p com.bilibili -v 200
❖ 深度功能覆盖：appcrawler⾃动遍历
❖ 异常场景覆盖

常见场景用例

❖ 后端接⼜问题：❖ 弱⽹：完全超时、2G、3G❖ 接⼜返回异常：null返回❖ 接⼜变更问题：字段类型变更
❖ 逻辑问题❖ 异步线程问题：打开新页⾯再快速返回❖ 逻辑处理不当：横竖屏切换、前后台切换
❖ 内存消耗：低内存、循环翻页、执⾏可累计内存的操作

弱网测试方案

❖ 模拟器⽅案：❖ $(which emulator) -avd [your-avd-image] -netdelay 20000 -netspeed gsm❖ $(which emulator) 不直接使⽤emulator是因为有个bug
❖ 真机代理⽅案：charles模拟弱⽹
❖ ⽹关⽅案：Facebook的ATC

发布后建立监控体系

❖ 捕获异常进⾏处理
❖ 接⼊外部sdk，⽐如bugly

使用monitor

Android的monitor⼯具
❖ ddms
❖ profile
❖ debug
❖ trace

C:\Users\shenyf>monitor

实时查看线程的使用情况

开启性能剖析

在App中打开要查看的页面

就可以查看性能了，还可以元素定位

使用AndroidStudio的Profile功能

方式1：有源码的情况下进行分析

前提：已配置安卓开发环境，已连接手机
首先准备App源码
将源码克隆到本地，用AndroidStudio打开

方式2：有debug.apk

File–>Profile or Dubug APK等待加载，并已连接手机

点击一个事件就会有一个小红点，可以查看cpu、内存、网络、电量使用情况

CPU分析文档

CPU 性能剖析器的默认视图包括以下时间轴：

事件时间轴：显示应用中的 Activity 在其生命周期内不断转换经历各种不同状态的过程，并指示用户与设备的交互，包括屏幕旋转事件。如需了解如何在搭载 Android 7.1（API 级别 25）及更低版本的设备上启用事件时间轴，请参阅启用高级性能剖析。
CPU 时间轴：显示应用的实时 CPU 使用率（以占总可用 CPU 时间的百分比表示）以及应用当前使用的线程总数。此时间轴还会显示其他进程（如系统进程或其他应用）的 CPU 使用率，以便您可以将其与您应用的 CPU 使用率进行对比。您可以通过沿时间轴的横轴方向移动鼠标来检查历史 CPU 使用率数据。
线程活动时间轴：列出属于应用进程的每个线程，并使用下面列出的颜色在时间轴上指示它们的活动。记录跟踪数据后，您可以从此时间轴上选择一个线程，以在跟踪数据窗格中检查其数据。

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

CPU 性能剖析器还会报告 Android Studio 和 Android 平台添加到应用进程的线程的 CPU 使用率，这些线程包括 JDWP、Profile Saver、Studio:VMStats、Studio:Perfa 和 Studio:Heartbeat 等（不过，它们在线程活动时间轴上显示的确切名称可能有所不同）。Android Studio 报告此数据是为了方便您确定线程活动和 CPU 使用率什么时候是由您的应用的代码实际引发的。

录制点击事件的CPU使用情况

点击CPU

创建、修改或查看记录配置

您可以在 CPU Recording Configurations 对话框中创建、修改和查看记录配置，从 CPU 性能剖析器顶部的记录配置下拉菜单中选择 Edit configurations 即可打开该对话框。

如需查看某个现有记录配置的设置，请在 CPU Recording Configurations 对话框的左侧窗格中选择该配置。

如需创建一个新的记录配置，请执行以下操作：

点击对话框左上角的 Add 图标。这样会创建一个包含一些默认设置的新配置。
为您的配置命名。
选择一种 Trace Technology。
对于采样记录配置，以微秒 (μs) 为单位指定 Sampling interval。此值表示应用的每个调用堆栈样本的时间间隔。指定的时间间隔越短，达到记录数据的文件大小限制就越快。
对于写入连接设备的记录数据，以兆字节 (MB) 为单位指定 File size limit。当您停止记录时，Android Studio 会解析此数据并将其显示在分析器窗口中。因此，如果您提高此限制并记录大量的数据，Android Studio 解析文件所需的时间会大大增加，并且可能会变得无响应。

注意：如果您使用的连接设备搭载的是 Android 8.0（API 级别 26）或更高版本，那么对跟踪数据的文件大小没有限制，系统会忽略此值。不过，您仍需留意每次记录后设备收集了多少数据，Android Studio 可能会无法解析大型跟踪文件。例如，如果您记录的是采样时间间隔很短的采样跟踪数据，或是在应用于短时间内调用许多方法的情况下记录检测跟踪数据，那么很快就会生成大型跟踪文件。

如需接受所做的更改并继续对其他配置进行更改，请点击 Apply。如需接受进行的所有更改并关闭对话框，请点击 OK。

点击录制

选择记录配置

在开始记录跟踪信息之前，请为需捕获的分析信息选择适当的记录配置：

对 Java 方法采样：在应用的 Java 代码执行期间，频繁捕获应用的调用堆栈。分析器会比较捕获的数据集，以推导与应用的 Java 代码执行有关的时间和资源使用信息。
基于采样的跟踪存在一个固有的问题，那就是如果应用在捕获调用堆栈后进入一个方法并在下次捕获前退出该方法，分析器将不会记录该方法调用。如果您想要跟踪生命周期如此短的方法，应使用插桩跟踪。
跟踪 Java 方法：在运行时检测应用，从而在每个方法调用开始和结束时记录一个时间戳。系统会收集并比较这些时间戳，以生成方法跟踪数据，包括时间信息和 CPU 使用率。
请注意，与检测每个方法相关的开销会影响运行时性能，并且可能会影响分析数据；对于生命周期相对较短的方法，这一点更为明显。此外，如果应用在短时间内执行大量方法，则分析器可能很快就会超出其文件大小限制，因而不能再记录更多跟踪数据。
对 C/C++ 函数采样：捕获应用的原生线程的采样跟踪数据。如需使用此配置，您必须将应用部署到搭载 Android 8.0（API 级别 26）或更高版本的设备上。
在内部，此配置使用 simpleperf 跟踪应用的原生代码。如果需为 simpleperf 指定其他选项，如对特定设备 CPU 采样或指定高精度采样持续时间，您可以从命令行使用 simpleperf。
跟踪系统调用：捕获非常翔实的细节，以便您检查应用与系统资源的交互情况。您可以检查线程状态的确切时间和持续时间、直观地查看所有内核的 CPU 瓶颈在何处，并添加需分析的自定义跟踪事件。当您排查性能问题时，此类信息至关重要。如需使用此配置，您必须将应用部署到搭载 Android 7.0（API 级别 24）或更高版本的设备上。
使用此跟踪配置时，您可以通过检测代码，直观地标记性能剖析器时间轴上的重要代码例程。如需检测 C/C++ 代码，请使用由 trace.h 提供的原生跟踪 API。如需检测 Java 代码，请使用 Trace 类。如需了解详情，请参阅检测您的应用代码。
此跟踪配置建立在 systrace 的基础之上。您可以使用 systrace 命令行实用程序指定除 CPU 性能剖析器提供的选项之外的其他选项。systrace 提供的其他系统级数据可帮助您检查原生系统进程并排查丢帧或帧延迟问题。

点击App上要检测的动作，在点击stop停止录制

选定范围：确定需在跟踪数据窗格中检查所记录时间的哪一部分。当您首次记录跟踪数据时，CPU 性能剖析器会自动在 CPU 时间轴上选择记录的完整长度。如需仅检查已记录的时间范围中的一部分的跟踪数据，请拖动突出显示区域的边缘。
“Interaction”部分：沿着时间轴显示用户互动和应用生命周期事件。
“Threads”部分：沿时间轴针对每一个线程显示线程状态活动（例如运行、休眠等）和调用图表（在 System Trace 中则为跟踪事件图表）。

使用鼠标和键盘快捷键在时间轴上导航。
双击线程名称，或在选中线程时按 Enter 键以展开或折叠线程。
选择某个线程即可在“Analysis”窗格中查看更多信息。按住 Shift 或 Ctrl（Mac 上为 Command）可选择多个线程。
选择方法调用（或 System Trace 中的跟踪事件），以在“Analysis”窗格中查看更多信息。

“Analysis”窗格：显示您选择的时间范围和线程/方法调用的跟踪数据。在此窗格中，您可以选择如何查看每个堆栈轨迹（使用“Analysis”标签页），以及如何测量执行时间（使用“Time reference”下拉菜单）。
“Analysis”窗格标签页：选择如何显示跟踪数据详细信息。如需详细了解各个选项，请参阅检查跟踪数据。
"Time reference"菜单：选择以下选项之一，以确定如何测量每次调用的时间信息（仅在示例/跟踪 Java 方法中受支持）：

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

Filter：按函数、方法、类或软件包名称过滤跟踪数据。例如，如果您需快速识别与特定调用相关的跟踪记录数据，请在搜索字段中输入名称。在 Flame chart 标签页中，会突出显示包含符合搜索查询条件的调用、软件包或类的调用堆栈。在 Top down 和 Bottom up 标签页中，这些调用堆栈优先于其他跟踪结果。您还可以通过勾选搜索字段旁边的相应方框来启用以下选项：

Regex：如需在您的搜索中包含正则表达式，请使用此选项。
Match case：如果您的搜索区分大小写，请使用此选项。

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

导出跟踪数据

导入跟踪数据

在性能剖析器的 Sessions 窗格中点击 Start new profiler session 图标，然后选择 Load from file。

您可以检查导入到 CPU 性能剖析器中的跟踪数据，就像检查直接在 CPU 性能剖析器中捕获的跟踪数据一样，但有下面几点不同：

CPU Activity 未显示在 CPU 时间轴上（在 System Trace 中除外）。
Threads 部分中的时间轴不会显示线程状态，如正在运行、等待或休眠（在 System Trace 中除外）。

检查跟踪数据

对于方法轨迹和函数轨迹，您可以直接在 Threads 时间轴中查看 Call Chart，并从 Analysis 窗格中查看 Flame Chart、Top Down、Bottom Up 和 Events 标签页。对于系统轨迹，您可以直接在 Threads 时间轴中查看 Trace Events，并从 Analysis 窗格中查看 Flame Chart、Top Down、Bottom Up 和 Events 标签页。

使用 Call Chart 检查跟踪数据

Call Chart 以图形方式来呈现方法跟踪数据或函数跟踪数据，其中调用的时间段和时间在横轴上表示，而其被调用方则在纵轴上显示。对系统 API 的调用显示为橙色，对应用自有方法的调用显示为绿色，对第三方 API（包括 Java 语言 API）的调用显示为蓝色。图 4 中显示了一个调用图表示例，说明了给定方法或函数的 Self 时间、Children 时间和 Total 时间的概念。如需详细了解这些概念，请参阅有关如何使用“Top Down”和“Bottom Up”标签页检查跟踪数据的部分。

提示：如需跳转到某个方法或函数的源代码，请右键点击该方法或函数，然后选择 Jump to Source。在“分析”窗格的任意标签页中都可以执行此操作。

使用“Flame Chart”标签检查跟踪数据

Flame Chart 标签页提供一个倒置的调用图表，用来汇总完全相同的调用堆栈。也就是说，将具有相同调用方顺序的完全相同的方法或函数收集起来，并在火焰图中将它们表示为一个较长的横条（而不是将它们显示为多个较短的横条，如调用图表中所示）。这样更方便您查看哪些方法或函数消耗的时间最多。不过，这也意味着，横轴不代表时间轴，而是表示执行每个方法或函数所需的相对时间。

为帮助说明此概念，不妨考虑图中的调用图表。请注意，方法 D 多次调用 B（B1、B2 和 B3），其中一些对 B 的调用也调用了 C（C1 和 C3）。

由于 B1、B2 和 B3 具有相同的调用方顺序 (A → D → B)，因此系统将它们汇总在一起，如图 6 所示。同样，也将 C1 和 C3 汇总在一起，因为它们也具有相同的调用方顺序 (A → D → B → C)。请注意，C2 不包括在内，因为它具有不同的调用方顺序 (A → D → C)。

汇总的调用用于创建火焰图，如图所示。请注意，对于火焰图中的任何给定调用，占用最多 CPU 时间的被调用方最先显示。

使用“Top Down”和“Bottom Up”检查跟踪数据

Top Down 标签显示一个调用列表，在该列表中展开方法或函数节点会显示它的被调用方。图 8 显示了图 4 中调用图表的自上而下图。图中的每个箭头都从调用方指向被调用方。

如图 8 所示，在 Top Down 标签页中展开方法 A 的节点会显示它的被调用方，即方法 B 和 D。在此之后，展开方法 D 的节点会显示它的被调用方，即方法 B 和 C，依此类推。与 Flame chart 标签页类似，“Top Down”树也汇总了具有相同调用堆栈的完全相同的方法的跟踪信息。也就是说，Flame chart 标签页提供了 Top down 标签页的图形表示方式。

Top Down 标签提供以下信息来帮助说明在每个调用上所花的 CPU 时间（时间也可表示为在选定范围内占线程总时间的百分比）：

Self：方法或函数调用在执行自己的代码（而非被调用方的代码）上所花的时间，如图 4 中的方法 D 所示。
Children：方法或函数调用在执行它的被调用方（而非自己的代码）上所花的时间，如图 4 中的方法 D 所示。
Total：方法的 Self 时间和 Children 时间的总和。这表示应用在执行调用时所用的总时间，如图 4 中的方法 D 所示。

Bottom Up 标签页显示一个调用列表，在该列表中展开函数或方法的节点会显示它的调用方。沿用图 8 中所示的跟踪数据示例，图 9 提供了方法 C 的“Bottom Up”树。在该“Bottom Up”树中打开方法 C 的节点会显示它独有的各个调用方，即方法 B 和 D。请注意，尽管 B 调用 C 两次，但在“Bottom Up”树中展开方法 C 的节点时，B 仅显示一次。在此之后，展开 B 的节点会显示它的调用方，即方法 A 和 D。

Bottom Up 标签页用于按照占用的 CPU 时间由多到少（或由少到多）的顺序对方法或函数排序。您可以检查每个节点以确定哪些调用方在调用这些方法或函数上所花的 CPU 时间最多。与“Top Down”树相比，“Bottom Up”树中每个方法或函数的时间信息参照的是每个树顶部的方法（顶部节点）。CPU 时间也可表示为在该记录期间占线程总时间的百分比。下表说明了如何解读顶部节点及其调用方（子节点）的时间信息。

	Self	Children	Total
“Bottom Up”树顶部的方法或函数（顶部节点）	表示方法或函数在执行自己的代码（而非被调用方的代码）上所花的总时间。与“Top Down”树相比，此时间信息表示在记录的持续时间内对此方法或函数的所有调用时间的总和。	表示方法或函数在执行它的被调用方（而非自己的代码）上所花的总时间。与“Top Down”树相比，此时间信息表示在记录的持续时间内对此方法或函数的被调用方的所有调用时间的总和。	Self 时间和 Children 时间的总和。
调用方（子节点）	表示被调用方在由调用方调用时的总 Self 时间。以图 9 中的“Bottom Up”树为例，方法 B 的 Self 时间将等于每次执行由方法 B 调用的方法 C 所用的 Self 时间的总和。	表示被调用方在由调用方调用时的总 Children 时间。以图 9 中的“Bottom Up”树为例，方法 B 的 Children 时间将等于每次执行由方法 B 调用的方法 C 所用的 Children 时间的总和。	Self 时间和 Children 时间的总和。

注意：对于给定的记录，当分析器达到文件大小限制时，Android Studio 会停止收集新数据（不过，不会停止记录）。在执行检测跟踪时，这种情况通常发生得更快，因为与采样跟踪相比，此类跟踪会在更短的时间内收集更多的数据。如果您将检查时间范围延长至达到限制后的记录时段，则跟踪数据窗格中的时间数据不会发生变化（因为没有新数据可用）。此外，当您仅选择没有可用数据的那部分记录时，对于时间信息，轨迹窗格将显示 NaN。

使用“Events”表格检查轨迹

“Events”表格列出了当前所选线程中的所有调用。您可以点击列标题对它们进行排序。通过选择表格中的某一行，您可以在时间轴上导航到所选调用的开始时间和结束时间。这样，您就可以在时间轴上准确定位事件。

检查系统轨迹

检查系统跟踪数据时，您可以在 Threads 时间轴中检查 Trace Events，以查看每个线程上所发生事件的详细信息。将鼠标指针悬停在某个事件上，可查看该事件的名称以及在每种状态下所花费的时间。点击事件可在 Analysis 窗格中查看详情。

检查系统轨迹：CPU 核心

除了 CPU 调度数据外，系统轨迹还包括按核心记录的 CPU 频率。它可以显示每个核心上的活动数量，让您可以了解哪些是新型移动处理器中的“大”核心或“小”核心。

CPU Cores 窗格（如图 11 所示）显示每个核心上安排的线程活动。将鼠标指针悬停在某个线程活动上，可查看该核心在该特定时间在哪个线程上运行。

如需详细了解如何检查系统轨迹信息，请参阅 systrace 文档的调查界面性能问题部分。

检查系统轨迹：帧渲染时间轴

您可以检查应用在主线程和 RenderThread 上渲染每个帧所用的时间，以调查造成界面卡顿和帧速率低的瓶颈。

如需查看帧渲染数据，请使用使您可以跟踪系统调用的配置来记录轨迹。记录轨迹后，在 Display 部分的 Frames 时间轴下查找有关每个帧的信息，如图 12 所示。

Display 部分中显示的跟踪记录如下：

Frames：在绘制帧时。长帧（大于 16 毫秒）显示为红色。
SurfaceFlinger：在 SurfaceFlinger 处理帧缓冲区时。SurfaceFlinger 是负责发送要显示的缓冲区的系统进程。
VSYNC：同步显示流水线的信号。错过 VSYNC 的帧将产生额外的输入延迟。这在高刷新率显示器上尤为重要。
BufferQueue：有多少帧缓冲区排队等待 SurfaceFlinger 使用。对于部署到搭载 Android 9 或更高版本的设备的应用，这一跟踪记录会显示应用 Surface BufferQueue 的缓冲区计数（0、1 或 2）。它可帮助您了解图像缓冲区在 Android 图形组件之间切换时的状态。例如，值 2 表示该应用当前处于三重缓冲状态，这可能会导致额外的输入延迟。

检查系统轨迹：进程内存 (RSS)

对于部署到搭载 Android 9 或更高版本的设备的应用，Process Memory (RSS) 部分会显示该应用当前使用的物理内存量。

Total

这是您的进程当前使用的物理内存总量。在基于 Unix 的系统上，这被称为“驻留集大小”，是匿名分配、文件映射和共享内存分配所使用的所有内存的组合。

对于 Windows 开发者，驻留集大小类似于工作集大小。

Allocated

此计数器跟踪进程的正常内存分配目前占用了多少物理内存。这些分配均匿名（不由特定文件支持）且不公开（不共享）。在大多数应用中，这由堆分配量（使用 malloc 或 new）和堆栈内存组成。从物理内存中换出时，这些分配会写入系统交换文件。

File Mappings

此计数器会跟踪进程用于文件映射的物理内存量，也就是说，通过内存管理器从文件映射至内存区域的内存。

Shared

此计数器跟踪在此进程和系统中其他进程之间共享的内存所用的物理内存量。

通过应用插桩生成跟踪日志

https://developer.android.google.cn/studio/profile/generate-trace-logs?hl=zh_cn