Mobile App Architecture, Lifecycle, and Performance Questions

Definition / goal: Measure frame rate and drops to quantify perceived smoothness (FPS, frame-time, jank) and turn that into actionable signals for engineers and PMs.

Instrumentation points:

• Collect frame timestamps at display-sync (VSYNC) or render pipeline boundaries:
  • App-side: record frame start (input handling), render start, render end/composite, and frame presented timestamp.
  • Platform hooks: use OS APIs (Android Choreographer, iOS CADisplayLink / Core Animation durations).
  • GPU/Compositor: capture surface-fling, dropped-surface counters if available.
• Correlate with events: screen orientation, navigation, network calls, long tasks, GC pauses.

Metrics to compute:

• Instant FPS (1 / frame_time) and moving average (1s, 5s).
• Frame-time distribution: p50, p90, p95, p99 frame-time in ms.
• Jank count: frames > 16ms (60Hz) or >33ms (30Hz). Also count consecutive janky frames and “frozen” periods.
• Drop rate: percentage of expected vs presented frames over intervals.
• Worst-case windows: max frame-time in 1s sliding windows.
• Context tags: device model, OS, CPU load, thermal state, screen refresh rate, feature flag.

Dashboarding and surface:

• Engineer view:
  • Time-series charts: p50/p90/p99 frame-time and FPS with zoom, annotations for releases.
  • Heatmap per device/OS for p95 and jank rate.
  • Alerting: increase in jank rate or p99 exceeding threshold; link to traces and recent commits.
  • Drilldowns: session-level traces showing frame timestamps, long-task stack traces, GC events.
• PM / Product view:
  • High-level KPIs: % smooth sessions (e.g., sessions with jank_rate < 1%), average FPS per cohort, crash + jank correlation.
  • Segmented trends by region, app version, feature rollout.
  • Short narratives: "Release X increased jank by Y% on older devices" with impact on retention.

Implementation best practices:

• Sample or batch telemetry to limit network/energy impact; compute aggregates client-side (histograms) and send compact metrics.
• Use consistent time bases and tag schemas for correlation.
• Add privacy and opt-out controls.

This approach gives engineers actionable traces and PMs concise outcome metrics to prioritize performance work.

Start by distinguishing goals: Android and iOS diagnostics both aim to detect leaks, spikes, and memory pressure, but tooling and OS behavior differ (Linux-based / low-memory-killer on Android vs. Darwin memory notifications and Jetsam-like behavior on iOS).

System-level metrics to collect:

• RSS (resident set size) — actual physical memory used.
• Heap usage / allocated objects — Java/Kotlin heap on Android (ART), Obj‑C/Swift heap on iOS.
• Peak memory and growth rate (delta over time).
• Virtual memory size, native vs. managed memory breakdown, file/cache usage.
• GC/counts, allocation rate, thread stacks, and OOM / low-memory events.

Platform telemetry options:

• Android: Android Vitals (Play Console) for ANRs, crash & OOM rates; System tracing (adb, systrace), procfs (/proc/[pid]/smaps), ART heap stats, memory Profiler in Android Studio, Firebase Performance for traces and custom metrics.
• iOS: Xcode Instruments (Allocations, VM Tracker), os_signpost and MetricKit (on-device reports delivered to the developer), Crashlytics + Firebase for crash/OOM, Activity Monitor, and aggregated metrics via App Store Connect (MetricKit, Crash Reports).
• Cross-platform: integrate custom telemetry (securely) to send aggregated metrics to backend for dashboards.

Privacy and overhead trade-offs for heap snapshots:

• Full heap dumps reveal object references and possibly user data — must redact or avoid persisting PII. Compliance (GDPR/CCPA) requires consent/justification.
• Heap dumps are heavy (CPU, pause time, disk/network) and can crash low-memory devices. They’re acceptable for targeted, rate-limited captures but not continuous.

Sampling / throttling strategies:

• Event-triggered snapshots: only capture on elevated signals (sustained growth rate above threshold, repeated GC pressure, crash/OOM).
• Probabilistic sampling: capture 1 in N sessions or users, skewed to power users, devices with reproducible issues, or beta channels.
• Rate limits per device/account and exponential backoff after captures.
• Lightweight continuous metrics: send aggregated counters (percentiles, histograms) instead of raw dumps to detect anomalies before heavy capture.
• Offload heavy processing: collect minimal in-app metadata, perform symbolication and deeper analysis server-side.
• Use low-overhead telemetry APIs (MetricKit, Android Vitals) for baseline monitoring and reserve deep captures for debugging windows.

Practical approach: rely on platform telemetry for broad detection, use aggregation and alerting on RSS/growth rate/GC churn, then trigger targeted heap captures with strict privacy redaction, sampling, and rate limits to investigate root cause.

Approach: avoid capturing Activity/View or long-lived JS callbacks directly. Use WeakReference for host objects, keep a single callback holder you can clear, and ensure callbacks are invoked/cleared on host destroy (onHostDestroy / onCatalystInstanceDestroy). Also support id-based callback maps so you can cancel outstanding operations.

Android (Java) — pattern: WeakReference + explicit clear

public class MyModule extends ReactContextBaseJavaModule implements LifecycleEventListener {
  private final Map<String, Callback> callbacks = new ConcurrentHashMap<>();
  private final ReactApplicationContext reactContext;

  public MyModule(ReactApplicationContext ctx) {
    super(ctx);
    this.reactContext = ctx;
    ctx.addLifecycleEventListener(this);
  }

  @ReactMethod
  public void startOp(String id, Callback cb) {
    callbacks.put(id, cb);
    // start async work; don't capture Activity directly
    Activity activity = getCurrentActivity(); // use weak ref where used
    WeakReference<Activity> weakActivity = new WeakReference<>(activity);
    Executors.newSingleThreadExecutor().submit(() -> {
      Activity a = weakActivity.get();
      // do work; when ready:
      Callback saved = callbacks.get(id);
      if (saved != null) {
        saved.invoke("result");
        callbacks.remove(id);
      }
    });
  }

  @Override
  public void onHostDestroy() {
    // clear remaining callbacks to allow JS GC
    for (Callback c : callbacks.values()) {
      try { c.invoke((Object) null); } catch (Exception ignored) {}
    }
    callbacks.clear();
  }
  public void onHostResume() {}
  public void onHostPause() {}
}

Kotlin variant uses MutableMap<String, Callback?> and WeakReference<Activity> similarly; ensure callbacks.clear() in onHostDestroy.

iOS (Objective-C) — pattern: RCTResponseSenderBlock storage and weak refs

@interface MyModule()
@property (nonatomic, strong) NSMutableDictionary<NSString*, RCTResponseSenderBlock> *callbacks;
@end

@implementation MyModule

RCT_EXPORT_MODULE();

- (instancetype)init {
  if (self = [super init]) {
    _callbacks = [NSMutableDictionary new];
    [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(onDestroy) name:UIApplicationWillTerminateNotification object:nil];
  }
  return self;
}

RCT_EXPORT_METHOD(startOp:(NSString *)id callback:(RCTResponseSenderBlock)callback) {
  if (callback) self.callbacks[id] = [callback copy];
  __weak typeof(self) weakSelf = self;
  dispatch_async(dispatch_get_global_queue(QOS_CLASS_DEFAULT, 0), ^{
    // ... work
    __strong typeof(weakSelf) strong = weakSelf;
    RCTResponseSenderBlock cb = strong.callbacks[id];
    if (cb) {
      cb(@[@"result"]);
      [strong.callbacks removeObjectForKey:id];
    }
  });
}

- (void)onDestroy {
  // clear to allow JS/ObjC deallocation
  for (NSString *k in self.callbacks) {
    RCTResponseSenderBlock cb = self.callbacks[k];
    if (cb) cb(@[[NSNull null]]);
  }
  [self.callbacks removeAllObjects];
}

- (void)dealloc { [[NSNotificationCenter defaultCenter] removeObserver:self]; }
@end

Swift (bridged) uses ([String: RCTResponseSenderBlock]) with weak self and cleanup in invalidate or deinit.

Key points / reasoning:

• Never strong-capture Activity/View in long-lived async tasks — use WeakReference/weak self.
• Store callbacks in a container so you can remove/replace them; calling or nulling them allows JS GC.
• Hook lifecycle (onHostDestroy / invalidate / dealloc / UIApplication notifications) to clear pending callbacks and cancel tasks.
• For cancellable ops, keep operation tokens and cancel underlying tasks when host destroyed.
  Edge cases:
• Duplicate ids — decide replace vs queue.
• Callbacks invoked after host gone — guard with weak refs and check reactContext.hasActiveCatalystInstance.
  These patterns prevent retaining GC roots and stop memory growth.

Situation: A third‑party SDK allocates large native buffers and triggers OOMs on low‑memory devices in production.

Task: Contain the risk quickly while working toward a permanent fix with the vendor.

Action: I’d implement a layered containment strategy:

• Encapsulate SDK calls in a small wrapper/adapter so cleanup is enforced and usage is controllable. Example (Android/Java):

public class SdkAdapter {
  public Result useSdk(Request req) {
    try {
      return ThirdPartySdk.process(req);
    } finally {
      ThirdPartySdk.releaseNativeBuffers(); // call cleanup API promptly
    }
  }
}

• Enforce limits: cap buffer sizes, reduce sampling rate, or downscale inputs before handing to the SDK to limit memory consumption.
• Process isolation: run SDK in a dedicated helper process (or service) with an OS memory limit. If it OOMs, the host app stays alive. Communicate via IPC (AIDL, REST, gRPC) and restart policy.
• Degraded fallbacks: provide a safe fallback path (simpler implementation, cached results, or feature toggle) for low‑memory devices or when the helper process fails.
• Runtime protection: add monitoring (OOM/error rates, resident set size), and a circuit breaker that throttles or disables SDK use when thresholds are exceeded.
• Operational: ship feature flags, targeted rollouts, and collect heap/native metrics with logs + crash reports to identify affected devices.
• Vendor coordination: share reproducer, heapdumps, device profiles, and request fixes (memory caps, explicit free APIs, or more configurable behavior).

Result / Rationale: This minimizes user impact quickly (isolation + fallback), gives engineers observability to detect regressions, and buys time to get a vendor fix. Trade‑offs: process isolation adds IPC complexity and latency; limiting quality reduces feature fidelity — but both are preferable to app crashes.

Common leak patterns (summary)

• Android: static references to Activity/Context, anonymous/non-static inner classes (handlers, runnables, adapters) holding implicit Activity ref, unremoved listeners/broadcast receivers, long-lived caches (bitmaps, LRU caches) holding Activity-bound objects, Handler.postDelayed or AsyncTask outliving Activity.
• iOS: retain cycles via closures capturing self, strong delegate references, NSTimer/CADisplayLink not invalidated, notifications (NotificationCenter) observers not removed, long-lived singletons holding view controllers, CoreFoundation objects not bridged correctly.

Mitigation techniques (concrete)

• Prefer application context when appropriate; never store Activity/UIViewController in static singletons.
• Make inner classes static (Android) or use static nested classes + WeakReference to Activity.
• Use weak/unowned references for delegates/listeners; in Swift capture [weak self] or [unowned self] with awareness of lifecycle.
• Remove observers/listeners in onStop/onDestroy (Android) or deinit/viewDidUnload (iOS); invalidate timers.
• Use lifecycle-aware components (Android LifecycleOwner, LiveData, CoroutineScope tied to lifecycle) to auto-cancel work.
• For caches, limit size, use soft references/WeakReference (Android), NSCache (iOS) which auto-evicts.
• Avoid long-lived background tasks tied to UI objects; cancel on destroy.

Detection + investigation workflow (heap dumps & allocation tracking)

1. Reproduce leak deterministically (navigate, rotate, background/foreground).
2. Capture allocations / heap snapshot:
   • Android: Android Studio Profiler → Memory → Record allocations and trigger Heap Dump; or adb shell am dumpheap, generate HPROF and open in Android Studio or Eclipse MAT.
   • iOS: Xcode Instruments → Allocations & Leaks or VM Tracker; take heap snapshots (heapshots).
3. Analyze the heap:
   • Look at dominator tree / retained size to find top memory retainers.
   • Inspect “GC roots” / retention paths to see why object (Activity/VC) isn’t collected.
   • On Android, in MAT check “Path to GC Roots (exclude weak refs)” and use Leak Suspects report.
   • On iOS Instruments, use “Cycles & Roots” and view reference cycles; enable “Zombies” to catch over-retained objects.
4. Allocation tracking:
   • Use allocation sampling to see which code paths allocate heavy objects (bitmaps, arrays).
   • Correlate timestamps with user actions to find leaks introduced by specific flows.
5. Fix and verify:
   • Implement mitigation (weakify, remove listener, cancel tasks).
   • Re-run scenario, take new heap snapshot, compare retained sizes/heapshots to ensure object is collected.
   • Add automated leak detection: LeakCanary (Android), FBMemoryProfiler/Leaks or XCTest memory assertions (iOS), CI tests running Instruments traces.

Best practices

• Code review checklist for lifecycle and listener removal.
• Add runtime guards (WeakReference checks), lifecycle-tied scopes.
• Use memory profilers regularly, keep regression tests for memory where possible.
  This approach finds the retention root, guides a corrective code change (weak refs/remove listeners), and validates via before/after heap comparisons.