feat(ios): report app peak memory from MetricKit

Abierto
  • ¿Algo no está bien?
#254 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
52/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
ios, kotlin
Área
documentation, mobile-dev, observability

Línea de trabajo

Comienza con AppExitMetricsCollector y la implementación existente de countMetric del puente de iOS; compara la estructura solicitada de distributionMetric con SentryMetricEmit.kt en Android. Revisa la inyección de atributos del dispositivo de #250 y el debate sobre el consentimiento en docs/BENCHMARKING.md. La tarea estará terminada cuando las dos distribuciones de memoria de MetricKit se emitan con los atributos centrales y se documente la salvedad de que abarcan toda la aplicación.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

On Android we now report the backend process's memory footprint as Sentry gauges (#249), including rss_peak_bytes — the peak the low-memory killer scores the process on. iOS deliberately emits only the JS-heap gauges: the process-level pair is gated off because Node runs inside the app process there, so any process number would describe the whole app, UI included.

But the whole-app number is still worth having on iOS — the OS kills the app on memory just as Android does — it just has to come from a different source, for two reasons:

  1. Node cannot see the right number on iOS. The iOS kill decision ("jetsam") is made on memory footprint — dirty memory plus compressed memory, the figure Xcode's memory gauge shows — not on resident set size. What Node's process.memoryUsage.rss() reports on iOS is resident size, which falls as the OS compresses pages while the footprint that determines the kill keeps counting them. Under memory pressure, exactly when the number matters, RSS is misleading. Node has no API for footprint.

  2. It must not share a metric name with the Android backend gauges. comapeo.backend.rss_bytes means "the backend process" on Android. An iOS value under the same name would mean "the whole app", and any cross-platform query would silently mix the two.

Proposal

MetricKit — the iOS framework we already consume for exit reasons in AppExitMetricsCollector — delivers MXMemoryMetric in the same daily payloads, with peakMemoryUsage measured by the OS as actual footprint (the jetsam-relevant quantity), plus averageSuspendedMemory (memory held while backgrounded, which speaks to background survival). No in-process sampling needed.

Wire these through the existing collector as app-level distributions, e.g.:

  • comapeo.app.peak_memory_bytes — from peakMemoryUsage
  • comapeo.app.suspended_memory_bytes — from averageSuspendedMemory

They pick up platform / device_class / os_major from the centralised injection added in #250, and pair naturally with the iOS exit reasons delivered in the same payloads — the way comapeo.backend.rss_peak_bytes pairs with comapeo.app.exit.rss_bytes on Android: one says what the app grew to, the other what it died holding.

Implementation notes:

  • The iOS bridge currently exposes only countMetric; a distributionMetric equivalent (same device-attribute injection and scrub) is needed. SentryMetricEmit.kt on Android is the shape to mirror.
  • MetricKit payloads are daily aggregates for the previous day, so these are slower-moving than the Android gauges — fine for fleet percentiles, not for boot-time analysis.
  • Caveat to document: the metric describes the whole app, so backend regressions show up diluted by UI memory; the JS-heap gauges remain the backend-specific signal on iOS.
  • Consent tier: propose diagnostic, matching the other memory gauges (daily aggregate, names nothing the user did) — needs the same second-opinion review the #249 tier decision got in docs/BENCHMARKING.md.

Depends on #250 (device-attribute injection in the native bridges).

Lenguaje dominante
Kotlin
Estrellas
1
Forks
0
Merge medio
1 d 6 h
PR fusionados (30 d)
5

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de digidem/comapeo-core-react-native

Todos los issues de digidem/comapeo-core-react-native

Issues similares

Más issues de Kotlin

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.