Te dijeron que una WebView es «solo una vista». No lo es. Es un motor de navegador Chromium completo — el mismo que hay detrás de Chrome — corriendo encima de tu app nativa. En un teléfono tope de gama con 12 GB de RAM, tal vez nunca lo notas. En los dispositivos de 3–4 GB que son la mayoría de tu audiencia de app de tráfico en mercados emergentes, ese segundo motor es un impuesto silencioso que pagas en cada pantalla: RAM que roba, batería que drena, fotogramas que cae.

WebView es un navegador multiproceso, no un widget. La propia documentación de Android es clara: «porque es esencialmente un motor de navegador de todas las funciones (Chromium), tiene una huella de memoria significativa y una arquitectura multiproceso compleja». Una WebView reparte el trabajo entre el proceso navegador de tu app y un proceso renderizador aislado en sandbox; la mayor parte de su memoria — el árbol DOM, el runtime de JavaScript, los gráficos renderizados — vive en memoria nativa que «puede crecer en silencio hasta gigabytes» y ni siquiera aparece en un volcado de heap de Java. Peor aún, la memoria nativa no tiene tope como el heap de Java; al llenar la RAM, el Low Memory Killer de Android empieza a terminar procesos en segundo plano y puede acabar matando la app en primer plano. Los documentos advierten que dejar instancias de WebView sin gestionar «puede causar fugas de memoria, fallos por OOM y rendimiento degradado», y que debes llamar explícitamente a destroy() o los recursos nativos pueden quedar mucho más tiempo del esperado.

La brecha medida es grande. Los benchmarks independientes de 2026 en dispositivos de gama media sitúan a un contenedor WebView en 85–320 MB de memoria frente a 12–65 MB de una implementación nativa equivalente; arranque en frío de 1.2–2.8 segundos frente a 0.18–0.28 segundos; tasa de fotogramas sostenida de 30–45 fps (bajando a 15–20 fps en dispositivos antiguos) frente a un estable 60 fps; y consumo de batería de 120–180 mAh/h frente a 45–65 mAh/h en uso activo. Nada de eso es un redondeo cuando la pantalla es la que el usuario toca más.

Tu audiencia vive en la gama baja. Android Go — la edición ligera de Google para hardware limitado — impulsa más de 16.000 modelos de dispositivos en 180+ países, y desde Android 16 (Go edition, finales de 2025) cubre dispositivos con hasta 4 GB de RAM. En mercados sensibles al precio dominan los terminales de 3–4 GB de RAM. En tal dispositivo, una WebView de 140 MB no se queda quieta — compite con tu app y con el sistema por la poca RAM disponible, empuja al Low Memory Killer a reclamar memoria y puede costarle al usuario su estado dentro de la app. Los mercados donde una app de tráfico necesita ganar son justo donde el impuesto WebView se cobra con más fuerza.

Un runtime renderiza de forma nativa, así que paga la tarifa nativa. Un runtime propio del host no levanta un segundo motor de navegador. Renderiza con el propio kit de UI de la plataforma, así que la memoria, la batería y el ritmo de fotogramas siguen el presupuesto nativo del dispositivo: 60 fps en el hardware que realmente está en manos de los usuarios, sin un segundo motor comiendo RAM, sin crecimiento nativo silencioso esperando provocar un OOM. El impuesto desaparece porque el segundo motor nunca arrancó.

El segundo motor de WebView vs un runtime propio del host

DimensiónWebView (Chromium sobre nativo)Runtime propio del host
Modelo de motorSegundo motor de navegador sobre nativoSolo kit de UI nativo
Memoria (gama media)85–320 MB12–65 MB
Arranque en frío1.2–2.8 s0.18–0.28 s
Fotogramas30–45 fps (15–20 en antiguos)Estable 60 fps
Batería (activo)120–180 mAh/h45–65 mAh/h
Riesgo en gama bajaLMK mata estado, OOMPresupuesto nativo, sin segundo motor

Fuentes