作者：路锦(小蘭)

01 背景：为什么需要崩溃采集？

系列回顾：在上一篇文章《深度解析 Android 崩溃捕获原理及从崩溃到归因的闭环实践》中，我们深入剖析了崩溃采集的技术内幕——从 Java 层的 UncaughtExceptionHandler 机制，到 Native 层的信号处理与 Minidump 技术，再到混淆堆栈的符号化原理。相信大家对“崩溃是如何被捕获的”已经有了清晰的认识。

然而，光有理论还不够。本文将通过复现生产环境案例，当一名 Android 开发同学遇到的线上崩溃问题，该如何通过 RUM 采集的异常数据与上下文进行崩溃的分析与定位，带你完整体验崩溃排查的全流程：从收到告警、查看控制台、分析堆栈、追踪用户行为，到定位根因。

1.1 案例背景

某 App 发布了 v3.5.0 版本，主要优化了商品列表的加载性能。然而，版本上线后的第 3 天，团队开始收到大量用户投诉 App 闪退和崩溃。

问题严重性：

崩溃率增长 10+ 倍
应用商店评分下降
用户卸载率上升

最终解决方案：集成了阿里云 RUM SDK，通过完整的崩溃数据采集，在 2 小时内完成了问题定位。

02 完整排查流程：从告警到根因定位

2.1 🔔 第一步：收到崩溃告警

数据接入后，由于配置了告警，在线上崩溃率大幅上升时，团队研发同学会收到告警通知，第一时间关注线上问题。

告警语句参考：

app.name: xxx and crash | SELECT diff[1] AS "当前值", diff[2] AS "昨日值", round(diff[3], 4) AS "比值" FROM (SELECT compare(cnt, 86400) AS diff FROM ( SELECT COUNT(*) AS cnt FROM log)) ORDER BY "当前值" DESC

2.2 📊 第二步：查看崩溃概览 - 锁定异常类型

操作路径：控制台首页 → 用户体验监控 → 找到对应的 App 应用 → 异常统计。

原图链接：https://img.alicdn.com/imgextra/i4/O1CN01sTmbeh1HuEhF4SKRy_!!6000000000817-2-tps-4684-1262.png

通过分析控制台展示的异常统计列表，我们发现 IndexOutOfBoundsException 占据了绝大多数的崩溃，是绝对的主要问题，并且开始大量出现则是 v3.5.0 版本发布之后。

2.3 🔍 第三步：分析崩溃堆栈 - 初步定位

点击进入 IndexOutOfBoundsException 详情页，深入分析，验证了我们的想法，这里可以定位到崩溃版本就是新发布的 v3.5.0，发生的页面为：ProductListActivity。对应的会话 ID 是：98e9ce65-c51a-40c4-9232-4b69849e5985-01，这个信息用于我们后续分析用户行为。

查看崩溃堆栈，分析关键信息：

崩溃发生在 ProductListAdapter.onBindViewHolder() 方法的第 50 行
错误原因：尝试访问列表的第 6 个元素（index 5），但列表实际只有 5 个元素
这是一个典型的 RecyclerView 数据不一致问题

初步假设：

可能是数据更新时机不对
可能是多线程并发修改数据
可能是用户快速操作导致

但仅凭堆栈还无法确定根因，需要查看用户的具体操作路径。

2.4 🎯 第四步：追踪用户行为 - 找到触发路径

操作路径：崩溃详情页 → 选择崩溃对应的会话 ID → 查看该会话 ID 的会话追踪。

点开会话详情，我们查看用户的行为路径，结合崩溃发生的页面。我们整理出这样的一个操作路径。

操作路径：

用户进入 ProductListActivity 页面
快速连续点击刷新按钮 3 次，触发列表异步更新（注：这里实际发生网络请求，由于我们是本地复现，使用异步更新）
线上请求时序问题：

第一次异步请求返回 n 个商品，用户滚动到 6 个
后续请求只返回 5 个商品，更新了列表数据

RecyclerView 还在渲染第 6 个位置，然而数据已经不存在了
根本原因：多次异步请求，导致数据竞态

2.5 🌐 第五步：多维度分析 - 验证假设

为了进一步确认问题，可以对崩溃数据进行多维度筛选分析，分析故障特征、确认影响面。

2.5.1 崩溃数据结构

SDK 采集的崩溃数据包含以下核心字段：

{
  "session.id": "session_abc123",         // 会话ID，用于关联用户行为路径
  "timestamp": 1699884000000,             // 崩溃发生时间（毫秒时间戳）
  "exception.type": "crash",              // 异常类型
  "exception.subtype": "java",            // 异常子类型
  "exception.name": "java.lang.NullPointerException",  // 异常类型
  "exception.message": "Attempt to invoke virtual method on a null object",  // 异常信息
  "exception.stack": "[{...}]",          // 完整堆栈（JSON数组）
  "exception.thread_id": 1,              // 崩溃线程ID
  "view.id": "123-abc",                    // 崩溃发生页面ID
  "view.name": "NativeCrashActivity",      // 崩溃发生页面名称
  "user.tags:": "{\"vip\":\"true\"}",      // 用户标签（自定义）
  "properties": "{\"version\":\"2.1.0\"}", // 自定义属性
  "net.type": "WIFI",                      // 用户网络类型
  "net.ip": "192.168.1.100",               // 用户客户端IP地址
  "device.id": "123-1234",                // 用户设备ID
  "os.version": 14,                       // 用户系统版本号
  "os.type": "Android"                    // 用户系统类型
}

2.5.2 崩溃大盘总览

位置：用户体验监控->体验看板->异常分析。

异常分析大盘中可以整体看应用的崩溃总览，包括异常总数、异常趋势、设备分布、异常类型、联网分布等其他聚合分析结果。

2.5.3 网络类型分布

由于实际列表更新操作是由网络请求返回的，因此我们需要关注线上数据发生崩溃时，用户的联网类型，在崩溃大盘中查看 v3.5.0 版本的崩溃联网分布。

💡 结论：90% 的崩溃发生在 3G/4G 网络下，WiFi 网络下崩溃率很低。这印证了网络（异步请求）是关键因素。

2.5.4 设备品牌分布

在崩溃大盘中查看 v3.5.0 版本崩溃的设备品牌分布。

💡 结论：所有品牌都受影响，不是特定机型的问题，而是代码逻辑问题。

2.5.5 版本对比

除了崩溃大盘，我们仍然可以在日志探索 tab 页使用 SQL 自定义分析。

查询语句：

app.name: xxx and crash | select "app.version", count(*) from log group by "app.version"

操作：对比 v3.4.0 和 v3.5.0 的崩溃率。

版本	崩溃率	IndexOutOfBoundsException 占比
v3.4.0	0.08%	5%
v3.5.0	1.25%	82.5%

💡结论：问题是 v3.5.0 版本引入的，需要查看这个版本的改动。

2.6 💻 第六步：定位代码问题

查看问题代码

打开 ProductListActivity.java，找到刷新逻辑：

private void loadProducts() {
    // ❌ v3.5.0 的改动：使用异步加载优化性能
    new Thread(() -> {
        try {
            // 模拟网络请求
            List<Product> newProducts = ApiClient.getProducts(currentCategory);
            // ❌ 问题 1：没有取消前一个请求
            // ❌ 问题 2：直接清空并更新数据，没有考虑 RecyclerView 正在渲染
            runOnUiThread(() -> {
                productList.clear();              // 💥 危险操作！
                productList.addAll(newProducts);  // 💥 数据更新
                adapter.notifyDataSetChanged();   // 💥 通知刷新
            });
        } catch (Exception e) {
            e.printStackTrace();
        }
    }).start();
}

@Override
public void onBindViewHolder(@NonNull ProductViewHolder holder, int position) {
    // 💥 崩溃点：position 可能超出 products 的范围
    Product product = products.get(position); //IndexOutOfBoundsException!
    holder.bind(product);
}

找到问题根因！

v3.5.0 的改动目的：优化性能，将网络请求放到子线程。

引入的问题：

1. 没有取消前一个请求：用户快速点击刷新时，多个请求同时进行

2. 数据竞态：后一个请求返回时，直接清空并更新数据

3. UI 状态不一致：RecyclerView 正在渲染某个位置，但数据已经变少了

03 符号化配置：让堆栈“说人话”

通过前面的排查流程，我们成功定位到了崩溃的根本原因：ProductListAdapter.onBindViewHolder()。

方法在处理数据更新时，存在索引越界问题。但你可能会有一个疑问：我们是如何从混淆后的堆栈中，精确定位到 ProductListAdapter.java:50 这一行代码的？

在真实的生产环境中，为了保护代码和优化包体积，发布到应用商店的 Release 版本都会经过 ProGuard 或 R8 混淆。这意味着控制台最初看到的崩溃堆栈是这样的。

java.lang.IndexOutOfBoundsException: Index: 5, Size: 5
    at java.util.ArrayList.get(ArrayList.java:437)
    at com.shop.a.b.c.d.a(Proguard:58)

这就是我们需要符号化的原因。接下来，让我们看看如何在 RUM 控制台配置符号化。

3.1 Java/Kotlin 混淆符号化

Step 1：保留 mapping.txt 文件

构建 Release 版本后，mapping.txt 文件位于：

app/build/outputs/mapping/release/mapping.txt

文件内容示例：

com.example.ui.MainActivity -> a.b.c.MainActivity:
    void updateUserProfile(com.example.model.User) -> a
    void onClick(android.view.View) -> b
com.example.model.User -> a.b.d.User:
    java.lang.String userName -> a
    void setUserName(java.lang.String) -> a

Step 2：上传 mapping 文件到控制台

1. 登录云监控 2.0 控制台

2. 进入用户体验监控（RUM）->进入您接入的应用->应用设置->文件管理

3. 点击符号表文件->上传文件

4. 上传 mapping.txt 文件

3.2 Native 符号化

构建完成后的目录中 .so 文件位于：

app/build/intermediates/cxx/release/xxx/obj/
  ├── arm64-v8a/
  │   └── xxx-native.so      ← 包含调试符号
  ├── armeabi-v7a/
  │   └── xxx-native.so
  └── x86_64/
      └── xxx-native.so

Step 3：上传到控制台

与 Java mapping 文件类似，在控制台上传对应架构的 .so 文件。

3.3 验证符号化

使用符号表文件解析：打开崩溃详情->异常明细->解析堆栈->选择对应的符号表文件（native 堆栈使用 .so 文件，java 堆栈使用 .txt 文件。）

点击确定后即可展示解析后的堆栈。

符号化成功：

显示完整的类名、方法名
显示源文件路径和行号
C++ 函数名已还原（非 mangled 状态）

04 案例总结：RUM 的关键价值

在这次崩溃排查中，RUM 提供了哪些关键帮助？

1. 完整的堆栈信息 + 符号化

没有 RUM：线上应用只能看到混淆后的堆栈，完全不知道是哪里崩溃
有了 RUM：上传 mapping 文件后，精确定位到 ProductListAdapter.java:50

2. 用户行为路径追踪

没有 RUM：只知道“用户打开列表就崩溃”，无法复现
有了 RUM：看到完整的操作时间线，发现是“快速点击刷新多次”触发

3. 多维度数据分析

没有 RUM：不知道是哪些用户、什么环境下崩溃
有了 RUM：

发现 90% 崩溃在 3、4G 网络下（网络延迟是关键）
所有机型都受影响（排除硬件问题）
v3.5.0 才开始出现（锁定版本改动）

4. 实时告警 + 量化影响

没有 RUM：依赖用户投诉，发现滞后
有了 RUM：第一时间收到告警，立即开始问题排查

应用的稳定性是用户体验的基石。通过系统化的崩溃采集与分析，开发团队能够从“被动响应”转变为“主动预防”，持续提升应用质量，赢得用户信任。阿里云 RUM 针对 Android 端实现了对应用性能、稳定性、和用户行为的无侵入式采集 SDK，可以参考接入文档^[^1]体验使用。除了 Android 外，RUM 也支持 Web、小程序、iOS、鸿蒙等多种平台监控分析，相关问题可以加入“RUM 用户体验监控支持群”（钉钉群号：67370002064）进行咨询。

相关链接：

[1] 接入文档

https://help.aliyun.com/zh/arms/user-experience-monitoring/access-to-android-applications

Android 崩溃监控实战：一次完整的生产环境崩溃排查全流程