有一个数字应该让每一个瞄准「下一个十亿用户」的增长计划冷静下来。Google 与 SOASTA 测量真实移动会话后发现，页面加载超过三秒，53% 的移动访问会被直接放弃；而加载时间从一秒拉到五秒，跳出概率攀升 90%。再把这组数字和那些「下一个十亿用户」真正所在的地方放在一起看。在撒哈拉以南非洲，超过一半的移动用户仍停留在 3G；截至 2024 年，全部连接里仍有三分之一是 3G，三分之二的移动网民靠 3G 手机或功能机上网。他们为 1GB 流量平均要付出月收入的 2.4%，高于联合国定义的「可负担」门槛。你漂洋过海想拿下的那批人，恰恰是一旦出现加载转圈圈就最容易被丢掉的那种用户。

然而流量 App 在这些市场「交付体验」的默认做法，仍是丢给用户一个 WebView，指向一份远端文档，每次点击都把整个世界重新加载一遍。它活不活得过自己所依赖的网络，是个问题。

这是个结构性陷阱，不是皮肤问题

H5 或 WebView 体验建立在一个假设上：网络在场、够快、够便宜。在成熟市场的 4G 上，这个假设大体成立。在拉各斯的 3G 上、在圣保罗郊外的乡村、在雅加达通勤的列车里，它按时刻表失败。每一次导航都是一次全新请求。每一张图片、每一段脚本、每一条路由，都是一次网络可以掐断的往返。当信号一闪——而在这些网络上它闪个不停——页面变成一份没有本地记忆的空白文档。转圈圈转着，跳出率自己兑现了，而你花真金白银买来的那个用户，在你的首屏画出来之前就走了。

这不是靠更快的服务器就能解决的延迟问题。依赖是架构级的。作为你产品的那份文档住在别处，而挡在用户和你内容之间的唯一东西，是一条对这些你最想要的人来说一天里最不可靠的连接。

每种处境都不一样，且你一个都控制不了

第二个问题是，「弱网」不是一种处境。它是一个市场的 3G、另一个市场拥堵的 4G、一条列车隧道、一片乡村边缘、一部用户为了省钱在两次点击之间关掉流量的手机。每一种表现都不同，而每一种，当你的体验是一份远端网页时，都在你的 runtime 之外。重试逻辑、超时、失败模式——全由浏览器和网络决定，不由你。当连接变差，你的 App 恰恰在你最没发言权的地方退化，面对的正是耐心和数据预算都最薄的用户。

逐项对比

维度H5 / WebView（网络优先）宿主 runtime + 打包目录
弱网下首屏等远端拉取，转圈本地资源，立即绘制
导航每次点击都是新往返本地路由，不重新拉取
离线可用性空白文档，死掉内容已缓存，可用
单次会话流量成本反复重载资源资源只打包一次
宿主归属浏览器与网络拥有体验宿主拥有体验
可维护性远端文档随市场漂移每个面一个目录条目

runtime 真正改变的是什么

宿主自有的 runtime 不会发明带宽。它去掉的，是一直本该你修的那部分：那份依赖。宿主不再把一份远端文档交给用户然后祈祷网络懂事，而是把小程序打包一次，用 runtime 已经缓存好的本地资源跑起来。用户打开内容，信号掉了，屏幕仍然活着——导航是本地的，看过的 content 都在，会话扛过了会杀死网页的那一闪。

宿主也保住了要紧的东西：体验、韧性、以及关系。这和之前讲资产归属、平台可控性的几篇同源——但这里谈的是在最难保证在线率的地方保证在线。网络还是那个网络；对体验的控制权留在宿主手里。

诚实的提醒

runtime 不是信号增强器。打包与缓存去掉了你的 App 对网络在资源、导航、以及已拉取内容上的依赖，但它们造不出不存在的带宽。你仍然需要 CDN、优雅降级，以及对那些真正必须回服务器的请求老实的应对。runtime 去掉的是自己施加的网络税——你每次从一份远在三千英里外的文档重新加载自家产品时丢掉的那些会话。它不去掉最后一公里的物理限制。谁跟你说「丢个 runtime 你就处处都快」，那是在卖东西。

如果你的增长计划押在下一个十亿用户身上，问题不是他们是否在弱网上。他们就在。问题是你的架构能不能在信号一闪时保住自己的灯，还是你仍在从一条你最宝贵的用户最负担不起去信任的连接上，重载你的产品。

参考来源