前言
首先，通过持久连接、就近访问（如CDN）、优化TLS部署，以及其他协议优化策略来降低延迟时间对移动应用更为重要。但，对于移动应用而言，延迟和吞吐量都是比较重要的。在移动应用开发实践中，需要考虑设备形态限制下如何展示内容，也需要考虑无线电接口的性能特性，还有设备电量的有限性。影响移动应用体验的因素很多，但传输延时、时间抖动、非合理联网操作致使电量消耗过大是其中最重要的。下面将介绍针对移动网络的无线性及电源限制给出的性能优化建议。
1.节约用电
移动网络的性能与电池的使用时间联系十分紧密。为了节约用电，无线接口的物理层针对如下限制做了不少优化：
- 全功率打开无线电模块几个小时就可耗尽电量；
- 对无线电功率的需求随着无线标准演进而增加；
- 无线电模块的耗电量仅次于设备屏幕；
- 数据传输时无线电通信的耗电过程是非线性的。
所以，既然无线电模块消耗的电量是这么的大，在开发应用时，需要尽量少用无线电接口。如果有数据传输需求，尽可能在无线电开启时传输数据，尽量把唤醒无线电以传输数据的次数减到最少。
注：虽然使用WI-FI进行数据传输时也需要使用无线接口，但移动网络与WI-FI的底层机制及时延、吞吐量和耗电特点是不同的。WIFI标准的连接方式是设备间可以随时通信，设备的相应无线电模块处于始终开启状态，电量消耗很大。针对这一问题有了一个优化策略，即无线接入点在向目标设备发送数据前，先发送一个周期性的信号帧广播DTIM（发送数据指示消息），设备收到DTIM帧后进行相应准备，开启无线电模块以接收数据，其他时刻无线电装置处于休眠状态。如果是设备要往外发送数据，大致过程相反。这个优化节省了电量，但增加了延迟。
2.消除周期性及无效的数据传输
只要进行数据传输，无论传输数据量大小，无线电模块总会处于高功率状态，并不存在耗电少的请求。有以下优化规则：
- 轮询在移动网络中代价极高，少用；
- 尽可能使用推送和通知；
- 出站和入站请求应该合并和汇总；
- 非关键性请求应该推迟到无线模块活动时进行。
一般来说，推送比轮询效果更好，但频率过高的推送与轮询相差不大。如果有实时更新的需求，应该考虑以下问题：
- 最佳更新间隔多长，是否符合用户预期？
- 除了固定的更新间隔，能否因地因时制宜？
- 入站或出站请求能否集合为更少的网络调用？
- 入站或出站请求能否推迟到以后发送？
注：原生应用可以访问平台专有的推送服务，因此尽可能使用；web应用可以使用服务器发送事件和WebSocket以降低延迟时间和协议消耗，尽可能不使用轮询和XHR技术。
消除必要的长连接：虽然移动网络中TCP/UDP连接的状态及生命周期与设备的无线状态是相互独立的，但不必要的长连接也有可能带来极大的电量消耗。
3.预测网络延迟上限
在移动网络中，一个HTTP请求（DNS、TCP、TLS等）可能导致长达几百甚至是几千毫秒的延迟，里面有很多环节都是不可确切预估的，有不小的变化。针对延迟的不确定性，移动应用需要做最坏的考虑，预测延迟的最大值，给用户以友好的反馈和用户体验。
一个HTTP的延迟预估
考虑RRC状态切换
如果移动设备处在空闲状态，第一个分组将会导致几百甚至几千毫秒的额外RRC延时。经验表明，4G网络或增加100ms，3.5G+网络会增加150ms-500ms，而3G网络会增加500-2500ms的控制面延时。
虽然移动网络会给人一种应用永远在线的感觉，但其物理层是不断的连接和断开的。要考虑这种延时，否则会影响用户体验。
解耦用户交互与网络通信
好的应用，即使底层连接慢或请求时间长，在UI层面给用户以良好的反馈也能让人觉得速度快。所以，不要把用户交互与网络通信联系太过紧密。
在发送网络请求时，不要忘了给用户以反馈，降低用户的延迟感。由于延迟的不确定性，需要预测最大值以做出准备。
4.面对多网络接口并存的现实
运行不够流畅的应用是不能吸引用户的，但由于短暂的网络问题引起的应用崩溃才是最糟糕的问题。在移动应用的开发中我们要对各种网络问题做好足够的准备，如：无法访问主机、吞吐量突然下降或上升、连接断开等。有线网络一般在建立连接后，后续的连接一般是比较稳定的，但在移动网络中是有变化的，用户可能会移动，也可能进入搞冲突、多用户或信号差的区域，这些都会对网络状况造成影响。
在应用设计和开发过程中，不能仅仅只考虑最新的移动网络，还应考虑2G、3G、4G、WIFI等不同的网络环境，要对这些网络迁移做出相应的调整和准备。对于信号塔远近、活跃用户量、环境冲突、不同的时段及其他不可测因素造成的通信质量变动，也应有相应的预估和应对。
在任何的网络环境中，要想预测出端到端的带宽和延迟都是极其困难，移动网络更是如此。既然如此，应该基于相关网络属于哪一代的粗粒度信息调整代码，虽然不能精准的预测网络延时，但可以根据网络代际知道第一跳的延迟时间，以及运营商网络中端到端的参数信息。除了上述因素需要考虑之外，还要把连接中断作为常态。
无论网络状况如何，都应保持应用保持运行，应该根据请求类型和特定场景做出反应：
- 不要缓存或试图猜测网络状态；
- 调度请求、监听并诊断错误；
- 瞬间错误总会发生，不可忽视，可以采取重试策略；
- 监听连接状态，以便采用最佳请求方式；
- 对重试请求采用补偿算法，不要永远循环；
- 离线时，尽可能记录并在将来请求；
- 利用HTML5的AppCache和localStorage实现离线应用。
5.爆发传输数据并转为空闲
移动无线接口专门为爆发性传输做过优化，应该多加利用。数据的每次传输都会是无线电接口处在高功率状态，如果数据发送间隔时间较大，数据量却很大，这时每次数据传输都会频繁的唤醒无线电模块，限于移动网络本身的机制问题，这就造成很多处在高功率状态的时段没有数据传输任务，极大了浪费了有限的电量资源。
在移动应用中，渐渐加载资源并不是很好的实践，因为这会造成不确定的吞吐量和延迟及更多的电量消耗。因此，应尽量把用户可能用到的数据提前集中下载，让设备在其他时刻空闲下来。建议如下：
- 如果需要大型音频或视频文件，考虑提前下载整个文件，而不是以比特为单位流式下载；
- 预先取得应用内容，通过测量和统计工具来辨别需要提前下载的内容；
- 预先取得第三方内容，比如广告，通过应用逻辑提前显示并更新它们的状态；
- 允许设备关闭无线电模块，保持其空闲，不要忘了优化和消除间歇性传输。
6.把负载转移到WI-FI网络
WIFI网络速率更为稳定，而且也没有流量限制，可以为用户节省移动流量的使用。
由于WIFI自身的机制原因，在大数据量传输时更为省电，也不需要RRC，延迟更为稳定。在需要大量数据传输时，移动应用应可能在WIFI场景下进行数据上传和下载。
7.遵从协议和应用的最佳实践
网络是分层设计和架构的，底层物理网络的优化固然重要，但全体考虑也十分必要，比如TCP优化、UDP优化、TLS优化等。