……

8.5 爆发传输数据并转为空闲

移动无线接口专门为爆发性传输做过优化,这一点应该尽可能利用。比如,把请求分组,尽可能多和快地下载数据,然后让无线模块转为空闲。这样,既可以获得最大的网络吞吐量,也能节约电量。

估算网络速度唯一正确的方式,就是使用它!LTE和HSPA+等最新一代网络,每隔1毫秒就会动态分配一次资源,而且更适合爆发性的数据传输。换句话说,要想快,就要简单:批量请求,预先下载尽可能多的数据,然后让网络空闲。

基于此,一个重要的结论就是:渐进加载资源在移动网络中弊大于利。每次只下载一点数据会导致应用的吞吐量和延迟都摇摆不定,同时消耗的电量可能也会更多。因此,要尽可能预先下载数据,预测用户接下来可能需要看什么,提前下载,尽量让无线模块空闲:

  • 如果需要大型音频或视频文件,考虑提前下载整个文件,而不要以比特为单位地流式下载;
  • 预先取得应用内容,通过测量和统计工具来辨别什么内容适合提前下载;
  • 预先取得第三方内容,比如广告,通过应用程序提前显示并更新它们的状态;
  • 允许设备关闭无线模块,保持其空闲,不要忘了优化和消除间歇性传输(参见7.3.5节中的“46%的电量消耗仅传输0.2%的数据”)。

构建和评估预取模型

预取内容总会存在矛盾:一方面,你希望尽可能下载更少的数据,另一方面,你又想减少延迟和吞吐量的变动,同时降低对电池的影响。哪一方面更重要呢?这样问本身就是错误的。答案永远与应用的具体使用情境,以及你选择用来评估预取策略有效性的指标相关。

重点在哪里?最低限度,要做到三个变量的平衡:传输的字节数、对电池的影响,还有网络吞吐量及延迟的变动。而且,如前所述,这三个变量并不相互排斥。一次下载较多字节可能会带来更大的吞吐量!

对于能准确预测使用模式的应用,可以采取激进的预取策略,将电量消耗降到最低,提升用户体验,同时避免大下载量的开销。相反,不够好的预取策略可能会下载大量不必要的数据,降低整体用户体验。

要确定应用的具体行为,首先要确定你的主要目标,以及应用的主要使用模式。然后,根据这些因素决定预取策略,并收集数据以验证你的预测,如此反复。

8.6 把负载转移到Wi-Fi网络

目前的行业预测显示,世界范围内几乎90%的无线流量都源自室内,而且经常是在有Wi-Fi连接的区域内。虽然最新4G网络的峰值吞吐量和延迟时间都与Wi-Fi不相上下,但每月的数据流量往往都有上限,毕竟移动上网是按量计费的,价格并不便宜。另外,Wi-Fi连接下的大数据量传输更省电(参见7.3.1节“3G、4G和Wi-Fi对电源的要求”),也不需要RRC。

可能的情况下,特别是对需要处理较大数据量的应用,都应该利用Wi-Fi连接。如果检测不到Wi-Fi连接,可以建议用户打开Wi-Fi连接,以提升体验和节省电量。

8.7 遵从协议和应用最佳实践

网络基础设施的分层架构有一个最大的优点,那就是把物理交付接口从传输层中抽象了出来,而传输层又把路由和数据交付从应用协议中抽象了出来。这种分离的结果就是API具有独立性,但为了取得端到端的最佳性能,我们仍然要考虑整个架构。

本章主要讨论了移动网络物理层的独立性能,比如RRC的存在、电池使用时间的问题,以及移动网络中独有的路由延迟。在物理层之上,是我们前几章已经介绍过的的传输和会话协议,针对它们的优化同样甚至更加重要:

  • 2.5节“针对TCP的优化建议”;
  • 3.3节“针对UDP的优化建议”;
  • 4.7节“针对TLS的优化建议”。

通过重用持久连接、将服务器和数据部署到离客户端更近的地方、优化TLS部署,以及其他所有优化措施,对移动网络而言只会更加重要,因为移动网络的往返时间长,而带宽永远都很昂贵。

当然,我们的优化策略并不会止步于传输和会话协议,这两方面只是基础。从现在开始,我们还必须考虑不同应用协议(HTTP 1.0、1.1和2.0),以及通用Web应用开发最佳实践对性能的影响。继续阅读吧,还没有结束呢!