Page 141 - Web性能权威指南

举个例子，GCM（Google Cloud Messaging，谷歌云消息）就是一个可以在 Android
和 Chrome 平台中使用的消息发送 API，它能聚合消息，并只在设备活动时发送更
新。只要把消息发送给 GCM，然后 GCM 就能作出最优的推送时间安排。
遗憾的是，目前还没有功能类似 GCM 的跨浏览器 API，因此不能统一为所有客户
端提供服务。不过，W3C Push API（参见 www.w3.org/TR/push-api/）将来有可能
解决这个问题。

间歇的信标（beacon）请求（比如周期性的听众评测和实时分析请求）很容易破坏
电池电量优化策略。这些周期性的请求对于有线甚至 Wi-Fi 网络没有什么负面影响，
但对无线网络影响巨大。这些信标请求有必要实时发送吗？恐怕借助日志将请求推
迟到无线模块下一次活动时发送才是明智的。总之，需要认真对待后台的这些周期
性操作，同时还要密切关注第三方库和代码片段访问网络的模式。
最后一点，虽然我们一直在说电池，但也不要忘了渐进增强和增量加载等技术依赖
的间歇性网络访问，会带来较长的延迟，因为 RRC 状态需要切换！还记得每次状态
切换都会导致移动网络控制面的较大延迟吧，每次切换都可能增加几百甚至几千 ms
的延迟时间。对于用户发起或交互性的流量，这方面的代价非常之大。

计算后台更新的电量消耗
为说明周期性轮询对电池使用时间的影响，我们可以做一道简单的数学题。数值
虽然不一定准确，但也不会跑出 3G/4G 移动设备的范围之外：
• 5 Wh 或 18000 J 的电池容量（5 Wh × 3600 J /Wh）；
• 无线电模块从空闲状态切换到连接状态需要 10 J；
• 1 分钟一次的轮询，1 小时耗能 600 J（60 × 10 J）；
• 600 J 相当于电池容量的大约 3%（600 J / 18000 J）。

一个应用每小时就要消耗 3% 的电量！那么两个应用不重合的轮询，要耗尽电池，
只需半天时间。当然，如果应用频繁使用不缓冲的推送（比如，每两秒就推送一
次），那么其耗电量还会更高！
电池使用时间优化和更新频率天生是一对矛盾。实践中，要根据自己应用的特定
需求来确定优化策略：更新打包、适应性的更新间隔、拉与推结合，等等。当然，
还要使用 ARO 或类似的工具测量策略效果，适时调整。

消除不必要的长连接
TCP 或 UDP 连接的连接状态及生命期与设备的无线状态是相互独立的。换句话说，

移动网络的优化建议 ｜ 125