Android 性能优化（八）之网络优化

一、 前言

移动互联网发展到如今，用户的联网方式已经完成了由流量依赖到Wifi依赖的转变。虽然网络环境在变好，但也对网络的应用提出了更高的要求，同时开发人员对网络的重视度却在降低。确实Wifi场景下用户的网络质量变好了，并且用户对网络流量消耗的敏感度也在降低。可是对网络问题的忽视，在网络状态很差的场景下，会表现的很明显。

二、 网络问题

2.1 流量耗费

过多以及没有通过处理的网络请求，会消耗用户的网络流量。Android用户通常都会安装手机管理类App，能够方便清楚查看到每一个App耗费的流量，高流量消耗会致使常常处于非Wifi场景下的用户卸载。

2.2 电量消耗

与第一条流量消耗相似，耗电也会致使用户最终的卸载。

2.3 用户体验差

网络请求耗时会给用户带来卡顿的产品体验，虽然可使用Loading提高用户体验，但属于治标不治本。例如最近我在使用某火爆单车App，每次网络请求都能超出个人耐心，因而我就转投另外一款单车App！

2.4 其它

• 应用Apk更新，Apk下载的快慢确定会影响到应用更新流程的转换率；
• 类如热修复Patch包、Hybrid资源包等的下载，确定是越早下载到本地越好；

三、 网络监控

3.1 Network Monitor

Android Studio自带的Network Monitor简单直观，能够看出时间段以内的网络请求数量及访问速率；

Network Monitor指南

3.2 Charles、Fiddler等抓包工具

使用Charles、Fiddler等抓包工具一样能够实现Network Monitor的功能，并且更增强大。

Charles使用

3.3 Stetho

Stetho是Facebook出品的一个Android应用的调试工具。无需Root便可经过Chrome，在Chrome Developer Tools中可视化查看应用布局，网络请求，sqlite，preference等。一样集成了Stetho以后也能够很方便的查看网络请求的各类状况。

Stetho查看网络请求

四、 网络优化

网络优化主要从三个方面进行：1. 速度；2. 成功率；3. 流量。

4.1 Gzip压缩

HTTP协议上的Gzip编码是一种用来改进WEB应用程序性能的技术，用来减小传输数据量大小，减小传输数据量大小有两个明显的好处：

• 能够减小流量消耗；
• 能够减小传输的时间。

4.2 IP直连与HttpDns；

DNS解析的失败率占联网失败中很大一种，并且首次域名解析通常须要几百毫秒。针对此，咱们能够不用域名，才用IP直连省去 DNS 解析过程，节省这部分时间。

另外熟悉阿里云的小伙伴确定知道HttpDns：HttpDNS基于Http协议的域名解析，替代了基于DNS协议向运营商Local DNS发起解析请求的传统方式，能够避免Local DNS形成的域名劫持和跨网访问问题，解决域名解析异常带来的困扰。

4.3 图片处理

4.3.1 图片下载

• 使用WebP格式；一样的照片，采用WebP格式可大幅节省流量，相对于JPG格式的图片，流量能节省将近 25% 到 35 %；相对于 PNG 格式的图片，流量能够节省将近80%。最重要的是使用WebP以后图片质量也没有改变。
• 使用缩略图；App中须要加载的图片按需加载，列表中的图片根据须要的尺寸加载合适的缩略图便可，只有用户查看大图的时候才去加载原图。不只节省流量，同时也能节省内存！以前使用某公司的图片存储服务在原图连接以后拼接宽高参数，根据参数的不一样返回相应的图片。

4.3.2 图片上传

图片（文件）的上传失败率比较高，不只仅由于大文件，同时带宽、时延、稳定性等因素在此场景下的影响也更加明显；

• 避免整文件传输，采用分片传输；
• 根据网络类型以及传输过程当中的变化动态的修改分片大小；
• 每一个分片失败重传的机会。

备注：图片上传是一项看似简单、共性不少但实际上复杂、须要细分的工做。移动互联网的场景和有线的场景是有不少区别的，例如移动网络的质量/带宽常常会发生“跳变”，但有线网络倒是“渐变”。

图片上传其它细节请参见《移动App性能评测与优化》一书。

4.4 协议层的优化

使用最新的协议，Http协议有多个版本：0.九、1.0、1.一、2等。新版本的协议通过再次的优化，例如：

• Http1.1版本引入了“持久链接”，多个请求被复用，无需重建TCP链接，而TCP链接在移动互联网的场景下成本很高，节省了时间与资源；
• Http2引入了“多工”、头信息压缩、服务器推送等特性。

新的版本不只能够节省资源，一样能够减小流量；我对Http2并无实际接入经验，此处仅从原理进行分析。

4.5 请求打包

合并网络请求，减小请求次数。对于一些接口类如统计，无需实时上报，将统计信息保存在本地，而后根据策略统一上传。这样头信息仅需上传一次，减小了流量也节省了资源。

4.6 网络缓存

对服务端返回数据进行缓存，设定有效时间，有效时间以内不走网络请求，减小流量消耗。对网络的缓存能够参见HttpResponseCache。

备注：咱们也能够自定义缓存的实现，一些网络库例如：Volley、Okhttp等都有好的实践供参考。

4.7 网络状态

根据网络状态对网络请求进行区别对待，2G与Wifi状态下网络质量确定是不同的，那对应的网络策略也应该是不同的。例如：在Wifi场景下能够进行数据的预取、一些统计的集中上传等；而在2G场景下此类操做以及网络请求的次数策略都应该调低。网络状态能够由TelephonyManager.getNetworkType()方法获取到。

备注：还可使用Facebook的开源库network-connection-class来作网络状态的判断。

4.8 其它

• 断点续传，文件、图片等的下载，采用断点续传，不浪费用户以前消耗过的流量；

• 重试策略，一次网络请求的失败，须要屡次的重试来判定最终的失败，能够参考Volley的重试机制实现。

• Protocol Buffer
  Protocol Buffer是Google的一种数据交换的格式，它独立于语言，独立于平台。相较于目前经常使用的Json，数据量更小，意味着传输速度也更快。

  具体的对比能够参见：《Protobuffer和json深度对比》。

• 尽可能避免客户端的轮询，而使用服务器推送的方式；

• 数据更新采用增量，而不是全量，仅将变化的数据返回，客户端进行合并，减小流量消耗；

五、 其它

• 对于网络优化，实际上和内存优化同样，是一项投入巨大的事情。提高网络的成功率尤其困难。所以建议优先进行流量优化，减小干扰项；
• 弱网不只仅指代网络很差，移动互联网的网络带宽很容易出现“跳变”，下一秒的传送速度可能降到前一秒的几十分之一；并且即使是信号满格也传不出一个字节；
• 对于真正的弱网，可使用抓包工具进行模拟，也有聪明的小伙伴使用wifi精灵进行限速；
• Facebook的开源项目augmented-traffic-control能够模拟不一样的网络环境，针对带宽、时延抖动、丢包率、错包率、包重排序率等方面，堪称弱网调试神器；
• 针对网络请求对电量的损耗，本文暂时不提，在下一篇文章中细说。

参考：

• Android性能优化典范《Network Performance》
• 《移动App性能评测与优化》
• 《Protobuffer和json深度对比》

欢迎关注微信公众号：按期分享Java、Android干货！

欢迎关注