El crash que mata la app completa
Incrusta un WebView y la pagina vive en el mismo proceso que tu capa nativa. Un script desbocado, un bucle de memoria o un fallo de render no solo rompe la pagina: puede llevarse toda la app. El usuario pierde tu app, no solo el contenido que abrio.
Un runtime de mini-programa aisla cada programa en su propio contenedor. Un fallo se queda donde empezo y el super-app sigue corriendo.
Que es el aislamiento por contenedor
El runtime da a cada programa un sandbox acotado: su propio presupuesto de memoria, su propio ciclo de vida y un limite de crash que no gotea al super-app. La aislacion de sitios de Chrome y el modelo de WebView por proceso de Android describen el mismo principio a nivel navegador. WeChat documenta el render independiente de mini-programas y OWASP lista el aislamiento como control base.
Donde se nota la diferencia
| Paso | WebView (proceso compartido) | Runtime de mini-programa (contenedor) |
|---|---|---|
| Alcance del crash | Toda la app | Un programa |
| Fallo de memoria | Puede matar el super-app | Acotado al sandbox |
| Recuperacion | Reiniciar la app | Reiniciar el programa |
| Radio de impacto | Todo | Un contenedor |
| Impacto al usuario | Sesion perdida | Queda en el super-app |
El resultado es un fallo que termina una pantalla, no una sesion.
Por que el confinamiento vence al destino compartido
El aislamiento significa que un programa con bugs no arrastra al super-app con el, asi el build malo de un vendedor no se vuelve tu caida. Tambien significa que la recuperacion es barata: recargar el programa, no toda la app, y el lugar del usuario en el super-app se conserva.
Como lo aplica Cross Mini App
Cross Mini App ejecuta cada programa en su propio sandbox, asi un crash se contiene a ese programa y el super-app sigue corriendo. El build malo de un vendedor se queda como problema de ese vendedor. Dejas de perder la app completa por una pagina y empiezas a aislar fallos por defecto.
Esa es la diferencia entre un crash que se propaga y uno que se detiene.
