Android性能优化之网络优化
1、 前言
移动互联网发展到现在，用户的联网方式已经完成了由流量依赖到Wifi依赖的转变。虽然网络环境在变好，但也对网络的应用提出了更高的要求，同时开发人员对网络的重视度却在下降。确实Wifi场景下用户的网络质量变好了，而且用户对网络流量消耗的敏感度也在下降。但是对网络问题的忽视，在网络状态不好的场景下，会表现的很明显。
2、 网络问题
2.1 流量耗费
过多以及没有经过处理的网络请求，会消耗用户的网络流量。Android用户一般都会安装手机管理类App，可以方便清楚查看到每个App耗费的流量，高流量消耗会导致经常处于非Wifi场景下的用户卸载。
2.2 电量消耗
与第一条流量消耗类似，耗电也会导致用户最终的卸载。
2.3 用户体验差
网络请求耗时会给用户带来卡顿的产品体验，虽然可以使用Loading提升用户体验，但属于治标不治本。例如最近我在使用某火爆单车App，每次网络请求都能超出我的耐心，于是我就转投另一款单车App！
2.4 其它
- 应用Apk更新，Apk下载的快慢肯定会影响到应用更新流程的转换率；
- 类如热修复Patch包、Hybrid资源包等的下载，肯定是越早下载到本地越好；
3、 网络监控
3.1 Network Monitor
Android Studio自带的Network Monitor简单直观，可以看出时间段之内的网络请求数量及访问速率；
image
3.2 Charles、Fiddler等抓包工具
使用Charles、Fiddler等抓包工具同样可以实现Network Monitor的功能，而且更加强大。
image
3.3 Stetho
Stetho是Facebook出品的一个Android应用的调试工具。无需Root即可通过Chrome，在Chrome Developer Tools中可视化查看应用布局，网络请求，sqlite，preference等。同样集成了Stetho之后也可以很方便的查看网络请求的各种情况。
image
4、 网络优化
重点来了，网络优化主要从三个方面进行：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.9、1.0、1.1、2等。新版本的协议经过再次的优化，例如：
- Http1.1版本引入了“持久连接”，多个请求被复用，无需重建TCP连接，而TCP连接在移动互联网的场景下成本很高，节省了时间与资源；
- Http2引入了“多工”、头信息压缩、服务器推送等特性。
新的版本不仅可以节省资源，同样可以减少流量；我对Http2并没有实际接入经验，此处仅从原理进行分析。
4.5 请求打包
合并网络请求，减少请求次数。对于一些接口类如统计，无需实时上报，将统计信息保存在本地，然后根据策略统一上传。这样头信息仅需上传一次，减少了流量也节省了资源。
4.6 网络缓存
对服务端返回数据进行缓存，设定有效时间，有效时间之内不走网络请求，减少流量消耗。对网络的缓存可以参见HttpResponseCache。
备注：我们也可以自定义缓存的实现，一些网络库例如：Volley、Okhttp等都有好的实践供参考。
4.7 网络状态
根据网络状态对网络请求进行区别对待，2G与Wifi状态下网络质量肯定是不一样的，那对应的网络策略也应该是不一样的。例如：在Wifi场景下可以进行数据的预取、一些统计的集中上传等；而在2G场景下此类操作以及网络请求的次数策略都应该调低。网络状态可以由TelephonyManager.getNetworkType()方法获取到。
image
备注：还可以使用Facebook的开源库network-connection-class来做网络状态的判断。
4.8 其它
- 断点续传，文件、图片等的下载，采用断点续传，不浪费用户之前消耗过的流量；
- 重试策略，一次网络请求的失败，需要多次的重试来断定最终的失败，可以参考Volley的重试机制实现。
- Protocol Buffer Protocol Buffer是Google的一种数据交换的格式，它独立于语言，独立于平台。相较于目前常用的Json，数据量更小，意味着传输速度也更快。 具体的对比可以参见：《Protobuffer和json深度对比》。
- 尽量避免客户端的轮询，而使用服务器推送的方式；
- 数据更新采用增量，而不是全量，仅将变化的数据返回，客户端进行合并，减少流量消耗；
5、 其它
- 对于网络优化，实际上和内存优化一样，是一项投入巨大的事情。提升网络的成功率尤为困难。因此建议优先进行流量优化，减少干扰项；
- 弱网不仅仅指代网络不好，移动互联网的网络带宽很容易出现“跳变”，下一秒的传送速度可能降到前一秒的几十分之一；而且即便是信号满格也传不出一个字节；
- 对于真正的弱网，可以使用抓包工具进行模拟，也有聪明的小伙伴使用wifi精灵进行限速；
-
Facebook的开源项目augmented-traffic-control可以模拟不同的网络环境，针对带宽、时延抖动、丢包率、错包率、包重排序率等方面，堪称弱网调试神器；
喜欢的话请帮忙转发一下能让更多有需要的人看到吧，有些技术上的问题大家可以多探讨一下。
