上传符号

错误上报后，stack trace 通常是混淆后的符号，或只包含裸内存地址。上传应用的 mapping 或符号文件后，Measure 会把它们还原为可读的 stack trace。需要哪些文件取决于平台。

Android

如果您使用 ProGuard 或 R8 混淆代码，请在 Dashboard 的应用 Mapping 区域上传 mapping file 以反混淆 stack trace：填写包名和对应 release 的版本，并选择同一次构建生成的文件。Android Gradle 插件只上报构建信息以及 APK/AAB 的大小元数据，不上传 Mapping 或 APK/AAB 文件本体。

如果您的版本首先使用 XmlClassGuard 等工具混淆类名，然后运行 ProGuard/R8，请在 Dashboard 同时上传两份 Mapping。如果 Gradle 任务生成第一阶段文件，也请配置该任务，使其在同一 variant 的构建前执行：

measure {
    variantFilter {
        if (name == "release") {
            classNameMappingTaskName = "xmlClassGuardRelease"
        }
    }
}

class-name Mapping 必须把原始类名映射到传给 ProGuard/R8 的名称；常规 ProGuard/R8 Mapping 会把这些中间名称映射到 APK 中的最终名称。Measure 会按相反顺序反混淆：先处理 ProGuard/R8，再处理类名 Mapping。

设置 classNameMappingTaskName 后，插件只会把该任务接到 variant 的 pre-build 任务之前，以便在构建前运行；插件不会读取或上传该任务生成的 Mapping。该任务必须生成同一 variant 实际使用的 Mapping。如果另一个构建依赖已经保证顺序，可以省略任务名称。classNameMappingFile、mappingUploadEnabled 和 classNameMappingUploadEnabled 只为兼容旧构建脚本保留，插件会忽略它们。

iOS

在 iOS 上，崩溃报告会以裸内存地址的形式返回，直到 dSYM 文件对其进行解码。请根据发布流程选择使用 shell 脚本上传 dSYM，或直接从 XCArchive 上传。

使用 shell 脚本

构建应用后，运行 upload_dsym_manual.sh 手动上传 dSYM 文件。

./upload_dsym_manual.sh <path_to_dsym_folder> <api_url> <api_key> <version_name> <version_code> <app_unique_id> <build_size> [custom_headers]

使用 XCArchive

upload_dsym_xcarchive.sh 脚本会从 .xcarchive 中提取 dSYM 并自动上传。

./upload_dsym_xcarchive.sh <path_to_xcarchive> <api_url> <api_key> [custom_headers] [ipa_path]