Mobile app performance optimization encompasses strategies and techniques for improving startup time, memory efficiency, battery consumption, network usage, and UI responsiveness across iOS and Android platforms. Performance directly impacts user retention—53% of users abandon apps that take longer than 3 seconds to load—making optimization essential for app success. The key mental model is to understand that mobile devices have constrained resources (CPU, memory, battery) compared to desktop systems, requiring developers to prioritize critical paths, defer non-essential work, and aggressively optimize the most common user flows rather than attempting to optimize everything equally.
What This Cheat Sheet Covers
This topic spans 16 focused tables and 169 indexed concepts, 147 flashcards. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
A jump-to index of every table row in this cheat sheet.
An interactive map of every table and concept in this topic.
Table 1: App Startup Optimization Techniques
Cold starts, warm starts, and hot starts each require different strategies; the biggest gains come from eliminating work in application initialization — not just deferring it — and from pre-compiling critical code paths before the user ever runs the app.
| Technique | Example | Description | |
|---|---|---|---|
Defer non-critical initialization: Application.onCreate() { // Critical only initCrashReporting() // Defer analytics, ads} | • Fastest startup type from when app process doesn't exist • minimize work in Application.onCreate() or application(_:didFinishLaunchingWithOptions:) to achieve sub-2-second cold starts | ||
Generated via Macrobenchmark: baselineProfile { profileInstrumentation("androidx")} | • Enables ahead-of-time (AOT) compilation of critical code paths, improving cold start by 20-40% by avoiding JIT compilation overhead during launch • Reddit saw 40-55% faster starts after enabling | ||
In build.gradle.kts:isMinifyEnabled = trueisShrinkResources = true | • Enables tree shaking, method inlining, class merging, and identifier minification • Reddit achieved 40% faster cold start, 30% fewer ANRs, 14% smaller APK — enabling full R8 took less than 2 weeks | ||
Set includeInStartupProfile = truein Baseline Profile generator | • Optimizes DEX file layout to place startup classes in the first classes.dex, reducing files loaded at launch• adds 15-30% improvement on top of Baseline Profiles alone | ||
private val analytics by lazy { AnalyticsSDK.create()} | • Initialize objects only when first accessed, not during app startup • reduces initial memory footprint and CPU usage during critical launch phase | ||
class WorkManagerInitializer : Initializer<WorkManager> | Jetpack library that coordinates initialization order and provides single ContentProvider entry point, eliminating multiple ContentProvider overhead that can add 50-100ms per provider | ||
splashScreen.setKeepOnScreenCondition { !viewModel.isReady.value} | • System-level splash screen API introduced in Android 12 • ensures instant app launch animation while app initializes in background | ||
Preserve activity state: onSaveInstanceState(Bundle) | • App process exists but activity needs recreation • optimize by caching frequently-used data in memory and avoiding redundant initialization — typically 50-70% faster than cold start | ||
Prepare data in sceneWillEnterForeground:before UI updates | • Load critical resources before they're needed to reduce perceived latency • cache network responses and prepare view controllers during background-to-foreground transition | ||
Handle intent data after UI ready: lifecycleScope.launch { delay(300) handleDeepLink()} | • Process deep link data after first frame renders rather than blocking launch • improves perceived startup time for users tapping notifications | ||
Keep launch under 10s (0x8badf00d) | iOS terminates apps that block main thread beyond specific time limits: 20s for launch, 10s for resume, 6s for quit — exceeding these triggers watchdog crash | ||
Lightweight splash screen, avoid heavy layouts, minimal theme assets | • Use simple views for initial screen • complex layouts with nested hierarchies can add 200-500ms to time-to-first-frame |