Mobile Platform Internals & Resource Management Questions

Overview — when to prefer what

• AsyncTask / HandlerThread (legacy)

  • Use only for maintaining or quickly patching old code. AsyncTask tied to Activity lifecycle (memory leaks), single-threaded defaults, poor cancellation semantics. HandlerThread gives you a dedicated Looper/Thread — manual lifecycle, synchronization and thread-safety are developer responsibilities.

• Coroutines (Kotlin)

  • Best for short-lived UI tasks and general asynchronous work. Use CoroutineScope tied to lifecycle (viewModelScope, lifecycleScope) for structured concurrency and easy cancellation. Concurrency: choose Dispatchers.IO for blocking I/O, Dispatchers.Default for CPU; use async/await for parallelism and withContext for context switching.

• Kotlin Flow

  • Use for reactive streams (UI state, continuous updates). Flows are cold, support backpressure, operators for transformation, and can be collected on specific dispatchers. Concurrency via flatMapConcat/Latest/Merge and buffer().

• WorkManager

  • Use for guaranteed/background and periodic jobs (tasks that must run even after app exits or device reboot). Handles constraints, retries, backoff, and scheduling. Concurrency: can be enqueued as unique/parallel chains; runs on background executor — avoid long-running foreground tasks without START_FOREGROUND_SERVICE pattern.

Mapping to scenarios

• Short-lived UI fetch/update: coroutines + lifecycleScope (or Flow for streaming)
• Guaranteed background (upload, DB sync, retries after reboot): WorkManager
• Periodic jobs: WorkManager PeriodicWorkRequest
• Long-running single thread task: HandlerThread if low-level control required, prefer coroutines with a single-threaded Dispatcher

Concurrency implications

• Structured concurrency (coroutines) reduces leaks and races; make sure to cancel scopes on destroy.
• WorkManager isolates scheduling from app process; less control over exact execution time.
• Legacy threads require explicit synchronization and risk leaks.
• Always confine UI updates to Main dispatcher and protect shared mutable state (Mutex, synchronized, or use immutable Flow/StateFlow).

Step-by-step debugging approach (high level)

1. Reproduce and narrow scope — identify OS versions, OEM models, exact app flow (cold start? foreground? permission prompt?), and whether crash occurs on first preview start or after switching cameras.

Collect logs & artifacts

• adb logcat -b all > logcat.txt (capture before reproducing; include timestamps)
• adb bugreport > bugreport.zip (includes system dumps, stack traces)
• Pull tombstones: /data/tombstones/ (adb pull) for native crashes
• dmesg and vendor camera HAL logs if available
• Capture ANR traces and a screen recording to show steps

Emulator vs physical device

• Use emulator for fast iteration but expect differences: no vendor HAL, different camera implementation. Always verify on affected physical devices; replicate on lowest-common API level and vendor image.

Repro strategies

• Minimize app to a small sample that starts Camera2 preview
• Toggle preview sizes, rotate, switch cameras, background/foreground cycles
• Add extensive logging around CameraDevice/Session callbacks and exceptions

Camera-specific pitfalls

• Unsupported preview sizes / format → IllegalArgumentException when creating session
• TextureView/SurfaceTexture lifecycle — ensure surface is available before creating session
• Concurrent camera/device resource conflicts (other apps, permissions)
• Vendor-specific HAL bugs; different behavior for YUV_420_888, PRIVATE, etc.

Mitigations & compatibility

• Validate supported sizes with StreamConfigurationMap at runtime; choose closest match
• Guard lifecycle: wait for SurfaceTexture.isAvailable and handle SurfaceHolder callbacks
• Fallbacks: gracefully degrade preview resolution, catch and report exceptions, retry with exponential backoff
• Use CameraX as a compatibility layer — it handles many vendor quirks, lifecycle, and size selection; still test on affected devices and enable experimental use cases if needed

Outcome

• Reproduce on device, collect artifacts, identify whether app-level misuse (size/surface) or vendor HAL bug, then apply size/surface fixes or use CameraX/fallbacks and file a vendor bug with collected logs.

Overview of threads

• JS thread — single-threaded JavaScript runtime (Hermes/V8). Executes React reconciliation, business logic, JSON parsing, timers, and sends bridge messages to native.
• Native main thread(s) — platform UI threads (iOS main thread, Android UI thread) that measure/layout/draw views and run native APIs. Also contains other native threads (render, input).
• Shadow threads — legacy React Native term for layout/layout-only work done off the main thread (Yoga layout engine runs on a separate “shadow” thread to compute layouts before syncing to UI).

Common causes of UI jank tied to threading

• Long-running JS tasks (heavy parsing, synchronous loops, large setState churn) block the JS thread so frames miss deadlines.
• Blocking the native main thread (synchronous native module calls, heavy drawing) prevents frame updates.
• Excessive bridge traffic (many small messages) saturates serialization and causes delays.
• Animations driven on JS (requestAnimationFrame) get starved when JS thread is busy.

Concrete strategies to reduce JS-thread-induced jank

• Offload heavy CPU tasks: move JSON parsing, image processing, cryptography to native modules or background workers (JS WebWorkers / JSI-based threads).
• Use Hermes for faster startup and lower GC pauses; enable proguard/production builds.
• Minimize bridge chattiness: batch updates, send structured payloads, avoid per-frame bridge messages.
• Use native-driven animations (Animated API with useNativeDriver / Reanimated v2 with JSI) so the UI thread/renderer animates without JS involvement.
• Defer non-urgent work: InteractionManager.runAfterInteractions, requestIdleCallback polyfills, or prioritize with setImmediate.
• Optimize rendering: memoize components (React.memo, useMemo), avoid anonymous inline functions/objects, reduce re-renders, use FlatList with virtualization and getItemLayout.
• Profile and measure: use Flipper, Systrace, React DevTools profiler to find JS/bridge hotspots and GC pauses.
• Reduce GC pressure: reuse objects/arrays, avoid excessive allocations inside animation loops.

These steps focus on keeping the JS thread free for critical work and moving animation/CPU-heavy tasks off it so the app maintains 60fps/90fps on target devices.

Approach summary (mobile dev perspective)
I’d build a hybrid client-driven + server-assisted sync that tolerates OS background limits, unreliable networks, and app updates by combining platform background APIs, push wake-ups, idempotent server endpoints, robust retry/backoff, deterministic conflict resolution, and strong observability.

Client scheduling (Android / iOS)

• Android: Use WorkManager with setRequiredNetworkType and ExpeditedWork when possible; mark tasks as unique by name so OS coalesces them. Respect Doze by using JobScheduler/WorkManager which the OS honors.
• iOS: Use BackgroundTasks (BGAppRefreshTask/BGProcessingTask) for periodic sync; use NSURLSession background uploads for large ops.
• Both: Attempt opportunistic sync when app foregrounds or network becomes available via Network callbacks.

Push wake-ups

• Use high-priority FCM / APNs silent pushes to trigger short sync windows. Include a minimal payload (sync type + server change token). Fallback: notify user to open app when silent push blocked.

Retry, backoff, jitter

• Exponential backoff with randomized jitter (full jitter) for retries. Cap max backoff and switch to server-driven retry-after when provided. Persist retry state across app restarts and updates.

Server: idempotency & change tracking

• All write endpoints accept idempotency-token (UUID) and return operation id + status.
• Server maintains logical change log / incremental sync tokens and tombstones for deletes. Support snapshot/version numbers for clients to request deltas.

Conflict resolution

• Prefer CRDTs for mergeable domain data. Otherwise: combine server-authoritative resolution (merge rules), last-writer-wins with vector clocks or per-field merges. Surface unresolved conflicts to client UI for user resolution when semantics require.

App updates & schema migrations

• Versioned payloads, feature flags, and server-side backward compatibility. Client includes schema version; server returns migration hints or rejects with clear error to trigger upgrade.

Observability

• Emit metrics: sync success/failure rates, latency, retries, conflict counts. Log per-operation ids, idempotency tokens, and device ids (hashed). Trace end-to-end with distributed tracing (trace id in pushes/requests). Alert on rising failure/conflict trends and long delta lag. Provide dashboards and debug endpoints for forced re-sync.

Why this works
Combines platform-friendly scheduling, minimizes wasted work via idempotency and tokens, reduces user-visible conflicts via merge strategies, and gives ops the signal to detect and remediate sync problems.

Approach (brief)
Explain routing with a stable routing key (deep link or screen id) in the push payload, handle app lifecycle on device, and validate/untrust payloads before navigation.

Backend payload design — examples

• APNs (iOS) — include custom data under aps and custom keys:

{
  "aps": { "alert": { "title": "New message", "body": "Tap to open" }, "badge": 1, "sound": "default" },
  "route": "chat",
  "route_id": "12345",
  "sender_id": "alice"
}

• FCM (Android) — use data for custom routing (use data-only for consistent delivery):

{
  "to": "...",
  "data": {
    "route":"chat",
    "route_id":"12345",
    "sender_id":"alice"
  },
  "notification": { "title":"New message", "body":"Tap to open" } // optional
}

Prefer data payloads (FCM) or silent pushes + local display to ensure consistent handling.

Including deep-links / routing identifiers

• Use a canonical routing key (e.g., route, route_id, params JSON).
• Optionally include full URI deep-link (myapp://chat/12345) for direct navigation across platforms.
• Keep keys small and versioned (route_v=1) for future changes.

App lifecycle behavior

• Foreground: system may not show banner (iOS); handle notification in-app callback and navigate immediately after validation.
  • iOS: userNotificationCenter:willPresentNotification
  • Android: onMessageReceived when app in foreground (data message)
• Background / Not running:
  • Tapping notification launches app with original payload via launch options (iOS) or intent extras (Android). Parse payload in initial routing code (scene:willConnect / activity intent).
  • If using silent pushes to fetch content, ensure you present a visible notification after fetching.
• Note: iOS may coalesce/modify payload; FCM notification messages are handled by system tray and may not include data to app when killed—use data-only or both notification+data carefully.

Security & validation

• Treat all payload fields as untrusted. Validate IDs server-side before navigation.
• Don’t include sensitive data in payloads (tokens, PII). Fetch details from backend once app is opened using authenticated API calls.
• Protect deep-link handlers: require authentication checks and fallback flows (login screen) if user not authorized.
• Prevent injection: canonicalize route strings, whitelist allowed routes, and avoid executing payload as code.
• Rate-limit automatic navigations to avoid UX abuse and phishing-like flows.

Implementation notes (mobile dev best practices)

• Centralize notification parsing and routing in one place (NotificationRouter).
• Add telemetry: record notification-impression, tap, and routing success/failure.
• Test across OS versions and cold start scenarios.