3. 数据采集工具选型：Android Studio Memory Profiler、MAT、LeakCanary、Perfetto、自定义Dump

DataStore 实例持有泄漏的排查进入数据采集阶段。采集什么数据、用什么工具采集，直接决定了后续原因定位的效率和准确性。本章围绕 5 种常用工具给出选型原则与采集策略，配合故障树与比对表格，帮助你在不同场景下快速找到最合适的采集武器。

3.1 现象识别——什么症状提示需要数据采集

出现以下 任意一条 现象时，应立即启动数据采集流程：

• 内存持续增长：Profiler 显示 Java 堆在使用 DataStore 后稳步上升，GC 无法回收。
• GC 频率异常：logcat 中连续出现 GC_CONCURRENT 或 GC_FOR_ALLOC，且 GC 后堆内存降幅 < 10%。
• 引用链持有：LeakCanary 通知提示 DataStore 实例被某个长生命周期对象（如 Application、Activity）持有。
• OOM 崩溃：极少数情况会出现 OutOfMemoryError，且堆栈指向 DataStore 内部的 FileChannel 或 MutableStateFlow。

3.2 数据采集——5 种工具的核心用途与选型判断

每种工具擅长回答不同问题，判断规则如下：

3.3 工具选型流程（SVG）

3.4 各工具采集实操要点

3.4.1 LeakCanary（推荐首选）

集成后自动监听 Activity/Fragment 生命周期，发现泄漏时自动生成 hprof 并解析引用链。配置只需一行：

// build.gradle.kts
debugImplementation("com.squareup.leakcanary:leakcanary-android:2.14")

采集后关注对象：DataStore、FileChannel、StateFlowImpl 是否被长生命周期的 Context 或 ViewModel 持有。

3.4.2 Android Studio Memory Profiler

适用于手动复现步骤。操作流程：

1. 运行应用，点击 Profiler 图标 → Memory 标签。
2. 执行可能触发泄漏的操作（如反复打开/关闭含 DataStore 的页面）。
3. 点击“Dump Java heap”生成 hprof。
4. 在 Profiler 中直接搜索 DataStore 类名，查看其引用路径。

3.4.3 MAT

适合对比两个时间的 Dump 文件。用 MAT 打开 hprof 后，主要操作：

• 打开 Histogram → 过滤 DataStore → 查看实例数量。
• 右键实例 → Merge Shortest Paths to GC Roots → 排除弱引用 → 找到强引用链。
• 使用 Compare Two Heap Dumps 功能（需要 HPROF 格式一致）。

3.4.4 Perfetto

当怀疑泄漏与异步协程的时序有关时（例如 DataStore 在协程作用域结束后仍未被释放），用 Perfetto 的 Record 功能选择 memory 和 android_heapprofd，持续 30s 以捕获分配事件。

# 使用 perfetto 命令行抓取 10s heap dump
adb shell perfetto -o /data/misc/perfetto-traces/trace.perfetto \
  -c - <<< '{
    "duration_ms": 10000,
    "buffers": [{"size_kb": 204800}],
    "data_sources": [
      {"config": {"name": "android.heapprofd", "target": {"pid": 12345}}}
    ]
  }'

3.4.5 自定义 Dump

在关键业务点（如用户登出后、数据库关闭后）精确触发：

// 在 Activity 或 ViewModel 中
fun captureDumpIfLeakSuspected() {
    if (ApplicationDataStoreHolder.hasReference()) {
        Debug.dumpHprofData(
            "${context.cacheDir}/leak_${System.currentTimeMillis()}.hprof"
        )
    }
}

3.5 原因定位通用规则（基于采集数据）

无论使用哪种工具，定位 DataStore 泄漏的通用步骤：

1. 统计 DataStore 实例数量（正常应为 1）。
2. 查看其引用链中是否有 Application、Activity、Fragment、ViewModel 等长生命周期对象。
3. 检查 FileChannel 或 MessageDispatcher 是否被 WorkManager 或 CoroutineScope 持有的回调所引用。
4. 若引用链中出现 kotlinx.coroutines.Job，检查该 Job 是否被取消。

典型泄漏路径（故障树示意）：

DataStore 不被释放
├─ 被 Application 静态引用（最常见）
│   └─ 通过依赖注入（Dagger/Hilt）单例绑定为 Application 成员
├─ 被 ViewModel 持有但 ViewModel 未被清除
│   └─ ViewModel 的作用域绑定到了 Activity 而非 Application
├─ 被协程 Job 持有（协程泄漏）
│   └─ CoroutineScope 未在 onDestroy 中取消
└─ 被 FileChannel 的内部线程引用
    └─ 用户手动调用 DataStore 的 updateData 后未关闭 Session

3.6 修复动作（示例）

以最常见的“Application 静态引用”为例：

// 错误：在 Application 中创建 DataStore 并暴露为静态变量
object AppDataStoreProvider {
    lateinit var dataStore: DataStore<Preferences>
}

// 正确：使用依赖注入管理生命周期，确保可被 GC
@Module
object DataStoreModule {
    @Provides
    @Singleton
    fun provideDataStore(@ApplicationContext context: Context): DataStore<Preferences> {
        return PreferenceDataStoreFactory.create {
            context.dataStoreFile("user_prefs.proto")
        }
    }
}

若泄漏来自协程，在 ViewModel 的 onCleared() 或 Activity 的 onDestroy() 中取消 scope：

private val scope = CoroutineScope(Dispatchers.IO + SupervisorJob())

fun onDestroy() {
    scope.cancel()
}

3.7 复测与验证

• 使用相同工具再次触发数据采集，观察 DataStore 实例数是否降为 1。
• 运行 adb shell dumpsys meminfo <package> 确认堆大小回归正常。
• 执行压力测试（快速进出页面 20 次），观察 GC 后堆曲线是否平坦。

3.8 预防措施

• DataStore 实例应使用 @Singleton 作用域，确保全局只有一个实例。
• 避免在 Application.onCreate() 之外手动创建 DataStore（除非有特殊分层需求）。
• 协程中操作 DataStore 时，确保使用 viewModelScope 或 lifecycleScope 自动取消。
• 在 CI 中集成 LeakCanary 日志检查，将泄漏报警视为构建失败。