你没要的那台引擎
打开一个 WebView，你就打开了一个浏览器。Android 自己的文档称 WebView 本质上是"一个功能齐全的浏览器引擎（Chromium）"，有"庞大的内存占用和复杂的多进程架构"。你没想在 App 里再塞一个浏览器；你只是想显示一个页面。然而这个成本无法避免：引擎、它的 JavaScript 运行时、它的渲染器、它的缓存，全都在你内容的第一个像素出现之前就加载了。
整台引擎的代价
数字并不含蓄。Android 的 WebView 指南提到渲染进程是隔离的，它的内存"单独计算"——也就是说你性能分析器里看到的头条数字，低估了真实成本。独立工程测量显示，单个 WebView 实例在简单页面上就要 60–150 MB，复杂页面 200 MB 以上；iOS 上的 WKWebView 在简单列表约 60–100 MB，媒体重页面 150–200 MB。光是一个空白页，在 Android 上就要 60–80 MB，iOS 上 50–70 MB，你的代码都还没跑。
把这个乘以标签页、乘以后台页面、乘以很多 H5 页面打包进去的重型 JavaScript 框架，一台中端设备——正是新兴市场大多数用户实际拿着的那台——的预算就没了。内存压力触发系统的 OOM Killer 或 iOS 每进程硬性上限，页面或 App 就死了。这些内存没有一分是在做你的程式要求的工作；那是引擎在空转。
轻量的替代方案
小程序运行时反转了这个模型。平台保留一个共享的、预热过的引擎，只为每个程式生成它需要的：一个逻辑层、一个轻量视图层，以及在用的具体页面。没有每个屏幕一台独立完整浏览器，没有你必须手动销毁的独立重型渲染器，没有每次启动都从零拉起的 V8/JIT 栈。因为运行时是通用的、由宿主预加载的，一个程式来时已经是温的——WebView 每次启动都要付的冷启动税，大部分被平台吸收了。
双线程的拆分让节省翻倍：业务逻辑和渲染分离，所以一次长计算不会卡住帧预算，只有变化的数据过桥。结果就是，每个程式的内存包络比等价的 WebView 屏幕更小、更可预测。
电量是内存沉默的孪生兄弟
内存只是故事的一半。一台完整引擎在独立进程里跑 JIT 编译、布局、绘制，让 CPU 和 GPU 忙个不停，而忙碌的 CPU 就是耗电的电池。基于 WebView 的 H5 页面每次访问都重新拉取、重新解析、重新渲染，让设备长时间工作，而原生或运行时表面早该安定下来了。相比之下，小程序把外壳留在本地，只重绘增量，于是设备做得更少、也更凉。
对于那些设备可用存储有限、电池受限的用户——正是新兴市场的画像——这个区别，就是"会话撑得住"和"用户弃用"的区别。更少内存、更少耗电、同一硬件上更长的会话。
这对会话意味着什么
实际结论是：运行时让宿主能跑很多小程式，而不必在一台重型浏览器上再叠一台，于是 App 保持响应、电池也能撑住。Cross Mini App 就是那个通用、预热过的运行时——一个引擎在 catalog 上共享，每个程式生而为轻。你交付广度，而不必堆叠引擎。
