MediaCodec异常堆栈解析实战 - 第3节

现象识别：堆栈成了“密码本”

崩溃日志中堆栈信息只显示裸内存地址，方法名和行号全部丢失。典型场景有两种：

• Java/Kotlin 层主线程异常：at com.example.app.a.a(Unknown Source) 或 at com.example.app.MainActivity$1.onClick(Unknown Source)
• Native 层崩溃 (signal)：#00 pc 0001a3b4 /lib/armeabi-v7a/libnative.so (BuildId: abc123)，无函数名、无文件行号

如果只靠地址定位，排查时间会陡增 3–5 倍，甚至无法确定是哪个业务模块触发的。

数据采集：必须抓牢的几样“原料”

符号化的前提是拿到正确的配套映射文件。下面表格列出了不同场景下需要采集的数据项：

原因定位：找不到符号的“病根”在哪

使用故障树快速下钻，看属于哪一类问题：

根据故障树锁定具体的缺失项后，进入修复环节。

修复动作：让堆栈“说人话”

Java/Kotlin 混淆堆栈还原

核心工具：retrace.sh (ProGuard) 或 retrace.bat，以及新版 R8 自带的映射工具。

# ProGuard / R8 还原命令（Windows 下用 retrace.bat）
java -jar proguard.jar retrace mapping.txt crash_stack.txt

# Android Studio 内置动作：粘贴堆栈后点击 "Restore obfuscated stacktrace"

关键配置：确保 release 构建中保留 mapping 输出。

// build.gradle.kts（Module:app）
android {
    buildTypes {
        release {
            isMinifyEnabled = true
            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro"
            )
            // R8 默认输出 mapping.txt，无需额外配置
        }
    }
}

Native 堆栈符号化

使用 ndk-stack 或 llvm-symbolizer，需要提供带符号的 .so 或 .debug 文件。

# 方式一：ndk-stack（需传入完整 maps 信息）
ndk-stack -sym path/to/obj/local/armeabi-v7a -dump crash_log.txt

# 方式二：addr2line 直接解析偏移（需知道共享库基址）
arm-linux-androideabi-addr2line -e libnative.so 0x1a3b4

# 方式三：LLVM symbolizer（推荐，支持更多架构）
llvm-symbolizer -obj=libnative.so --print-address --demangle 0x1a3b4

复测：验证符号化是否生效

按以下步骤人工或自动化验证：

1. 重新复现一次相同场景的崩溃（同一操作路径）。
2. 获取新的崩溃日志，确认堆栈中的地址与上一次基本一致。
3. 用修复步骤中的命令重新解析。
4. 检查解析后的堆栈是否包含原始类名、方法名和行号，如 com.example.app.login.LoginActivity.onClick(LoginActivity.java:102) 或 Native 函数名 ANativeWindow::dequeueBuffer。
5. 若仍然只显示地址，回到数据采集环节检查映射文件和基址是否正确。

预防：不给符号“丢失”留机会

从工程流程上杜绝符号映射丢失：