Mobile Performance Test Gate: Cold Start & Frame Budget

Device & Build Profile

Device tier (CPU slowdown) 1.6×

Cold-start init work 900 ms

GC pressure (alloc churn) 25%

Target frame rate

Live Test Readouts

Cold start (TTI)

— ms

Dropped frames

—

Jank score

—

Frame budget

16.7 ms

CI performance gate

RUNNING

How it works

This simulates two of the standard mobile performance-testing checks that sit alongside unit/integration/UI tests in a mobile CI pipeline: a cold-start budget and a frame-time (jank) budget.

Cold start. Launch is modelled as six sequential main-thread init tasks (process fork, content providers, Application.onCreate, activity inflate, layout pass, first frame). Each task's duration scales with the chosen init work and the device-tier multiplier:

task_ms = share_i × initWork × deviceTier
TTI = Σ task_ms  (Time To Interactive)

Google's Android vitals treats a cold start over 5000 ms as "excessive" — that threshold is the pass/fail line for the TTI half of the gate.

Frame budget. Once the app is interactive, a live strip samples one frame time per animation tick during a simulated scroll:

frame_ms = base(deviceTier) + noise
         + (rand() < gcProb ? gcSpike : 0)
budget   = 1000 / targetFps
janky if frame_ms > budget

Higher GC pressure raises both the probability and size of garbage-collection pause spikes, which show up as tall red bars. The rolling dropped-frame % over the last 100 frames and a weighted jank score (mean overage above budget) are checked against common CI thresholds (≤10% dropped frames) to decide the overall PASS / FAIL gate — exactly the kind of automated check a mobile performance-testing strategy runs on every build, distinct from functional unit/UI tests or device-lab scheduling.

Cold start

Init task (Gantt) Frame within budget Janky / dropped frame

⚠ Couldn't load the 3D engineThree.js failed to load from the CDN. Check your connection and reload.