Console

Settings

Sign out

Notifications

Alexa

亚马逊应用商店

Ring

AWS

文档

Support

My Cases

Console

Vega开发者文档

主页

新手入门

设计和开发

应用发布

参考

支持

利用ACR摘要进行崩溃调试

开放Beta测试文档 作为预发布开放Beta测试的一项内容，亚马逊提供了此技术文档。随着亚马逊收到反馈并对功能进行迭代，所描述的这些功能可能会发生变化。有关最新功能的信息，请参阅最新的发布说明。

“汇总崩溃报告”(ACR) 摘要将所有崩溃调试数据整理到一个markdown文件中。Vega Studio会在每次符号化结束时自动生成摘要。

先决条件

来自您的Vega应用的崩溃文件 (.acr)。
阅读应用崩溃报告符号化，熟悉ACR文件及其数据

了解ACR文件和摘要报告

ACR文件和摘要报告适用于不同的用途，也不是同一个文件。

	定义	位置
ACR文件	设备在崩溃时生成的原始崩溃数据	从设备复制到您选择的本地文件夹
摘要报告	Vega Studio在符号化后生成的经过解码的可读Markdown文件。用于确定崩溃的根本原因。	生成的位置为`acr_workdir_<hash>/summary_report.md`（在Vega Studio中自动打开）

重要须知： 当您联系亚马逊客户支持时，请共享ACR文件和摘要报告。摘要报告包含来自您的应用的相关符号化堆栈。ACR文件包含其他数据，客服使用这些数据来对亚马逊的特定问题进行分类。

如何使用摘要

符号化完成后，Vega Studio会自动在新选项卡中打开摘要。

要诊断崩溃，请按照以下步骤操作：

从元数据开始 - 检查崩溃原因和语言，以了解出现的崩溃类型。
检查符号化堆栈跟踪 - 在堆栈跟踪中查找您的应用代码中的函数名称。
查看系统信息 - 检查崩溃时的使用情况。
与源代码交叉引用 - 使用堆栈跟踪中的文件路径和行号来找出项目中有问题的代码。
确定后续步骤：
- 如果崩溃出现在您的应用代码中，请修复问题并进行测试
- 如果崩溃出现在操作系统代码中，或者您只能看到系统帧，请联系亚马逊支持人员并提供ACR文件
- 如果您不确定，请参阅崩溃来源分析以获取指导说明
- 如果符号化失败或摘要不完整，请参阅修复崩溃分析问题

摘要结构

以下各部分描述了摘要的组成部分，以及每个组成部分包含的信息。

文件头

包含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。

崩溃原因参考

下表列出了您可能在CRASH_REASON字段中看到的崩溃原因、触发终止的原因，以及ACR文件是否包含小转储和堆栈跟踪。

崩溃原因	描述	相关服务	包括迷你转储和堆栈跟踪
`LowCPUKiller`	Resource Manager终止了该应用，以便为更高优先级、CPU密集型进程腾出资源。查看系统信息以获取资源压力数据。	Resource Manager	否
`LowMemoryKiller`	由于内存不足，Resource Manager终止了应用，以便为优先级较高的进程回收内存。查看系统信息以获取内存压力数据。	Resource Manager	否
`LRUDepthMaintenance`	Resource Manager终止了该应用，以使后台应用的数量保持在系统限制范围内。查看系统信息以获取内存压力数据。	Resource Manager	否
`ReclaimMediaResource`	资源管理器终止了应用，以回收应用移至后台时未释放的原生媒体播放资源（例如媒体解码器或视频表面）。有关详细信息，请参阅ReclaimMediaResource crashes。	Resource Manager	否
`AppNotResponding`	Lifecycle Manager因应用无响应 (ANR) 而终止了应用。	Lifecycle Manager	是
Linux信号（例如`SIGABRT`、`SIGSEGV`、`SIGBUS`）	该应用遇到了故障，Linux内核使用相应的信号将其终止。这可能发生在任何进程上，无论它是LCM管理的还是本机运行的。	内核	是

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字段对这些崩溃显示LowMemoryKiller。LowCPUKiller和LRUDepthMaintenance等相关资源管理器终止也缺少堆栈跟踪 - 有关完整列表，请参阅崩溃原因参考。

如果符号化堆栈跟踪部分为空且崩溃原因表示Resource Manager终止：

跳过堆栈跟踪部分。
查看系统信息以获取内存压力数据 - 查看前5个消耗内存最多的进程和压力信息统计数据。
如果您的应用出现在内存消耗量最高的消耗者中，请调查代码中是否可能存在内存泄漏、图像缓冲区过大或缓存过多。

ReclaimMediaResource崩溃

ReclaimMediaResource崩溃原因表示操作系统终止了您的应用，因为它在发送到后台时没有释放原生媒体播放资源（例如媒体解码器或视频表面）。操作系统会为其他应用回收这些资源。

当您的AppState后台处理程序使用async/await对资源清理进行排序时，就会发生这种崩溃。KeplerScript运行时会在后台过渡后暂停JavaScript线程，因此await之后的任何工作都可能永远无法执行。因此导致原生媒体资源没有被发布，操作系统终止了应用。

要修复此问题，请在进行任何异步操作之前在AppState后台处理程序中同步释放原生媒体资源。有关详细信息，请参阅在后台和前台之间转换应用状态。

崩溃来源分析

对于非ANR崩溃，摘要表明崩溃可能源于应用代码还是操作系统代码。工具分析符号化堆栈跟踪以确定崩溃来源：

可能在应用层崩溃： 堆栈跟踪参考应用代码。查看堆栈跟踪了解详细信息。

示例：堆栈跟踪显示MyApp.handleUserInput() 或com.example.myapp.MainActivity.onCreate()
可能在操作系统层崩溃： 工具在堆栈跟踪中未发现与应用相关的框架。请联系亚马逊支持。

示例：堆栈跟踪仅显示__libc_do_syscall() 或binder_call_internal() 的系统调用

系统信息

该部分显示崩溃时记录在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年6月18日