先决条件
- 来自您的Vega应用的崩溃文件 (.acr)。
- 阅读应用崩溃报告符号化，熟悉ACR文件及其数据
了解ACR文件和摘要报告
ACR文件和摘要报告适用于不同的用途，也不是同一个文件。如何使用摘要
符号化完成后，Vega Studio会自动在新选项卡中打开摘要。 要诊断崩溃，请按照以下步骤操作：- 从元数据开始 - 检查崩溃原因和语言，以了解出现的崩溃类型。
- 检查符号化堆栈跟踪 - 在堆栈跟踪中查找您的应用代码中的函数名称。
- 查看系统信息 - 检查崩溃时的使用情况。
- 与源代码交叉引用 - 使用堆栈跟踪中的文件路径和行号来找出项目中有问题的代码。
- 确定后续步骤：
摘要结构
以下各部分描述了摘要的组成部分，以及每个组成部分包含的信息。文件头
包含ACR文件的文件路径和相关临时工作目录的路径。可以使用这些路径来查找原始崩溃文件和中间符号化文件。 示例：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文件是否包含小转储和堆栈跟踪。
OS release file（操作系统发布文件）
包含ACR文件收集的/etc/os-release的内容。此信息可帮助您验证发生崩溃的确切操作系统版本和编译配置，这在重现问题或确定崩溃是否特定于操作系统时非常有用。
Symbolicated stacktraces（符号化堆栈跟踪）
该部分包含解码后的堆栈跟踪，这些堆栈跟踪显示了导致崩溃的函数调用的确切位置和顺序。 崩溃语言决定了该部分中出现的堆栈跟踪：- JavaScript崩溃：只显示JavaScript堆栈跟踪
- 原生崩溃：默认情况下仅显示原生堆栈跟踪
读懂堆栈帧
堆栈跟踪可显示导致崩溃的函数调用顺序。跟踪中的每行都是一个堆栈框架。 原生堆栈帧包括帧号、内存地址和库名称。如果调试符号可用，堆栈帧还会显示函数名称、源文件和行号。了解堆栈跟踪中的??
如果您在原生堆栈帧中看到??，就说明符号化工具无法解析该内存地址处的函数名称。这意味着调试符号不适用于该位置。通过检查相邻堆栈帧的上下文，您可以确定这对应于应用代码还是操作系统级/系统库代码。
??的帧不是应用中的错误。它们代表了在没有导出调试符号的情况下运行的系统代码。请重点关注显示应用的文件路径和函数名称的帧。
要确定崩溃是源于您的代码还是亚马逊的代码，请参阅检测应用崩溃的根源。
低内存杀手 (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文件中的系统信息，包括：- 部分中最消耗内存的5个进程 示例：如果您的应用占用了250MB并出现在前5名，则内存压力可能是相关因素
- 部分中的压力信息统计数据 示例：内存压力值高表明系统可用内存较少。
Native stacktrace - all threads（原生堆栈跟踪 - 所有线程）
该部分显示所有线程的原生堆栈跟踪。您可以通过在交互式GDB会话中运行thread apply all bt来生成此跟踪。
