Android-移动网络优化

最新推荐文章于 2024-05-02 20:40:27 发布

zhuhai0613

最新推荐文章于 2024-05-02 20:40:27 发布

阅读量166

点赞数

文章标签： android

本文链接：https://blog.csdn.net/zhuhai0613/article/details/132886588

版权

移动网络优化

前言

首先，通过持久连接、就近访问（如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优化等。

附:初识Doze

在Android 6.0版本中google提供了两个策略：doze和app standby，能有效的减少电量的消耗，提升待机时间。设备没有连接到电源，设备进入Doze模式时，系统将通过延迟最近用户没有使用的应用程序的后台CPU运作及网络活动，让应用程序处于App Standby状态，以此来减少电池消耗。
Doze功能借助动作检测来确定用户有多长时间没用手机，然后就进入“打盹”模式，从而延长续航时间。而一旦用户重新开始使用手机，Doze模式就会取消恢复到正常状态。

谷歌称，配备Doze的Nexus9将比普通Nexus续航能力提高一倍。德国科技博客ComputerBase分别用一部安装了Android M开发者预览版和一部安装了Android 5.1.1的Nexus 5来做对比。两部手机都安装了同样的应用，电池充满。同时连入相同的无线网络，使用相同的设置，都不装SIM卡，蓝牙，NFC，Android Beam以及LED等全都处于关闭状态。结果对比是在待机8小时后，安装了Android 5.1.1的Nexus 5消耗了4%的电量，而Android M版则仅消耗了1.5%;在24小时后，Android 5.1.1版的Nexus 5消耗了12%的电量，Android M版则仅消耗了4.5%；48小时后，Android 5.1.1版的Nexus 5消耗了24%的电量，而Android M版则仅消耗了9%。总的来看，在Doze开启下，Nexus 5在Android M下则能待机533小时，在Android 5.1.1下可待机200小时。

2. 理解Doze

1、设备进入Doze睡眠模式时机：
–用户不操作设备一段时间（通过动作监测来判断）
–屏幕关闭
–设备未连接电源充电
2、Doze模式下应用程序有什么变化：
–系统试图通过限制应用程序访问网络和CPU密集型8服务节省电池
–防止应用程序访问网络，推延应用程序的工作，同步，和标准的警报
–系统定期提供一个短暂的时间让应用程序完成延迟的工作活动，在这个时间片里，系统将提供维持性窗口应用程序访问网络，运行在等待的同步，工作，和报警等活动
Doze模式的五种状态，分别如下：
–ACTIVE：手机设备处于激活活动状态
–INACTIVE：屏幕关闭进入非活动状态
–IDLE_PENDING：每隔30分钟让App进入等待空闲预备状态
–IDLE：空闲状态
–IDLE_MAINTENANCE：处理挂起任务
下面一张图将介绍这几种状态之间的切换关系
在这里插入图片描述

google官方文档说明，在灭屏后至少60分钟才会进入到doze模式。在进入到doze模式后，应用程序的活动和网络链接都会被挂起，每个一段时间会进入一次Maintenance阶段（持续30秒），让应用能处理挂起的任务。
在这里插入图片描述

进入Maintenance的时间间隔会随着doze模式的深入越来越长。
3、如何退出doze模式
–用户唤醒装置移动，打开屏幕
–连接电源
4、doze模式有哪些限制
–网络连接会被禁止
–Wake Lock会被屏蔽
–AlarmManager定时任务延迟到下一个maintenance window进行处理，除非使用AlarmManager提供的方法：setAndAllowWhileIdle()或者setExactAndAllowWhileIdle()
–系统将不扫描热点WIFI
–同步工作将被禁止
–不允许JobScheduler进行任务调度
5、如何在开发时适配doze模式
–Doze影响到AlarmManager闹钟和定时器管理活动，在Android6.0引入了两个新方法：setAndAllowWhileIdle() 和setExactAndAllowWhileIdle()，调用两个方法可以在Doze模式下让系统响应定时任务
–Doze模式下限制了网络的连接，如果应用程序依赖于实时信息，那么这个将影响App的体验。那么你需要使用Google Cloud Messaging (GCM)谷歌云消息
6、测试Doze和App Standby模式的方法（Adb命令）

测试Doze模式

1.首先确保你的硬件或虚拟设备是Android6.0或更高版本系统；
2.连接设备到开发机上并安装你的app；
3.运行app并让其运行活动；
4.关闭设备的屏幕；

5.运行以下adb命令使系统进入Doze模式：

  $ adb shell dumpsys battery unplug      //（断开电源）
  $ adb shell dumpsys deviceidle step     //（获取状态）

6.观察你的app表现行为是否有需优化改进的地方。

测试App Standby模式

步骤1-3同测试Doze模式

4.运行以下adb命令迫使系统进入App Standby模式：

  $ adb shell dumpsys battery unplug
  $ adb shell am set-inactive <packageName> true

5.模拟唤醒你的应用程序使用以下命令：

  $ adb shell am set-inactive <packageName> false
  $ adb shell am get-inactive <packageName>

6.观察你的App，确保应用程序恢复正常从待机模式过程中，App的通知及其背部活动能达到预期结果。

3.理解app standby策略

当用户不触摸使用应用程序一段时间时，该应用程序处于App Standby状态，系统将把该App标志为空闲状态。除非触发以下任意条件，应用程序将退出App Standby状态：

1.用户主动启动该App;
2.该App当前有一个前台进程（或包含一个活动的前台服务，或被另一个activity或前台service使用）;
3.App生成一个用户所能在锁屏或通知托盘看到的Notification,而当用户设备插入电源时，系统将会释放App的待机状态，允许他们自由的连接网络及其执行未完成的工作和同步。如果设备空闲很长一段时间，系统将允许空闲App一天一次访问网络。

Doze和App Standby的区别：
个活动的前台服务，或被另一个activity或前台service使用）;