> ## 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 Performance Impact

> Learn about the performance impact of the Flashcat Android RUM SDK on CPU, memory, launch time, APK size, and network usage, along with optimization recommendations.

## Overview

When integrating any SDK into an Android application, understanding its performance impact is crucial for maintaining a good user experience. The Flashcat RUM SDK is designed with performance in mind and provides transparent measurement data to help you make informed integration decisions.

<Check>
  The SDK uses asynchronous processing and batch reporting mechanisms to avoid blocking the main thread, ensuring it does not affect the application's UI responsiveness.
</Check>

## Performance Benchmark

To evaluate the actual performance impact of the SDK on your application, we conducted performance benchmarks under typical usage scenarios. The following SDK modules were enabled during testing:

* `dd-sdk-android-rum`: RUM core functionality
* `dd-sdk-android-trace`: Distributed tracing
* `dd-sdk-android-okhttp`: Network request tracking

The SDK was initialized with default configuration and simulated common user operations (such as page views, scrolling lists, network requests, etc.).

### Test Results

| Metric            | With SDK                                          | Without SDK | Impact                                                          |
| ----------------- | ------------------------------------------------- | ----------- | --------------------------------------------------------------- |
| Peak CPU Usage    | \~27%                                             | \~25%       | +2%                                                             |
| Peak Memory Usage | \~435 MB                                          | \~437 MB    | Negligible                                                      |
| App Launch Time   | \~245 ms                                          | \~230 ms    | +15 ms                                                          |
| APK Size          | \~+410 KB for base RUM; \~+3.6 MB for all modules | -           | Depends on enabled modules, R8 configuration, and ABI packaging |
| Network Usage     | \~70 KB sent / \~20 KB received                   | -           | Varies with event volume                                        |

<Note>
  The above data are reference values under typical scenarios; actual impact may vary depending on application complexity, device performance, and SDK configuration.
</Note>

### Performance Impact Details

<AccordionGroup>
  <Accordion title="CPU Usage" icon="microchip">
    The SDK's CPU impact primarily comes from:

    * Event collection and processing
    * Data batching and compression
    * Network request reporting

    The SDK uses asynchronous processing and batch reporting mechanisms to avoid blocking the main thread, ensuring it does not affect the application's UI responsiveness.
  </Accordion>

  <Accordion title="Memory Usage" icon="memory">
    The SDK uses a fixed-size memory buffer to store pending event data, which does not grow indefinitely over time. Stale data is automatically cleaned up to ensure it does not consume excessive memory.
  </Accordion>

  <Accordion title="Launch Time" icon="rocket">
    The SDK initialization process is optimized, with launch time impact controlled to milliseconds.

    <Tip>
      It is recommended to initialize the SDK as early as possible in `Application.onCreate()` to capture the complete application startup process.
    </Tip>
  </Accordion>

  <Accordion title="APK Size" icon="box">
    The SDK uses a modular design, allowing you to include only the necessary functional modules:

    | Module                   | Description             |
    | ------------------------ | ----------------------- |
    | `dd-sdk-android-rum`     | RUM core functionality  |
    | `dd-sdk-android-trace`   | Distributed tracing     |
    | `dd-sdk-android-okhttp`  | OkHttp network tracking |
    | `dd-sdk-android-webview` | WebView tracking        |

    Including only the necessary modules can minimize the impact on APK size.

    The following lab measurements can be used as reference data when estimating integration cost:

    | Integration scope                                       | Build type                                      | APK increase | Notes                                                                               |
    | ------------------------------------------------------- | ----------------------------------------------- | ------------ | ----------------------------------------------------------------------------------- |
    | `dd-sdk-android-core` + `dd-sdk-android-rum`            | Release with R8 / minify enabled                | \~410 KB     | Base RUM integration scope                                                          |
    | `dd-sdk-android-core` + `dd-sdk-android-rum`            | Debug                                           | \~1.3 MB     | Debug builds are not reduced by R8, so the increase is larger                       |
    | `core` + `rum` + `trace` + `webview` + `okhttp` + `ndk` | Release with R8 / minify enabled, multi-ABI APK | \~3.6 MB     | Most of the increase comes from multi-ABI native shared libraries in the NDK module |
    | `core` + `rum` + `trace` + `webview` + `okhttp` + `ndk` | Debug, multi-ABI APK                            | \~4.6 MB     | Full integration scope used by the current Android demo                             |

    <Note>
      The APK size data above was measured with Flashduty Android SDK 0.4.0 and the Android demo. The measurement scope is APK file size increase. Actual results vary depending on dependencies already present in the host app, R8 keep rules, App Bundle / ABI split usage, and whether Trace, WebView, OkHttp, or NDK modules are enabled.
    </Note>
  </Accordion>

  <Accordion title="Network Usage" icon="wifi">
    The SDK employs the following strategies to optimize network usage:

    * **Batch reporting**: Events are cached locally first and sent in batches to reduce the number of network requests
    * **Data compression**: Reported data is compressed to reduce transmission traffic
    * **Intelligent scheduling**: Upload timing is intelligently scheduled based on network status and battery level
  </Accordion>
</AccordionGroup>

## Performance Optimization Recommendations

If you have specific performance requirements, consider the following measures:

<Steps>
  <Step title="Adjust the sample rate">
    Reduce the number of collected events by configuring the sample rate:

    ```kotlin theme={null}
    val rumConfig = RumConfiguration.Builder(applicationId)
        .setSessionSampleRate(80f) // sample 80% of sessions
        .build()
    ```
  </Step>

  <Step title="Enable only the features you need">
    Turn off the automatic tracking you do not analyze:

    ```kotlin theme={null}
    val rumConfig = RumConfiguration.Builder(applicationId)
        .disableUserInteractionTracking()                     // stop auto-collecting tap/scroll/swipe
        .trackLongTasks(0)                                    // a threshold <= 0 disables long task tracking (default 100 ms)
        .trackFrustrations(false)                             // disable frustration signals (enabled by default)
        .setVitalsUpdateFrequency(VitalsUpdateFrequency.RARE) // collect vitals less often (default AVERAGE, every 500 ms; NEVER turns it off)
        .setTelemetrySampleRate(0f)                           // disable the SDK's internal telemetry (default 20%)
        .build()
    ```

    <Warning>
      This step trades data coverage for load, so weigh each option against what you actually analyze. Disabling interaction tracking drops automatic action events to zero, and the frustration signals that depend on them (rage/dead/error tap) disappear with them. View, resource, error and long task events are unaffected, and manual `RumMonitor.addAction` instrumentation still works. Action events are important context for diagnosing errors, so turn them off only in load-sensitive scenarios.

      `setTelemetrySampleRate(0f)` disables the SDK's own operational telemetry. It does not affect any RUM data, so you can set it safely.

      **`trackLongTasks(0)` costs more than its name suggests.** Frozen frames are not counted from rendered frames — they are the subset of long tasks running past 700ms — and Freeze Frequency is derived from the frozen-frame count. Disabling long-task collection therefore drives **Long Tasks, Frozen Frames and Freeze Frequency all to 0 at once** in the dashboard's Smoothness Analysis table, which reads as "no jank at all" when it really means "not measured". Slow Frame Share travels a separate path and is unaffected.

      If your goal is to reduce event volume, **raise the threshold rather than disabling it**: `trackLongTasks(500)` keeps every frozen frame (the 700ms criterion sits above 500ms) while cutting long-task event volume by an order of magnitude versus the 100ms default. Note that the threshold only decides *what gets reported* — it does not reduce the instrumentation overhead itself, since the listener sits on the main thread's Looper and is called for every message. **If your goal is to cut runtime overhead**, only `trackLongTasks(0)` achieves that, and you should accept that the three metrics above become unavailable.
    </Warning>
  </Step>

  <Step title="Tune the upload cadence">
    Adjust the upload interval, batch window and per-cycle batch limit to reduce contention between SDK uploads and your own requests, without losing any events. See the next section.
  </Step>
</Steps>

## Reducing the Impact of Uploads on Your Own Requests

If your app makes latency-sensitive requests of its own (sign-in, checkout, key provisioning) over a narrow uplink, SDK uploads can compete with them for the uplink. The symptom is a higher tail (P95) on your own request latency that comes and goes.

Three core settings change how uploads are distributed over time — fewer uploads, spread further apart:

```kotlin theme={null}
val coreConfig = Configuration.Builder(clientToken, env, variant)
    .setUploadFrequency(UploadFrequency.RARE)          // upload interval: default AVERAGE 2 s -> RARE 5 s
    .setBatchSize(BatchSize.LARGE)                     // batch window: default MEDIUM 10 s -> LARGE 35 s
    .setBatchProcessingLevel(BatchProcessingLevel.LOW) // batches per cycle: default MEDIUM 20 -> LOW 1
    .build()
```

| Setting                   | Default               | Suggested       | Effect                                                                                                                  |
| ------------------------- | --------------------- | --------------- | ----------------------------------------------------------------------------------------------------------------------- |
| `setUploadFrequency`      | `AVERAGE` (2 s)       | `RARE` (5 s)    | Lengthens the interval between upload cycles, lowering the chance of colliding with your requests                       |
| `setBatchSize`            | `MEDIUM` (10 s)       | `LARGE` (35 s)  | Batches collect for longer, so there are fewer requests; larger batches also gzip better, so uplink bytes drop slightly |
| `setBatchProcessingLevel` | `MEDIUM` (20 batches) | `LOW` (1 batch) | Caps how many batches one upload cycle ships back-to-back, so a backlog cannot saturate the uplink at once              |

<Tip>
  These three settings only change *when* uploads happen. They drop no events and remove no dimension from your dashboards, so if you do not want to sacrifice data, tune only these.
</Tip>

<Note>
  The Android, iOS, HarmonyOS and Flutter SDKs use the same names and values for these three settings, so tuning advice transfers between platforms unchanged. The one difference is that iOS `batchProcessingLevel = .low` is 5 batches per cycle, while Android and HarmonyOS use 1 — same direction, smaller reduction.
</Note>

If the event volume itself is high, an EventMapper can drop specific noisy events (return `null` from the mapper). That is less invasive than changing your instrumentation — see [Advanced configuration](/en/rum/sdk/android/advanced-config).

## Offline Data Storage

When the device is offline, the SDK stores data locally with strict storage space limits:

<Check>
  * Uses fixed-size disk cache
  * Expired data is automatically cleaned up
  * Cached data will not affect device storage space
</Check>

## Related Documentation

<CardGroup cols={2}>
  <Card title="SDK Integration Guide" icon="plug" href="/en/rum/sdk/android/sdk-integration">
    Learn how to integrate the SDK
  </Card>

  <Card title="Advanced Configuration" icon="sliders" href="/en/rum/sdk/android/advanced-config">
    Learn about SDK advanced configuration options
  </Card>

  <Card title="Data Collection" icon="database" href="/en/rum/sdk/android/data-collection">
    Learn what data the SDK collects
  </Card>
</CardGroup>