Mobile Performance and Energy Optimization Questions

Comprehensive engineering and operational practices for diagnosing, profiling, and optimizing mobile application performance and device energy consumption at feature and system scale. Candidates should be able to explain strategies to reduce application startup time, minimize main thread work to keep the user interface responsive, and stabilize rendering at target frames per second such as sixty frames per second and one hundred and twenty frames per second to avoid application not responding situations. Core topics include memory management and leak prevention, allocation analysis, preventing crashes and responsiveness regressions, efficient rendering of large feeds, complex gesture and input handling, and efficient handling of large media such as photos and video. Common techniques include lazy loading, request batching, image resizing and compression, caching and batching strategies, offline first synchronization, and efficient background processing and scheduling to limit energy impact. Energy and battery focused optimizations include minimizing sensor usage and location service use when unnecessary, geofencing best practices, network and radio optimizations to reduce radio wake ups, preferring push driven updates over polling where appropriate, and designing background tasks to be energy aware. Candidates should demonstrate familiarity with profiling and instrumentation tools and workflows for mobile platforms, interpreting profiler output to identify central processing unit and memory bottlenecks, measuring and quantifying latency and energy impact, designing architectural and code changes to prevent regressions, reasoning about trade offs between native and cross platform implementations, and defining user perceived performance and energy metrics with continuous monitoring and tests to quantify improvements.

EasyTechnical

91 practiced

You have a long-scrolling feed implemented with RecyclerView (Android) / UITableView (iOS) that contains many images and small complex subviews. List practical strategies to optimize scroll performance: include view recycling, image decoding, avoiding allocations per frame, and GPU/CPU trade-offs.

Sample Answer

**Clarify goal**Keep scrolling 60fps with low jank, low memory spikes, and stable battery/CPU.

**Practical strategies**

- **View recycling / reuse** - Use RecyclerView/ViewHolder or UITableViewCell properly. Avoid findViewById in onBind — cache views. - Reuse/adapt existing views instead of inflating in onBind; keep layouts flat (ConstraintLayout/UIView stack tuning).

- **Image decoding & loading** - Decode to target size (inSampleSize / BitmapFactory options or use Glide/Coil/Picasso/SDWebImage with resize). Decode on background threads. - Use efficient formats (WebP/AVIF where supported) and memory pools (BitmapPool). - Cancel in-flight requests in prepareForReuse / onViewRecycled.

- **Avoid allocations per frame** - No new objects in bind/layout/draw: avoid creating strings, drawables, anonymous lambdas, temporary arrays, Spannables each frame. - Reuse Paint, Rect, Path instances. Preallocate lists/buffers. - On iOS: reuse NSAttributedString/formatters; avoid autorelease churn in scrolling code.

- **GPU vs CPU trade-offs** - Avoid expensive offscreen renders: flattened layouts, minimize overlapping translucent views, avoid heavy shadows/elevation which force extra compositing. - Use hardware layers sparingly: enable for short animations but don't keep static views in a hardware layer (costly GPU memory). - Prefer pre-rasterized bitmaps for complex static subviews; use simpler drawing code (Canvas/CoreGraphics) when cheaper than many subviews.

- **Other practical tips** - Profile: Systrace/Traceview, Profile GPU Rendering (Android), Instruments Core Animation (iOS). - Throttle work: debounce image loads, use placeholder thumbnails, incremental load (low-res → high-res). - Memory caps: tune cache sizes, evict bitmaps on memory pressure.

Example (Kotlin onBind):

kotlin

override fun onBindViewHolder(h: VH, pos: Int) {
  val item = list[pos]
  h.title.text = item.title          // no allocations
  imageLoader.load(item.url)
    .resize(h.image.width, h.image.height)
    .into(h.imageView)
}

Use profiling to validate which change gives real benefit.

HardTechnical

112 practiced

You must choose which components to rewrite natively to achieve stable 120fps on high-refresh devices for a critical animation-heavy feature in a cross-platform app. Define decision criteria (performance, maintenance cost, dependencies), measurable benchmarks (per-frame budgets, p99 latency), and a phased rollout and validation plan that includes canarying and fallbacks.

Sample Answer

**Decision criteria**- Performance impact: measurable frame time reduction, GPU draw call reduction, lower JS/bridge crossings. - Maintenance cost: dev effort (weeks), platform parity, test surface, internal expertise. - Dependencies & risk: 3rd‑party libs, OS version limits, ABI changes. - UX/energy: battery impact, thermal throttling risk. - Reusability: can component be shared across platforms or is it platform-specific?

**Measurable benchmarks**- Per-frame budget: 1000 ms / 120 fps =

text

8.33 ms

(target < 7 ms to include compositor work). - Latency targets: p50 < 4 ms, p90 < 6 ms, p99 < 8.33 ms for render-critical path. - Jank: < 0.1% frames > 16ms, < 1% frames > 8.33ms. - CPU/GPU: sustained main-thread CPU < 40% on flagship device; GPU frame time budget < 4 ms. - Memory: no OOM regressions, peak working set increase < 10%. - Power: end-to-end battery draw increase < 5% in stress test.

**Evaluation process**- Instrumentation: high-frequency telemetry (per-frame timestamps, stage durations: app logic, layout, raster, GPU submit), traces (Systrace/Android Perfetto, iOS Instruments), and synthetic benchmarks on representative devices (high-refresh flagship + midrange 90/60Hz). - Profiling checklist: bridge crossings, JS/C++ boundaries (React Native), Skia draw calls (Flutter), layout invalidations, texture uploads.

**Phased rollout & validation**1. Prototype + measure (can be internal native module): implement hot path natively (Swift/Kotlin) to validate perf delta. 2. Lab validation: automated frame-capture tests at 120Hz, smoke tests, power profile. Accept if p99 and jank meet targets. 3. Canary release (0.5–5%): ship native variant behind remote flag to small cohort (geography/device family split). Collect telemetry: per-frame timings, crashes, adoption, UX metrics (engagement, drop-offs). Define pass/fail gates (e.g., p99 < 8.33ms AND crash rate no higher than baseline + 0.05%). 4. Progressive ramp: 5% → 25% → 100% with monitoring and manual sign-off at each stage. 5. Fallbacks & kill-switches: remote config toggle to switch back to cross-platform implementation instantly; keep both renderers available for A/B rollback. Graceful degrade: on thermal/cpu pressure or battery saver, fall back to lower-fidelity animation or 60fps mode. 6. Post-rollout: monitoring dashboards, weekly stability review, and plan to upstream native optimizations into cross-platform layer if maintainability demands.

**Example trade-offs**- If native rewrite reduces p99 by 60% but doubles maintenance cost across platforms, prefer targeted native for the animation micro-component with a small, well-tested interface; keep higher-level logic cross-platform.

This plan ensures decisions are data-driven, measurable, and reversible while balancing UX gains against engineering cost.

MediumTechnical

87 practiced

Implement a debouncer function in TypeScript for a React Native app with signature:

function debounce<T extends (...args:any[]) => any>(fn: T, waitMs: number): T

It should delay invocation until waitMs of inactivity; preserve `this` context and arguments; and support cancellation on unmount. Provide a compact but correct implementation and explain how to cancel pending invocations safely.

Sample Answer

**Solution (approach)**

Delay calling fn until waitMs of inactivity. Preserve this/args using apply. Expose a cancel method on the returned function so React components can clear pending timer on unmount.

typescript

function debounce<T extends (...args: any[]) => any>(fn: T, waitMs: number): T {
  let timer: ReturnType<typeof setTimeout> | null = null;

  const debounced = function (this: any, ...args: any[]) {
    if (timer) clearTimeout(timer);
    timer = setTimeout(() => {
      timer = null;
      fn.apply(this, args);
    }, waitMs);
  } as T & { cancel?: () => void };

  debounced.cancel = () => {
    if (timer) {
      clearTimeout(timer);
      timer = null;
    }
  };

  return debounced as T;
}

**How to cancel on unmount**

- In a functional React Native component, keep the debounced function in a ref or stable variable and call .cancel() in cleanup.

Example:

tsx

const searchRef = useRef(debounce(handleSearch, 300));
useEffect(() => () => { searchRef.current.cancel?.(); }, []);

Why this is safe:- clearTimeout prevents the scheduled call; setting timer to null avoids double clears.- Using fn.apply(this, args) preserves original context and arguments.

HardTechnical

66 practiced

Describe a strategy to minimize radio wake-ups caused by chat message notifications for a global user base. Cover push delivery semantics, server-side aggregation or collapse keys, use of APNs/FCM features, batching of silent updates, and trade-offs between latency and energy.

Sample Answer

**High-level approach**I’d minimize radio wake-ups by turning many individual chat-notification events into fewer, smarter pushes using server-side aggregation + platform features, accepting controlled latency when needed.

**Push delivery semantics**- Use “best-effort”/high-priority for foreground/real-time messages; use low-priority/“background” pushes for non-urgent updates.- Treat push as at-most-once/best-effort: rely on in-app sync for guaranteed delivery to avoid re-sends that wake radios.

**Server-side aggregation & collapse keys**- Aggregate per-user (and per-device group) within a short window (e.g., 5–30s). Collapse messages into a single payload summarizing count, senders, and last message excerpt.- Use FCM collapse_key / APNs apns-collapse-id so platform collapses duplicates when device is offline.- Maintain per-conversation vs global collapse strategies: collapse per-conversation for active chats, global collapse for background updates.

**Use of APNs/FCM features**- FCM: set priority = high only for messages needing immediate UI notify; normal for silent or aggregated. Use collapse_key and ttl appropriately.- APNs: use apns-priority 10 for immediate, 5 for background; use apns-collapse-id for collapsing; include content-available = 1 for silent updates.- Use mutable-content / notification service extensions on iOS to fetch rich content only when user expands notification.

**Batching silent updates**- Send silent background pushes (content-available/apns-priority 5 or FCM normal) periodically to update local DB/state. Combine multiple chat events into one silent update that delivers summary and triggers a lightweight sync.- Client-side: when silent push arrives, perform a single short-lived sync and apply changes; respect OS limits to avoid terminated background execution.

**Trade-offs: latency vs energy**- Lower energy: larger aggregation windows, more aggressive collapse, use normal/prioritized background pushes. Accept increased perceived latency (up to tens of seconds).- Lower latency: immediate high-priority pushes per message — increases radio-on events and battery.- Hybrid: use heuristics (user activity, VIPs, Do-Not-Disturb, message importance) to selectively escalate priority.

**Example policy**- If sender is VIP or user is in active chat → send high-priority immediate push.- Else: server buffers 10s, collapse into one normal-priority push; send silent periodic sync every 5–15 minutes if there’s low activity.

This balances UX and battery: critical messages are immediate; most messages are aggregated to reduce wake-ups, with robust in-app sync to ensure correctness.

HardTechnical

65 practiced

Explain how to quantify the energy impact of a feature change. Design an experiment to measure battery consumption attributable to a specific feature with statistical rigor: device selection, workload definition, measurement tools (on-device telemetry vs hardware power meters), metrics to collect, baseline determination, number of runs, and how to compute confidence intervals.

Sample Answer

**Clarify goal & constraints**- Goal: measure additional battery energy consumed by Feature X vs baseline app without X, with statistical rigor across representative devices and workloads.

**Device selection**- Pick 3–5 devices covering low/medium/high SoC, and at least two OS versions if relevant.- Use identical firmware, fresh charge cycles, airplane mode for network-sensitive tests unless feature requires network.- Repeatable thermal/environmental conditions (ambient temp controlled).

**Workload definition**- Create an automated script that exercises the exact user path invoking Feature X and an equivalent baseline path without it.- Use UI automation (Android: adb/espresso, iOS: XCUITest) and synthetic traffic if needed.- Fix screen brightness, disable background apps, clear caches between runs.

**Measurement tools**- Hardware power meter (preferred): attach power monitor to battery line or use power-harness (e.g., Monsoon) for absolute energy (mWh) and high sample rate.- On-device telemetry: Android Battery Historian, dumpsys batterystats, iOS energy logs — useful for attribution but noisier and system-filtered.- Use both when possible: meter for ground-truth energy; telemetry for attribution to processes.

**Metrics to collect**- Primary: total energy consumed during scenario (mWh) and average power (W).- Secondary: runtime duration (s), CPU% per core, GPU, network bytes, wakelocks, temperature, battery % delta.- Collect timestamps to align traces.

**Baseline & experimental runs**- Baseline = same app version with Feature X disabled or feature code path stubbed.- Randomize run order (ABBA) to avoid drift.- Warm-up run(s) discarded, then collect N independent runs per device/per condition.- Recommend N ≥ 30 for CLT, but if constrained, compute required N using observed variance; start with 15–30.

**Statistical analysis & confidence intervals**- For each device compute sample mean energy difference d̄ between Feature and Baseline across paired runs (prefer pairing same-order runs).- Use paired t-test and CI when differences approximate normal; otherwise use Wilcoxon signed-rank.- 95% CI for mean difference:

text

mean_diff ± t_{n-1,0.975} * (s_diff / sqrt(n))

Plain English: multiply the standard error of the paired differences by the t critical value.

**Practical notes**- Report per-device CIs and a pooled estimate (random-effects meta-analysis) to generalize across devices.- Verify effect size vs user-impact threshold (e.g., >5% nightly battery drain).- Share raw traces and scripts for reproducibility.

Unlock Full Question Bank

Get access to hundreds of Mobile Performance and Energy Optimization interview questions and detailed answers.

Join thousands of developers preparing for their dream job.