Performance & footprint
Figures below were measured on Screeb Android SDK v4.0.0 (2026-07-01) with a release build (R8/minification on) using a repeatable, versioned methodology. They cover two independent regimes: Core (surveys and in-app messages, what every integration gets by default) and Session Replay (screen recording, opt-in only — inactive unless the customer enables it, via the SDK API or server-side targeting).
Summary
| Metric | Core (surveys, default) | Session Replay (opt-in) |
|---|---|---|
| App size added | ~179 KB download size (release, R8, transitive dependencies included) | included above — ships in the same package |
| Memory (RAM) | ≈ +62–64 MB, dominated by the Android System WebView used to render surveys | ≈ +65 MB — roughly core + ~1 MB, since session replay reuses the existing survey WebView rather than adding a second one |
| CPU | idle: no measurable cost — the idle reading lands at or below the SDK-free process baseline | small marginal cost on top of Core's own CPU usage during active interactions — on-screen interactions dominate CPU either way; Session Replay's own share is modest and, from a single measurement, on the order of 0–3% of one core |
| Network | first session: ≈ 2.1 MB down / ~76 KB up; largely cacheable; event tracking is batched (near-zero incremental) | a few KB per minute under light on-screen activity — scales with how much the screen changes, uploaded in batches and flushed when a recording stops |
| On-device storage | negligible — the WebView's own localStorage holds ~3.5 KB of SDK-attributable state; no SharedPreferences or SDK-managed files | none beyond Core |
App size
Adding the Screeb SDK to an Android app increases the release download size by about 179 KB, including all transitive dependencies. This single figure covers both Core and Session Replay, since they ship in the same package — there's no separate "Session Replay module" to add on top.
Memory
With the SDK active, memory usage increases by roughly 62 to 65 MB. This is driven almost entirely by the Android System WebView instance the SDK uses to render surveys and in-app messages — the same footprint you'd see from any app embedding a WebView. It stays essentially the same whether a survey is currently visible or not, and enabling Session Replay adds only a small amount on top of it — around 1 MB — since session replay records the screen through the WebView that's already there, rather than allocating a second one.
CPU
At idle, the SDK adds no measurable CPU cost — its idle reading comes in at or below the CPU used by an equivalent app process with no SDK at all, i.e. within normal measurement noise, not a sustained background workload. When the app is actively used, on-screen interactions themselves are what drive CPU usage, whether or not Session Replay is running. Session Replay does add some CPU on top of that, since it continuously captures, diffs, and encodes screen frames, but that marginal cost is small relative to the interaction workload itself — on the order of 0–3% of one CPU core based on a single measurement pass. This marginal cost only applies while Session Replay is running — it is not part of the default footprint.
Network
A typical first survey session — from SDK initialization through the survey being displayed — transfers about 2.1 MB down and 76 KB up. The large majority of this is the WebView loading the survey rendering bundle; event tracking itself is batched and adds close to zero incremental network usage.
This survey bundle is versioned and served with standard HTTP caching, so it is not re-downloaded on every session — it is largely cacheable and only churns when the bundle version changes on our end.
Session Replay's own network usage is small — on the order of a few kilobytes per minute under light on-screen activity, split roughly evenly between upload and download. Replay data is batched on-device and uploaded when a recording stops rather than streamed continuously frame-by-frame, so short recordings may see traffic arrive in bursts rather than a steady trickle. The actual volume scales with how much the screen visually changes: a mostly static screen produces very little traffic, while heavier, continuously-changing content produces more — so treat any single figure as indicative of light usage, not a fixed rate. This traffic is separate from, and not part of, the Core session figure above.
Storage
The Screeb Android SDK itself keeps no persistent storage of its own on the device: no SharedPreferences, no SDK-managed files or databases. The SDK's rendering surface (a WebView) does persist a small amount of state via standard browser localStorage — about 3.5 KB, used for session/client state — which is negligible. Beyond that, the WebView also maintains its own standard HTTP cache for the survey bundle it downloads, which is what enables the caching behavior described above; that cache is managed entirely by the OS/WebView, not by the SDK.
Figures are measured on a single reference device and represent a realistic, reproducible baseline; exact numbers can vary slightly by device and OS version. Session Replay is always opt-in — it has zero runtime footprint (CPU/memory/network) until it is started, either explicitly via Screeb.sessionReplayStart() or when enabled through Screeb's server-side targeting configuration; its code is included in the SDK's binary size regardless.