5.2 弱网与省电：让玩家在地铁上也能玩两局

核心结论

玩家的真实网络环境是：地铁信号断续、电梯无信号、校园网限速。手游的网络设计不是"能联机"，而是断线重连、数据补偿、包体/流量都小。省电同理——一小时掉 30% 电的游戏，玩家第二天就卸载。

弱网设计的三层策略

断线重连的正确观感：玩家网络断了，画面继续动（本地推进），顶部出现"网络连接中"；恢复后与服务端对账，多数操作无需玩家干预。这就是"地铁上也能玩"的技术底座。

省电的工程清单

在 UE 移动端，省电的所有抓手：

关键技术点：游戏暂停（非战斗）时，把 GameViewport 的 tick 频率降下来，或让渲染降频（引擎的 t.MaxFPS 后台 15 帧）。这能让"玩家接电话 10 分钟"只掉 1% 电而不是 5%。

弱网测试方法

1. 限速工具： Charles / 系统级限速（或安卓模拟器网络调节）模拟 3G/丢包环境。
2. 断网注入：脚本周期性开关网络，看客户端的反应与重连成功率。
3. 指标：重连成功率、重连耗时、弱网下同步误差。

测试标准：在 30% 丢包的模拟环境里，游戏可玩、无数据错乱、恢复后状态一致。

常见坑与解法

坑 1：切到后台再回来，连接断了但客户端不知道

原因：应用挂起时 socket 被系统断开，但游戏没主动检测。

解法：监听应用 Pause/Resume 事件，Resume 立即发心跳/重连。UE 里用 FCoreDelegates::ApplicationHasEnteredForeground 之类。

坑 2：弱网下"包洪水"（历史消息全量重发）

原因：重连时一次性请求所有缺失数据。

解法：不要补发历史，只请求当前快照（状态同步游戏）；帧同步游戏则回退一小段或补关键帧。补完整历史=更卡更费流量。

坑 3：跑流量太凶被投诉

解法：优化同步频率（重要状态变才发，别按帧发）；心跳从 30 秒一次放宽到 60~90 秒；大版本数据走 WiFi 下载。

相关节点速查

• 断线重连实现思路：见网络复制那本书的会话与生命周期篇
• 应用前后台事件：FCoreDelegates（C++）或蓝图 OnApplicationStateChanged
• 限速模拟：Charles / 系统网络共享设置

心得：弱网体验是"做了没人夸、不做人人骂"的工程。我们项目上线前做了一周"地铁通勤测试"——团队成员每天上下班在地铁上玩自己开发的游戏，收集真实弱网体感。这种土办法比任何模拟器数据都真实。