有人告诉你 WebView「只是一个视图」。它不是。它是一整套 Chromium 浏览器引擎——和 Chrome 背后那套一模一样——跑在你的原生 App 之上。在 12GB 内存的旗舰机上你可能永远察觉不到；但在撑起你流量 App 主力的 3–4GB 设备上，这套第二引擎是你为每个屏幕悄悄交的税：它偷走的内存、耗掉的电量、掉落的帧。
WebView 是「多进程浏览器」，不是控件。 Android 官方文档说得很直白：「因为它本质上是一套全功能浏览器引擎（Chromium），有显著的内存占用和复杂的多进程架构。」WebView 把工作拆到你的 App 浏览器进程和一个独立的沙箱渲染进程里；它的大部分内存——DOM 树、JavaScript 运行时、已渲染图形——都住在原生内存里，而原生内存「可以静默涨到 GB 级」，连 Java 堆转储都抓不到。更糟的是，原生内存不像 Java 堆那样有上限；它一旦填满 RAM，Android 的 Low Memory Killer（低内存杀手）就开始杀后台进程，最终甚至可能杀掉前台 App。文档警告：让 WebView 实例处于未管理状态「会导致内存泄漏、OOM 崩溃和性能下降」，而且你必须显式调用 destroy()，否则原生资源可能比预期挂留得久得多。
实测差距很大。 2026 年针对中端机的独立基准测试显示，WebView 封装的内存是 85–320 MB，而同等原生实现仅 12–65 MB；冷启动 1.2–2.8 秒 对比 0.18–0.28 秒；持续帧率 30–45 fps（老设备掉到 15–20 fps） 对比稳定的 60 fps；活跃使用时的电量消耗 120–180 mAh/小时 对比 45–65 mAh/小时。当用户最常点的就是这块屏幕时，这些没有一项是四舍五入的误差。
你的用户就活在低端机上。 Android Go——Google 面向受限硬件的轻量版——驱动着 180+ 国家、16000+ 机型，而到 Android 16（Go 版，2025 年末）已覆盖至 4GB RAM 的设备。在价格敏感市场，3–4GB RAM 的手持设备占主导。在这种设备上，一个 140MB 的 WebView 不是「待着不动」——它和你的 App、和系统在仅有的 RAM 里抢资源，逼着低内存杀手去回收内存，还可能让用户丢掉 App 内的状态。流量 App 最需要在这些市场赢，而 WebView 税恰恰在这里收得最狠。
运行时用原生渲染，所以按原生费率交税。 宿主自有 runtime 不会再起一套第二浏览器引擎。它用平台自己的 UI 工具包渲染，于是内存、电量、帧率节奏都跟着设备的原生预算走：在用户手里真实的硬件上 60fps、没有第二引擎抢 RAM、没有静默原生内存增长等着触发 OOM。税消失了，因为那套第二引擎根本没启动。
WebView 的第二引擎 vs 宿主自有 runtime
| 维度 | WebView（原生之上的 Chromium） | 宿主自有 runtime |
|---|---|---|
| 引擎模型 | 原生之上再叠一套浏览器引擎 | 仅用原生 UI 工具包 |
| 内存（中端机） | 85–320 MB | 12–65 MB |
| 冷启动 | 1.2–2.8 秒 | 0.18–0.28 秒 |
| 帧率 | 30–45 fps（老机 15–20） | 稳定 60 fps |
| 电量（活跃） | 120–180 mAh/小时 | 45–65 mAh/小时 |
| 低端机风险 | LMK 杀状态、OOM | 原生预算、无第二引擎 |
