Mobile Memory and Resource Management Questions

Covers memory management principles and resource handling for mobile applications across platforms. Candidates should understand platform specific models such as automatic reference counting on iOS and garbage collection on Android, common causes of memory leaks and retain cycles, and how reference ownership and weak versus strong references affect lifetime. Include techniques for releasing resources correctly in lifecycle methods and avoiding long lived references that hold activity or context objects. Expect knowledge of memory profiling and diagnostics including tools and workflows for locating leaks and high memory usage, strategies to prevent out of memory conditions, and trade offs such as requesting a larger heap. Also cover cross platform considerations for frameworks like React Native and Flutter and practical practices for identifying and fixing real memory issues in production, such as analyzing heap dumps, using allocation instrumentation, and applying targeted fixes and regression tests.

MediumTechnical

74 practiced

A React Native Android app shows increasing memory over time. Describe how you would determine whether the leak is in the JS heap, native heap, or the bridge. Include tools (Flipper, Chrome DevTools, Android profiler), signals to observe, and remediation patterns for each leak source.

Sample Answer

**Approach summary**I'll triage with profilers to classify the leak (JS heap, native heap, or bridge), reproduce with a deterministic scenario, then iterate fixes and re-measure.

**Tools & workflow**- Reproduce on device/emulator with release-ish build.- Chrome DevTools (Remote JS heap snapshot via React Native debug JS) — inspect JS object retention.- Flipper: React DevTools plugin, Memory plugin, and Hermes profiler (if using Hermes).- Android Studio Profiler / MAT (Memory Analyzer) — inspect native allocations and native heap growth.- adb logcat / systrace for GC frequency and OOMs.

**Signals to distinguish sources**- JS heap leak: - Chrome/Flipper JS heap snapshots show retained objects increasing over runs (closures, arrays). - Frequent JS GC but overall JS heap growth; native heap stable.- Native heap leak: - Android profiler shows native memory rising (native allocations, Bitmaps, NDK memory). - MAT identifies leaking classes (Activity, Bitmap). - JS heap stable while native grows.- Bridge (JS<->Native) leak: - Both heaps grow or native grows when many serialized bridge calls occur. - Pending promises/callbacks never resolved; Flipper shows long-lived JS objects referencing native handles. - Large number of sendEvents/sendTimers correlates with memory increase.

**Remediation patterns**- JS heap: - Remove accidental global refs, clear timers/intervals, destroy listeners, use weak refs, avoid large retained closures. - Example: unsubscribe in useEffect cleanup; avoid storing large data in component state.- Native heap: - Recycle Bitmaps, use Glide/Picasso, fix leaks of Context/Activity, unregister native listeners, free native buffers. - Use LeakCanary for Android to catch Activity/Service leaks.- Bridge: - Batch messages, reduce frequency of events, avoid passing huge objects across bridge; use direct native modules or JSI (Hermes) to reduce serialization. - Ensure promises/callbacks invoked on both success and error paths; null out native handles when JS side releases.

**Verification**- After fixes, re-run same scenario and compare heap snapshots and profiler traces to confirm memory plateaus and GC behavior normalizes.

EasyTechnical

78 practiced

Describe common image-related memory pitfalls on mobile such as loading full-resolution images into memory, creating multiple copies during transforms, and retaining large caches. For each pitfall list practical solutions: downsampling to view size, streaming/tiling, using efficient formats, in-memory pooling, and limiting concurrent decodes.

HardTechnical

57 practiced

Explain the differences between managed heaps (Java/Dart/Objective-C), native/C heap, and GPU/texture memory on mobile platforms. Describe symptoms which indicate which heap is problematic for an OOM, and list the tools and commands you would use to inspect each type of memory on Android and iOS.

Sample Answer

**Overview — heap types & characteristics**- Managed heap (Java/Kotlin VM, Dart, Objective‑C ARC-managed objects): GC-managed, contains objects, strings, framework widgets. Leaks grow slowly; GC pressure triggers pauses.- Native/C heap: malloc/calloc, native libraries, bitmaps, large buffers. Leaks are persistent until freed; often large contiguous allocations.- GPU/texture memory: GPU-side textures/buffers (GL/Vulkan/Metal). Not in process RSS always; causes OOMs in GPU allocation path or driver failures.

**Symptoms pointing to which heap**- Managed heap: Frequent GC, increasing "allocated" managed size, OutOfMemoryError referencing java.lang.OutOfMemoryError or Dart VM OOM; UI slow during GC.- Native heap: High RSS / native memory growth while managed heap stable; crashes with native OOM, malloc failure, or SIGABRT in native libs.- GPU/texture: Crashes when loading images/textures; errors like EGL_BAD_ALLOC, GLES errors, framebuffer incomplete, or app backgrounding to free GPU fixes it.

**Inspection tools & commands**

Android- Java/Dalvik heap: Android Studio Memory Profiler; adb shell dumpsys meminfo <pkg>; MAT on HPROF:

bash

adb shell am dumpheap <pkg> /sdcard/heap.hprof
adb pull /sdcard/heap.hprof

- Native/C heap: dumpsys meminfo -d <pkg>, /proc/<pid>/smaps, malloc hooks, heap snapshots (libc malloc debug):

bash

adb shell cat /proc/<pid>/smaps
adb shell dumpsys meminfo <pkg>

- GPU: adb shell dumpsys SurfaceFlinger --local, logcat for GLES errors, GPU profiling in Android Studio (System Trace), dumpsys gfxinfo:

bash

adb shell dumpsys gfxinfo <pkg>
adb logcat | grep -i egl

iOS- Managed (Obj‑C/Swift): Xcode Instruments — Allocations, Leaks; VM Tracker; observe memory graph.- Native/C: Instruments Allocations + VM Tracker; malloc stackshots; inspect resident size in sysdiagnose.- GPU/texture: Metal Debugger in Xcode, Instruments Metal System Trace; look for Metal API errors in device console.

**Approach to diagnose**1. Reproduce with device; capture full memory/RSS timeline.2. Correlate GC pauses, RSS, and GPU errors.3. Heap dump -> analyze retained paths (MAT / Xcode Memory Graph).4. If native: enable malloc guards, run Address Sanitizer / guard malloc.5. If GPU: reduce texture sizes, reuse textures, check GL/Metal lifecycle.

Use targeted profiling, incremental fixes, and re-run to confirm.

HardTechnical

65 practiced

For a memory-critical Android app that performs heavy image processing and background syncs, analyze the pros and cons of using android:largeHeap versus redesigning work into a separate process or leveraging native memory pools. Discuss how each approach affects OS memory pressure, battery, multi-process trade-offs, and maintainability.

Sample Answer

**Summary / recommendation** For a memory‑critical Android app, prefer redesign (process isolation + careful memory pools) over relying on android:largeHeap. largeHeap is a stopgap that hides problems and worsens OS-level memory pressure; use it only when impossible to refactor.

**android:largeHeap — Pros / Cons** - Pros: Quick to enable; reduces immediate OOMs for large images. - Cons: Encourages memory bloat; Android treats it per-process but overall system memory pressure increases; poorer multitasking (other apps get killed); no battery benefit — larger heaps increase GC pauses and CPU for GC, increasing energy use; hard to reason about across OEM variants.

**Separate process / process isolation — Pros / Cons** - Pros: Limits blast radius (e.g., heavy image pipeline in a dedicated process); Android can kill/restart it independently; improves UI responsiveness and reduces main process OOMs. Good for background syncs or batch work. - Cons: IPC overhead (Binder) and serialization costs; increased APK complexity, lifecycle coordination, and testing; two processes double baseline memory footprint (code and native libs), affecting overall memory and battery.

**Native memory pools (NDK) — Pros / Cons** - Pros: Predictable, manual allocation (e.g., pooled bitmaps, native allocators) reduces Java heap pressure and frequent GC; can use mmap/ashmem to share buffers across processes; often lower CPU/GPU copy cost -> battery savings. - Cons: Unsafe (leaks crash process), platform differences, debugging harder; asset lifetime must be carefully managed; increases code complexity.

**Trade-offs & practical guidance** - Start by profiling (Android Studio Memory Profiler, dumpsys meminfo). - If large allocations are transient, use pooled native buffers + Bitmap pooling (inSampleSize, BitmapFactory options, Bitmap re-use). - Use a separate process for non-UI heavy work (e.g., worker process for transforms/sync) when isolation and restartability matter; mitigate IPC cost with shared ashmem or file descriptors. - Reserve android:largeHeap as last resort with clear monitoring and timeboxed mitigation plan.

**Maintainability / testing** - Prefer patterns that keep behavior deterministic: pool + clear contracts, small IPC surface, thorough integration tests. Document ownership of native memory and lifecycle to avoid hidden leaks.

EasyTechnical

99 practiced

In Swift, write a short example where a class creates a retain cycle by capturing self in a stored closure (for example a callback stored on the object). Then show how to fix the retain cycle using a capture list ([weak self] or [unowned self]) and explain the trade-offs between weak and unowned in this scenario. Provide the example in Swift code.

Sample Answer

**Problem (retain cycle)**A class stores a closure that captures self strongly, creating a retain cycle.

**Bad example (creates retain cycle)**

swift

class Downloader {
    var completion: (() -> Void)?
    func start() {
        // closure captures `self` strongly
        completion = {
            print("Download finished for \(self)")
        }
    }
    deinit { print("Downloader deinit") }
}

var d: Downloader? = Downloader()
d?.start()
d = nil // Downloader is not deallocated due to retain cycle

**Fix with [weak self]**

swift

class DownloaderWeak {
    var completion: (() -> Void)?
    func start() {
        completion = { [weak self] in
            guard let self = self else { return }
            print("Download finished for \(self)")
        }
    }
    deinit { print("DownloaderWeak deinit") }
}

**Fix with [unowned self]**

swift

class DownloaderUnowned {
    var completion: (() -> Void)?
    func start() {
        completion = { [unowned self] in
            print("Download finished for \(self)")
        }
    }
    deinit { print("DownloaderUnowned deinit") }
}

**Trade-offs**- weak: captures an optional; safe if closure may outlive the object. Must handle nil (guard/optional).- unowned: non-optional, no runtime check; use only when you guarantee the object outlives the closure (avoids crashes). For callbacks stored on the same object, weak is usually safer in iOS apps.

Unlock Full Question Bank

Get access to hundreds of Mobile Memory and Resource Management interview questions and detailed answers.

Join thousands of developers preparing for their dream job.