Bloqueo de la app: qué es, causas de cierres inesperados y métodos de detección

Qué es un bloqueo de la aplicación

Bloqueo — una terminación inesperada del programa causada por una situación excepcional que el código no manejó. En los sistemas operativos móviles, un bloqueo provoca el cierre inmediato de la aplicación y muestra una pantalla de “Aplicación detenida” o regresa a la pantalla de inicio.

Los bloqueos se dividen en dos grandes clases. Errores manejados — los bloques try/catch capturan la excepción, la aplicación continúa funcionando, posiblemente con pérdida de funcionalidad. Bloqueos no manejados — la excepción asciende hasta el nivel del sistema operativo y el sistema mata el proceso. El segundo tipo es especialmente peligroso porque el usuario no puede guardar datos.

Un sistema con dos millones de usuarios y una tasa de bloqueos del 0.1% pierde 2,000 usuarios en cada lanzamiento. Según Google Play Console (2024), las aplicaciones con una tasa de bloqueos superior al 1.5% son excluidas de las recomendaciones y pierden hasta el 30% del tráfico orgánico.

Principales causas de cierres en aplicaciones móviles

NullPointerException (NPE) — el rey de los bloqueos en Java/Kotlin. Intento de llamar a un método sobre un objeto null. En Kotlin, NPE es menos común gracias a la seguridad contra nulos (null safety), pero aún es posible al usar el operador !! o al interactuar con código Java. Google (2024) estima que NPE representa el 25% de todos los bloqueos de aplicaciones Android.

IndexOutOfBoundsException — acceso a un elemento de una lista con un índice inexistente. Causa frecuente: los datos llegan del servidor en un formato inesperado y la interfaz intenta mostrar una posición que no existe. Solución — siempre verifica el tamaño de la colección antes de acceder por índice.

ANR (Application Not Responding) — un problema específico de Android. El hilo de la interfaz de usuario se bloquea durante más de 5 segundos. Causas principales: solicitudes de red en el hilo principal, cálculos pesados, sincronización con la base de datos. StrictMode en Android ayuda a detectar el bloqueo del hilo de la interfaz durante el desarrollo.

OutOfMemoryError (OOM) — la aplicación superó el límite de memoria. En dispositivos móviles con 2–4 GB de RAM, OOM es un problema común al trabajar con imágenes grandes o listas infinitas sin paginación. Solución — Glide/Coil para cargar imágenes, LruCache para almacenamiento en caché, ViewHolder en RecyclerView.

Excepciones de ejecución y errores fatales

Excepciones de ejecución — errores que el compilador no verifica durante la compilación. Solo aparecen cuando el código se ejecuta en un dispositivo específico con datos específicos. En Java, son RuntimeException y sus subclases: NullPointerException, IllegalArgumentException, ArithmeticException.

Errores fatales (FATAL) — no son de ejecución, sino fallos del sistema. Signal 11 (SIGSEGV) — violación de segmentación de memoria en código nativo. Signal 6 (SIGABRT) — terminación anormal provocada por la propia aplicación mediante abort(). Estos bloqueos son difíciles de diagnosticar porque el stack trace a menudo no muestra un contexto claro.

En iOS, las causas principales son NSInvalidArgumentException (nil inesperado en un parámetro) y EXC_BAD_ACCESS (acceso a memoria liberada). Swift ha reducido la cantidad de bloqueos en comparación con Objective-C, pero los errores en el runtime de ObjC y las bibliotecas C todavía provocan caídas.

Monitoreo y recopilación de registros de bloqueos

Firebase Crashlytics — el estándar para aplicaciones móviles. Recopila automáticamente stack traces, agrega registros, ID de usuario y metadatos del dispositivo. Agrupa los bloqueos por firma (clase de error + línea). Alertas en tiempo real — notificaciones cuando la tasa de bloqueos supera un umbral definido (por ejemplo, >0.1% por hora).

Sentry — una alternativa con capacidades más flexibles. Permite crear contextos personalizados, agregar breadcrumbs (eventos precedentes), configurar el filtrado en la aplicación para excluir errores sin importancia. Source maps para Kotlin y Swift permiten ver el código fuente en lugar de nombres ofuscados.

Mejores prácticas para registros: envía metadatos clave antes de realizar una operación peligrosa — así el registro mostrará lo que el usuario estaba haciendo antes del bloqueo. Agrega claves personalizadas (número de versión de la API, última pantalla, tamaño de los datos de entrada). Esto convierte un stack trace inútil en información procesable.

Ejemplo: configuración de Crashlytics en Android

class PaymentViewModel : ViewModel() {
    fun processPayment(amount: Double) {
        crashlytics.setCustomKey("last_screen", "payment")
        crashlytics.setCustomKey("amount", amount)
        try {
            api.charge(amount)
        } catch (e: Exception) {
            crashlytics.recordException(e)
        }
    }
}

Estrategias de prevención de bloqueos

Optional binding y null safety — en Kotlin usa `?` para tipos anulables, `let` y `?:` para el manejo seguro de null. En Swift — optionals y guard let. Kotlin moderno (2024) agregó anotaciones Contract: `@ContractsDsl` permite declarar que una función no devuelve null, y el compilador lo verifica.

Manejo de errores en redes — cada solicitud de red debe manejar tiempos de espera, errores de análisis y fallos del servidor. Retrofit con tipo Result — una clase sellada que garantiza que el error será manejado. Estilo sin excepción: en lugar de try/catch, usa Result sellado para el manejo explícito de éxito y error.

Feature flags — desactiva funcionalidades problemáticas de forma remota sin lanzar una nueva versión. Si una operación del servidor provoca un bloqueo en dispositivos antiguos, el flag la desactiva para ese grupo. Firebase Remote Config permite cambiar el comportamiento de la aplicación sin publicar en la tienda.

Implementación gradual — lanza una nueva versión al 5% de la audiencia y monitorea la tasa de bloqueos. Si la tasa se mantiene por debajo del objetivo (generalmente <0.1%), expande al 25%, luego al 50% y luego al 100%. Google Play Console y App Store Connect admiten lanzamientos escalonados para la detención automática cuando se supera el umbral.

Plan de acción ante la detección de un error

Paso 1: Clasificación — determina la gravedad: Crítico (bloqueo en >1% de los usuarios), Alto (0.1–1%), Medio (<0.1%). Para bloqueos críticos — respuesta inmediata. Para los demás — proceso estándar de corrección de errores en el sprint actual. Google Play Console clasifica automáticamente los bloqueos por el número de usuarios afectados.

Paso 2: Análisis del stack trace — abre el registro en Crashlytics, verifica la ubicación exacta del fallo. Revisa las claves personalizadas: qué pantalla, qué datos, versión del SO. Correlaciona con el último despliegue — a menudo un bloqueo es causado por un cambio reciente en el código que afectó un escenario de uso inesperado.

Paso 3: Reproducción — intenta reproducir el bloqueo en un dispositivo o emulador con parámetros similares. Si no lo logras, revisa el registro de bloqueos en busca de patrones: modelos específicos (Samsung A10), versiones de Android (API < 26), configuraciones regionales. Solución — agrega una condición defensiva que cubra el escenario.

Paso 4: Corrección y monitoreo — lanza un hotfix con prioridad. Después del lanzamiento, asegúrate de que la tasa de bloqueos para este tipo caiga a cero. Escribe una prueba de regresión que cubra el escenario del bloqueo. Sin una prueba, el mismo error puede regresar en la próxima refactorización.