Android SDK Performance Impact

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.

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.

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

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

Performance Impact Details

CPU Usage

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.

Memory Usage

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.

Launch Time

The SDK initialization process is optimized, with launch time impact controlled to milliseconds.

It is recommended to initialize the SDK as early as possible in Application.onCreate() to capture the complete application startup process.

APK Size

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

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.

Network Usage

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

Performance Optimization Recommendations

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

Adjust the sample rate

Reduce the number of collected events by configuring the sample rate:

val rumConfig = RumConfiguration.Builder(applicationId)
    .setSessionSampleRate(80f) // sample 80% of sessions
    .build()

Enable only the features you need

Turn off the automatic tracking you do not analyze:

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()

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.

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.

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:

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

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.

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.

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.

Offline Data Storage

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

Uses fixed-size disk cache
Expired data is automatically cleaned up
Cached data will not affect device storage space

SDK Integration Guide

Learn how to integrate the SDK

Advanced Configuration

Learn about SDK advanced configuration options

Data Collection

Learn what data the SDK collects

Quick Start

Analytics

SDK Integration

Performance

Error Tracking

Explorer

Session Replay

Best Practices

Others

Android SDK Performance Impact

Overview

Performance Benchmark

Test Results

Performance Impact Details

Performance Optimization Recommendations

Reducing the Impact of Uploads on Your Own Requests

Offline Data Storage

SDK Integration Guide

Advanced Configuration

Data Collection

​Overview

​Performance Benchmark

​Test Results

​Performance Impact Details

​Performance Optimization Recommendations

​Reducing the Impact of Uploads on Your Own Requests

​Offline Data Storage

​Related Documentation

SDK Integration Guide

Advanced Configuration

Data Collection

Overview

Performance Benchmark

Test Results

Performance Impact Details

Performance Optimization Recommendations

Reducing the Impact of Uploads on Your Own Requests

Offline Data Storage

Related Documentation