Page 144 - Web性能权威指南

上再次传输数据将导致额外的延迟，这个延迟在最新的网络上可能有几百 ms，而在
3G 或 2G 网络上最多则可能达到几秒。

换句话说，尽管网络会给人一种我们的应用永远在线的错觉，但由 RRC 控制的物
理层（也就是无线模块）会不断连接和断开。表面上看这不是什么问题，但这种由
RRC 交互导致的延迟，如果不加重视的话，很可能会打断用户体验。

8.3.2 解耦用户交互与网络通信

设计得好的应用，即便底层连接慢或者请求时间长，通过在 UI 中提供即时反馈也能
让人觉得速度快。不要把用户交互与网络通信联系得太过紧密。为给用户最佳体验，
应用必须在几百 ms 内响应输入，具体参见 10.2.1 节“速度、性能与用户预期”。

如果必须发送网络请求，那么在后台发，但要对用户输入立即给出反馈。单单控制
面延迟一项，经常就可以让你提供实时反馈的计划超出预算。因此要针对高延迟做
足准备，虽然不能“解决”核心网络和 RRC 带来的延迟，但你可以与设计团队合
作，确保他们在设计应用时了解这些限制。

8.4 面对多网络接口并存的现实

用户不喜欢速度慢的应用，但由于短暂网络错误导致的应用崩溃才是体验最差的。
我们的移动应用必须足以应对各种常见的网络错误：无法访问的主机、吞吐量突然
下降或延迟突然上升，甚至连接彻底断开。与有线网络不同，你不能假定一次连接
成功就能持续保持连接状态。用户可能正在移动，可能进入了高冲突、用户多，或
者信号差的区域。

另外，就像设计界面时不能只考虑最新的浏览器一样，设计应用时也不能只考虑最
新一代移动网络。如前所述（7.1.7 节），即便用户手里拿着最新的手机，也需要不
断在 4G、3G，甚至 2G 网络之间切换。我们的应用必须接受这些接口变化，作出相
应调整。

在浏览器中，可以使用 navigator.onLine 接收连接状态通知，也可以利
用 NetInfo（Network Information API，网络信息 API）查询和监听连接属
性的变化。要了解更多信息，请参考 Paul Kinlan 在 HTML5 Rocks 上的文
章： Working Off the Grid with HTML5 Offline（http://hpbn.co/offline）。

移动网络中不变的只有变化。距离信号塔的远近、活跃用户的多少、环境冲突、一
天中的时段，以及其他很多不可预知的因素，都会导致移动信道质量的差异。明白

128 ｜ 第 8 章