利用ACR摘要进行崩溃调试
“汇总崩溃报告”(ACR) 摘要将所有崩溃调试数据整理到一个markdown文件中。Vega Studio会在每次符号化结束时自动生成摘要。
先决条件
- 来自您的Vega应用的崩溃文件 (.acr)。
- 阅读应用崩溃报告符号化，熟悉ACR文件及其数据
了解ACR文件和摘要报告
ACR文件和摘要报告适用于不同的用途，也不是同一个文件。
| 定义 | 位置 | 何时共享 | |
|---|---|---|---|
| ACR文件 | 设备在崩溃时生成的原始崩溃数据 | 从设备复制到您选择的本地文件夹 | 联系亚马逊支持人员时共享此文件 |
| 摘要报告 | Vega Studio在符号化后生成的经过解码的可读Markdown文件。用于确定崩溃的根本原因。 | 生成的位置为acr_workdir_<hash>/summary_report.md（在Vega Studio中自动打开） |
请勿与亚马逊支持人员共享此文件 |
如何使用摘要
符号化完成后，Vega Studio会自动在新选项卡中打开摘要。
要诊断崩溃，请按照以下步骤操作：
-
从元数据开始 - 检查崩溃原因和语言，以了解出现的崩溃类型。
-
检查符号化堆栈跟踪 - 在堆栈跟踪中查找您的应用代码中的函数名称。
-
查看系统信息 - 检查崩溃时的使用情况。
-
与源代码交叉引用 - 使用堆栈跟踪中的文件路径和行号来找出项目中有问题的代码。
-
确定后续步骤：
摘要结构
以下各部分描述了摘要的组成部分，以及每个组成部分包含的信息。
文件头
包含ACR文件的文件路径和相关临时工作目录的路径。可以使用这些路径来查找原始崩溃文件和中间符号化文件。
示例：
Path to ACR file: /Users/username/my-app-crash.acr
Path to acr_workdir: /Users/username/acr_workdir-a1b2c3d4
Metadata（元数据）
该部分包含ACR文件中的相关元数据：
-
PROCESS - 崩溃的进程。示例：
com.example.myapp或/usr/bin/eventmgrd -
CRASH_REASON - 崩溃的原因。
-
CRASH_LANG - 崩溃代码的编程语言。可能的值： Native、JavaScript或Unknown。如果出现ANR（应用无响应）问题，当崩溃线程ID与JavaScript线程ID匹配时，ACR文件会报告“Unknown”（未知）。阻塞可能发生在原生代码中，也可能发生在JavaScript代码中，因此该工具无法自动确定语言。
-
APP_VERSION - 崩溃的应用版本。示例：
1.2.3或2024.11.15 -
OS_BUILD_NUMBER - 生成ACR文件时所用操作系统的内部版本号。示例：
1001010003820 -
BUILD_VARIANT - 生成ACR文件时所用的版本类型。可能的值：user、userdebug或user-external。
OS release file（操作系统发布文件）
包含ACR文件收集的/etc/os-release的内容。此信息可帮助您验证发生崩溃的确切操作系统版本和编译配置，这在重现问题或确定崩溃是否特定于操作系统时非常有用。
Symbolicated stacktraces（符号化堆栈跟踪）
该部分包含解码后的堆栈跟踪，这些堆栈跟踪显示了导致崩溃的函数调用的确切位置和顺序。
崩溃语言决定了该部分中出现的堆栈跟踪：
-
JavaScript崩溃： 只显示JavaScript堆栈跟踪
-
原生崩溃： 默认情况下仅显示原生堆栈跟踪
读懂堆栈帧
堆栈跟踪可显示导致崩溃的函数调用顺序。跟踪中的每行都是一个堆栈框架。
原生堆栈帧包括帧号、内存地址和库名称。如果调试符号可用，堆栈帧还会显示函数名称、源文件和行号。
#0 0xa1a701bc in VegaProjectTMTurboModule::VegaProjectTM::voidFunc (this=0xa1d99838) at /Users/developer_name/workspace/vega/testapp/VegaProjectTM/kepler/turbo-modules/VegaProjectTM.cpp:33
JavaScript堆栈帧包含了函数名称、源文件和行号。
at onPress (node_modules/@amazon-devices/react-native-kepler/Libraries/Pressability/Pressability.js:587:18)
了解堆栈跟踪中的??
如果您在原生堆栈帧中看到??，就说明符号化工具无法解析该内存地址处的函数名称。这通常表示操作系统级或系统库代码没有可用的调试符号。
#0 0xb6e01b26 in ?? () from /private/var/folders/_p/.../lib/libc.so.6
包含??的帧不是应用中的错误。它们代表了在没有导出调试符号的情况下运行的系统代码。请重点关注显示应用的文件路径和函数名称的帧。
要确定崩溃是源于您的代码还是亚马逊的代码，请参阅检测应用崩溃的根源。
低内存杀手 (LMK) 崩溃
LMK崩溃不会产生堆栈跟踪，因为操作系统会在外部终止进程，而进程本身并未发生崩溃。如果符号化堆栈跟踪部分为空，且CRASH_REASON指示LMK，请跳过此部分，改为检查系统信息以获取内存压力数据。
System info（系统信息）
该部分显示崩溃时记录在ACR文件中的系统信息，包括：
-
<meminfo>部分中最消耗内存的5个进程示例： 如果您的应用占用了250MB并出现在前5名，则内存压力可能是相关因素
-
<pressure_info>部分中的压力信息统计数据示例： 内存压力值高表明系统可用内存较少。
Native stacktrace - all threads（原生堆栈跟踪 - 所有线程）
该部分显示所有线程的原生堆栈跟踪。您可以通过在交互式GDB会话中运行thread apply all bt来生成此跟踪。
示例
未呈现的ACR摘要示例：
# ACR摘要
Path to ACR file: [/Users/user/callie-test.acr](./crashfile)
Path to acr_workdir: /Users/user/acr_workdir-c4bcb13c
## 元数据
PROCESS: /usr/bin/eventmgrd
CRASH_REASON： SIGABRT
CRASH_LANG： Native
APP_VERSION： N/A
OS_BUILD_NUMBER： 1001010003820
BUILD_VARIANT：user
PRODUCT_NAME：callie
BUILD_FINGERPRINT： 4.0.137942.0(3072cab629675a74)/38N:user/release-keys
OE_VERSION： 4.0.0
## 操作系统发布文件
NAME="OS"
OE_VERSION="4.0.0"
OS_MAJOR_VERSION="1"
OS_MINOR_VERSION="1"
RELEASE_ID="10"
OS_VERSION="1.1"
BRANCH_CODE="TV Ship"
BUILD_DESC="OS 1.1 (TV Ship/38)"
BUILD_FINGERPRINT="4.0.137942.0(3072cab629675a74)/38N:user/release-keys"
BUILD_VARIANT="user"
BUILD_TAGS="release-keys"
BUILD_DATE="Fri Jul 25 01:48:20 UTC 2025"
BUILD_TIMESTAMP="1753408100"
VERSION_NUMBER="1001010003820"
## 符号化堆栈跟踪
### 原生堆栈跟踪
<details open>
<summary>展开以查看原生堆栈跟踪</summary>
<pre>
#0 __libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:47
#1 0xb6877d98 in __GI___ioctl (fd=-4, request=3224396289) at ../sysdeps/unix/sysv/linux/ioctl.c:35
#2 0xb67544ba in binder_call_internal (runtime=0xf8a2c8, target=<optimized out>, code=<optimized out>, request=<optimized out>, response=0xb2d32cd8) at /usr/src/debug/app-framework-neocoreipc/ssot-r0/app-framework-neocoreipc/cargo-project/api/runtimes/binder/direct/binder.c:1057
#3 0xb6754548 in binder_call (runtime=<optimized out>, target=<optimized out>, code=<optimized out>, request=<optimized out>, response=0xb2d32cd8) at /usr/src/debug/app-framework-neocoreipc/ssot-r0/app-framework-neocoreipc/cargo-project/api/runtimes/binder/direct/binder.c:1082
#4 0xb6754d3c in ipcn_runtime_call (runtime=<optimized out>, remote_handle=<optimized out>, code=<optimized out>, request=<optimized out>, reply=reply@entry=0xb2d32cd8) at /usr/src/debug/app-framework-neocoreipc/ssot-r0/app-framework-neocoreipc/cargo-project/api/runtimes/binder/direct/ipcn_runtime_binder.c:235
#5 0xb67569a6 in ipcn_call (runtime=0xf8a2c8, target=<optimized out>, code=<optimized out>, request=<optimized out>, reply=0xb2d32cd8) at /usr/src/debug/app-framework-neocoreipc/ssot-r0/app-framework-neocoreipc/cargo-project/api/core/ipcn_call.c:103
#6 0xb1be0418 in ?? ()
回溯已停止：前一帧与此帧相同（堆栈损坏？）
故障排除
如果您在ACR分析或符号化方面遇到问题，请参阅修复崩溃分析问题。
相关主题
Last updated: 2026年2月18日
