El recuento real de procesos
«Dos procesos» es una simplificación útil que se rompe al abrir el monitor del sistema. Qué constelación monta cada motor, por qué eso hace que medir memoria sea difícil, y qué consecuencias tiene para depurar y para la seguridad.
Lo que monta cada motor
Por qué esto complica medir la memoria
El nivel 2.5 avisaba de que la memoria se mide mal casi siempre. Esta tabla explica la mitad de por qué.
Si tu aplicación monta cinco procesos y el monitor te da cinco cifras, sumarlas es incorrecto: buena parte de esas páginas están compartidas entre ellos, y sumarlas las cuenta varias veces. Si además algunos servicios se comparten con otras aplicaciones del sistema, la pregunta «cuánta memoria consume tu aplicación» deja de tener una respuesta única: depende de si cuentas lo que se habría gastado igualmente sin ti.
La comparación honesta con un motor empaquetado se hace en términos de coste marginal: cuánto crece el consumo total del sistema al abrir tu aplicación, con el sistema en un estado conocido y midiendo antes y después. Eso sí se puede medir y sí significa algo. El nivel 58 lo hace con detalle.
Qué se cae y qué sobrevive
La consecuencia práctica más útil de este recuento es la de la última fila: el contenido web vive en otro proceso, así que puede morir sin llevarse tu aplicación por delante.
Eso significa que un fallo grave en tu JavaScript —un bucle infinito que agota la memoria, un fallo del motor— deja al core vivo, con su estado intacto y su bucle de eventos funcionando. La ventana se queda en blanco o congelada, y tu aplicación puede detectarlo y reaccionar: recrear la webview, avisar al usuario, guardar lo que estuviera pendiente.
Es una propiedad que casi nadie aprovecha y que separa una aplicación robusta de una frágil. El nivel 25, cuando trate el ciclo de vida y los eventos del bucle, vuelve sobre ello.
El aislamiento como propiedad de seguridad
Hay una lectura de seguridad que conviene hacer explícita. Cuando el contenido web corre en un proceso aparte, con el sandbox del motor puesto, el atacante que consigue ejecutar JavaScript en tu webview no está dentro de tu proceso: está en un proceso vecino, aislado por el sistema operativo, cuya única vía hacia ti es el canal de mensajes.
Esa es la razón profunda de por qué el modelo de permisos de la fase V puede funcionar. Si la webview compartiera espacio de direcciones con el core, cualquier control sobre qué comandos se pueden invocar sería una formalidad: quien ejecuta código en tu proceso hace lo que quiere. Es el sistema operativo el que hace que el control sea real, y el framework se limita a decidir qué pasa por la única puerta que queda.
De ahí se sigue una consecuencia de diseño que aparecerá en el nivel 32: cualquier cosa que reduzca ese aislamiento reduce toda la seguridad del modelo, por muy bien escritas que estén las capabilities.