> ## Documentation Index
> Fetch the complete documentation index at: https://test-8ad8522e-feat-ai-sre.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Android SDK 性能影响

> 了解 Flashduty Android RUM SDK 对应用 CPU、内存、启动时间、APK 大小和网络使用的影响，以及性能优化建议。

## 概述

在将任何 SDK 集成到 Android 应用时，了解其性能影响对于维护良好的用户体验至关重要。Flashduty RUM SDK 在设计时充分考虑了性能因素，并提供透明的测量数据，帮助您做出明智的集成决策。

<Check>
  SDK 采用异步处理和批量上报机制，避免阻塞主线程，确保不影响应用的 UI 响应性能。
</Check>

## 性能基准测试

为了评估 SDK 对应用性能的实际影响，我们在典型使用场景下进行了性能基准测试。测试中启用了以下 SDK 功能模块：

* `dd-sdk-android-rum`：RUM 核心功能
* `dd-sdk-android-trace`：链路追踪
* `dd-sdk-android-okhttp`：网络请求追踪

SDK 使用默认配置进行初始化，并模拟常见用户操作（如页面浏览、滚动列表、网络请求等）。

### 测试结果

| 指标         | 集成 SDK 后                       | 未集成 SDK  | 影响                      |
| ---------- | ------------------------------ | -------- | ----------------------- |
| 峰值 CPU 使用率 | \~27%                          | \~25%    | +2%                     |
| 峰值内存使用     | \~435 MB                       | \~437 MB | 基本持平                    |
| 应用启动时间     | \~245 ms                       | \~230 ms | +15 ms                  |
| APK 大小     | 基础 RUM 约 +410 KB；全量模块约 +3.6 MB | -        | 取决于接入模块、R8 配置和 ABI 打包方式 |
| 网络使用       | \~70 KB 发送 / \~20 KB 接收        | -        | 根据事件量变化                 |

<Note>
  以上数据为典型场景下的参考值，实际影响会因应用复杂度、设备性能和 SDK 配置不同而有所差异。
</Note>

### 性能影响详解

<AccordionGroup>
  <Accordion title="CPU 使用率" icon="microchip">
    SDK 对 CPU 的影响主要来自：

    * 事件收集和处理
    * 数据批处理和压缩
    * 网络请求上报

    SDK 采用异步处理和批量上报机制，避免阻塞主线程，确保不影响应用的 UI 响应性能。
  </Accordion>

  <Accordion title="内存使用" icon="memory">
    SDK 使用固定大小的内存缓冲区存储待上报的事件数据，不会随时间无限增长。过旧的数据会被自动清理，确保不会占用过多内存。
  </Accordion>

  <Accordion title="启动时间" icon="rocket">
    SDK 初始化过程经过优化，启动时间影响控制在毫秒级。

    <Tip>
      建议在 `Application.onCreate()` 中尽早初始化 SDK，以便捕获完整的应用启动过程。
    </Tip>
  </Accordion>

  <Accordion title="APK 大小" icon="box">
    SDK 采用模块化设计，您可以根据需要只引入必要的功能模块：

    | 模块                       | 说明          |
    | ------------------------ | ----------- |
    | `dd-sdk-android-rum`     | RUM 核心功能    |
    | `dd-sdk-android-trace`   | 链路追踪        |
    | `dd-sdk-android-okhttp`  | OkHttp 网络追踪 |
    | `dd-sdk-android-webview` | WebView 追踪  |

    只引入必要的模块可以最小化对 APK 大小的影响。

    实验室测量数据如下，供评估接入成本时参考：

    | 接入口径                                                    | 构建类型                             | APK 增量   | 说明                              |
    | ------------------------------------------------------- | -------------------------------- | -------- | ------------------------------- |
    | `dd-sdk-android-core` + `dd-sdk-android-rum`            | Release，开启 R8 / minify           | 约 410 KB | 基础 RUM 接入口径                     |
    | `dd-sdk-android-core` + `dd-sdk-android-rum`            | Debug                            | 约 1.3 MB | Debug 包未经过 R8 裁剪，增量更大           |
    | `core` + `rum` + `trace` + `webview` + `okhttp` + `ndk` | Release，开启 R8 / minify，多 ABI APK | 约 3.6 MB | 主要增量来自 NDK 模块携带的多 ABI native so |
    | `core` + `rum` + `trace` + `webview` + `okhttp` + `ndk` | Debug，多 ABI APK                  | 约 4.6 MB | 当前 Android demo 的全量接入口径         |

    <Note>
      以上包体积数据基于 Flashduty Android SDK 0.4.0 和 Android demo 测得，统计口径为 APK 文件大小增量。实际结果会受原 App 已有依赖、R8 裁剪规则、是否使用 App Bundle / ABI split、以及是否接入 Trace、WebView、OkHttp、NDK 等模块影响。
    </Note>
  </Accordion>

  <Accordion title="网络使用" icon="wifi">
    SDK 采用以下策略优化网络使用：

    * **批量上报**：事件先缓存到本地，批量发送以减少网络请求次数
    * **数据压缩**：上报数据经过压缩处理，减少传输流量
    * **智能调度**：根据网络状态和电量情况智能调度上报时机
  </Accordion>
</AccordionGroup>

## 性能优化建议

如果您对性能有特殊要求，可以考虑以下优化措施：

<Steps>
  <Step title="调整采样率">
    通过配置采样率减少收集的事件数量：

    ```kotlin theme={null}
    val rumConfig = RumConfiguration.Builder(applicationId)
        .setSessionSampleRate(80f) // 采样 80% 的会话
        .build()
    ```
  </Step>

  <Step title="按需启用功能">
    只启用必要的追踪功能：

    ```kotlin theme={null}
    val rumConfig = RumConfiguration.Builder(applicationId)
        .disableUserInteractionTracking()                     // 关闭 tap/scroll/swipe 自动采集
        .trackLongTasks(0)                                    // 阈值 ≤ 0 即关闭长任务追踪（默认 100 毫秒）
        .trackFrustrations(false)                             // 关闭挫折信号分析（默认开启）
        .setVitalsUpdateFrequency(VitalsUpdateFrequency.RARE) // 降低 vitals 采集频率（默认 AVERAGE 每 500 毫秒，NEVER 为完全关闭）
        .setTelemetrySampleRate(0f)                           // 关闭 SDK 内部遥测（默认 20%）
        .build()
    ```

    <Warning>
      这一步是拿数据维度换负载，请按实际分析需求取舍。关闭交互追踪后，自动 action 事件清零，依赖 action 的挫折信号（rage/dead/error tap）一并消失；view、resource、error、长任务事件不受影响，手动 `RumMonitor.addAction` 打点也不受影响。action 是异常定位和交互分析的重要上下文，建议仅在负载敏感场景关闭。

      `setTelemetrySampleRate(0f)` 关闭的是 SDK 自身的运行遥测，不影响任何 RUM 业务数据，可以放心设置。

      **`trackLongTasks(0)` 的代价比字面意思大。** 冻结帧并不是从渲染帧里统计出来的，而是「耗时超过 700ms 的长任务」这一子集，卡顿频率又由冻结帧数算得。所以关闭长任务采集后，看板「流畅度分析」里的**长任务数、冻结帧数、卡顿频率会同时恒为 0**——看起来像「应用毫无卡顿」，实际是没采集。慢帧占比走独立链路，不受影响。

      如果你的目的是减少事件量，**建议调高阈值而不是关闭**：`trackLongTasks(500)` 能保留全部冻结帧（判据是 700ms，高于 500ms），同时把长任务事件量比默认 100ms 降低一个量级。但请注意，阈值只决定「上报什么」，不减少插桩本身的开销——监听器挂在主线程 Looper 上，每条消息都会回调。**若你是为了降低运行时开销**，那只有 `trackLongTasks(0)` 有效，此时请接受上述三个指标不可用。
    </Warning>
  </Step>

  <Step title="配置上传节奏">
    调整上传周期、批次时长和单周期批次上限，降低 SDK 上传与业务请求争抢网络的概率，且不损失任何事件。详见下一节。
  </Step>
</Steps>

## 降低上传对业务请求的影响

如果应用自身有延迟敏感的网络请求（如登录、下单、密钥申请），并且运行在上行带宽较窄的网络上，SDK 的上传可能与业务请求争抢上行链路，表现为业务请求耗时的长尾（P95）升高，且时好时坏。

这种情况下调整以下三个 Core 参数，改变的是上传的时间分布——上传次数更少、单次更分散：

```kotlin theme={null}
val coreConfig = Configuration.Builder(clientToken, env, variant)
    .setUploadFrequency(UploadFrequency.RARE)          // 上传周期间隔：默认 AVERAGE 2 秒 → RARE 5 秒
    .setBatchSize(BatchSize.LARGE)                     // 批次收集时长：默认 MEDIUM 10 秒 → LARGE 35 秒
    .setBatchProcessingLevel(BatchProcessingLevel.LOW) // 单周期连发批次上限：默认 MEDIUM 20 → LOW 1
    .build()
```

| 参数                        | 默认值             | 建议值           | 作用                                      |
| ------------------------- | --------------- | ------------- | --------------------------------------- |
| `setUploadFrequency`      | `AVERAGE`（2 秒）  | `RARE`（5 秒）   | 拉长上传周期的间隔，降低与业务请求撞车的概率                  |
| `setBatchSize`            | `MEDIUM`（10 秒）  | `LARGE`（35 秒） | 批次收集更久、请求次数更少；批次越大 gzip 压缩率越好，上行字节数还会略降 |
| `setBatchProcessingLevel` | `MEDIUM`（20 批次） | `LOW`（1 批次）   | 限制一个上传周期最多连续发送的批次数，避免积压时一次性占满上行         |

<Tip>
  这三个参数只改变上传时机，不减少任何事件，也不影响看板上的任何数据维度——如果不希望牺牲数据，只调它们即可。
</Tip>

<Note>
  这三个参数在 Android、iOS、HarmonyOS、Flutter SDK 中同名同值，调优结论可以跨平台直接套用。唯一差异是 iOS 的 `batchProcessingLevel = .low` 为 5 批次/周期，Android 与 HarmonyOS 为 1，方向一致、降幅略小。
</Note>

如果事件量本身偏大，还可以用 EventMapper 丢弃指定的噪音事件（映射函数返回 `null` 即丢弃），侵入性小于改业务打点代码，用法见 [高级配置](/zh/rum/sdk/android/advanced-config)。

## 离线数据存储

SDK 在设备离线时会将数据存储到本地，存储空间使用受到严格限制：

<Check>
  * 使用固定大小的磁盘缓存
  * 过期数据自动清理
  * 不会因缓存数据过多影响设备存储空间
</Check>

## 相关文档

<CardGroup cols={2}>
  <Card title="SDK 接入指南" icon="plug" href="/zh/rum/sdk/android/sdk-integration">
    了解如何接入 SDK
  </Card>

  <Card title="高级配置" icon="sliders" href="/zh/rum/sdk/android/advanced-config">
    了解如何配置 SDK 的高级功能
  </Card>

  <Card title="数据收集" icon="database" href="/zh/rum/sdk/android/data-collection">
    了解 SDK 收集的数据类型
  </Card>
</CardGroup>