Calling it a «WebView» hides what it is. It is not a cheap rectangle that draws your HTML; it is a full browser engine loaded into memory — and a traffic app that opens one per hosted mini-program is paying that engine's rent over and over. The bill arrives as a blank screen, a relaunch, and a user who does not come back.
Two platforms, the same tax
On Android, Google's own documentation is blunt: WebView «has a significant memory footprint» because it is essentially a full Chromium browser engine with a complex multi-process architecture. Web content runs in a separate sandboxed renderer process; the app process only hosts the view and the browser-side logic. On iOS, every WKWebView spins up its own WebContent process. As the mobile reliability firm Embrace puts it, creating a WebView means «launching another application within your mobile app and adding two additional processes.» There are no economies of scale: one WebView is three OS processes, two are five, three are seven. The more you create, the more sluggish — and the closer to a kill.
The numbers are not small
A blank WebView is not free. Measured footprints put a blank page at roughly 50–80 MB on Android and 50–70 MB on iOS; a simple list at 100–120 MB / 80–100 MB; an e-commerce detail page at 150–200 MB on Android and 120–150 MB on iOS; a live-stream or SPA screen at 180–300 MB. Google's MemoryLab exercise shows a renderer process jumping to about 55 MB after just a few JavaScript allocations. A documented stress test of a mini-program platform found each WebView instance is a separate WebKit process carrying an 80–150 MB baseline — «this overhead is WebKit's, not ours, and no flag makes it smaller.»
The crash you can't reproduce
This is where it turns into a stability incident. In that same mini-program stress test on an iPhone 15 release build, one backgrounded WebView was stable, five were stable, but ten were jetsammed — killed by the system within about a second, with total host memory around 1.0–1.2 GB. The projection is brutal on smaller devices: an iPhone SE (3rd gen, 4 GB) sustains only one or two; an SE (2nd gen, 3 GB) sustains zero or one. On iOS, exceed the WebContent process's hard memory cap and the system kills it with no negotiation — the user sees a white screen. On Android, the low-memory killer terminates the renderer independently, and without handling you get the same blank screen on return. Embrace's rule of thumb: never keep more than two WebViews in memory for a carousel. For a traffic app hosting hundreds of merchant screens, one heavy page is enough to OOM the whole app — forced relaunch, lost session, lost cart, churn.
The runtime fix
A host-owned runtime refuses to spin up a full browser engine for every program. Instead of each mini-program being its own heavy WebView process, the runtime pools and recycles a bounded set of views, shares a rendering process where the platform allows, and gives the common lightweight program — a checkout, a form, a content card — a far smaller footprint through a single shared runtime context rather than N independent engines. The host enforces a memory budget per mini-program and across the catalog, recycles instances instead of leaking them, and degrades gracefully instead of being jetsammed. One merchant's heavy page stops being able to take the whole app down with it.
| Dimension | WebView | Host-owned runtime |
|---|---|---|
| Cost per screen | Full engine; 50–200+ MB each | Shared runtime; bounded, pooled |
| Scaling | No economies; N engines = N× overhead | One shared context; capped per program |
| Worst case | Jetsam / renderer kill → white screen | Budget enforced; graceful degradation |
| Blast radius | Whole app OOM from one heavy page | Isolated per mini-program |
| Instance lifecycle | Leaks if not destroyed by hand | Pooled, recycled by the host |
The through-line of this series is control. A WebView lets you open a screen but hands the memory bill — and the crash — to the operating system. A runtime lets you set the budget yourself. For a platform whose catalog is hundreds of other people's pages, that budget is the line between a smooth app and a white screen on a best-selling phone.
Sources
- Android Developers: WebView and memory — WebView is a full Chromium engine with significant footprint and a separate sandboxed renderer process.
- Embrace: Why WKWebView is so heavy and leaks — each WebView launches another app within yours plus two extra processes; no economies of scale; cap carousels at two.
- MentraOS: mini-program WebView stress test (10 WebViews jetsammed in ~1s) — each instance is a separate WebKit process at 80–150 MB baseline; iPhone SE-class devices sustain 0–2.
- Juejin: WebView memory governance and OOM in production — measured footprints by page type; single instance 80–150 MB, complex 200 MB+; iOS hard cap kills the process.
- iOS OOM治理: Jetsam原理与内存峰值优化 — WKWebView's WebContent process has a stricter memory limit and is killed independently, surfacing as a white screen / crash to the user.
