Android性能优化——网络优化

一、流量消耗

• 一段时间流量消耗的精准度量，网络类型、前后台
• 监控相关：用户流量消耗均值、异常率（消耗多、次数多）
• 完整链路全部监控 ( Request. Response ），主动上报

二、网络请求质量

• 用户体验：请求速度、成功率
• 监控相关：请求时长．业务成功率、失败率、Top失败接口
• 其它

公司成本：带宽、服务器数、CDN
耗电

三、网络优化误区

• 只关注流量消耗，忽视其它纬度
• 只关注均值、整体，忽视个体

四、工具选择

• Network Profiler
• 抓包工貝
• Stetho

Network Profiler

• 显示实时网络活动：发送、接收数据及连接数
• 需要启用高级分析
• 只支持 HttpURLConnection和OkHttp网络库

抓包工具

• Charles  功能强大，重点使用，网络请求抓包，信息全面
  • 断点功能
  • Map Local
  • 弱网环境模拟
• Fiddler 
• Wireshark
• TcpDump

Stetho使用。功能小，不常使用

• com.facebook.stetho:stetho-okhttp3:1.5.0
• Stetho.initialize WithDefaults(this);
• addNetworkInterceptor
• Chrome浏览器：chrome://inspect

如何判断App流量消耗偏高

• 流量的绝对值看不出高低
• 对比竞品，在相同case 下对比流量消耗
• 异常监控超过正常指标

测试方案

• 设置 -> 流量管理
•  抓包工具，只允许本App 联网
•  可以解决大部分问题，但是线上场景线下可能遇不到

线上流量获取方案

NetworkStatsManager：AP123之后流量统计，可获取指定时间间隔内的流量信息，可获取不同网络类型下的消耗

前后台流量获取方案

难题：线上反馈App后台跑流量
分析：只获取一个时间段的值不够全面

在App启动的时候来执行一个后台任务，这个后台任务每隔一段时间，比如30s，获取一下这30s 之内的流量消耗，自己维护一份数据的统计，分别记住流量在前后台消耗总量，然后和别的监控加起来，在合适的时间之内上报到APM 后台，作为流量治理的依据，这样就可以知道流量在前后台的流量消耗，当用户反馈时可以很方便的看到流量统计

有一定误差，可接受范国内
结合精细化的流量异常报警针对性的解决后台跑流量

使用网络的场景概述

• 数据：Api、资源包（升级包、H5、RN）、配置信息
• 图片：下载、上传
• 监控：APM相关、单点问题相关

网络请求优化

• 数据缓存
  • 服务端返回加上过期时间，避免每次重新获取
  • 节约流量且大幅提高数据访问速度，更好的用户体验
  • OkHttp、volley都有较好实践
• 增量数据更新
  • 加上版本的概念，只传输有变化的数据
  • 配置信息、省市区县等更新
• 数据压缩
  • Post请求Body使用GZip压缩
  • 请求头压缩
  • 图片上传之前必须压缩
• 优化发送频率和时机
  • 合并网络请求、减少请求次数
  • 性能日志上报：批量＋特定场景上报
• 图片相关
  • 图片使用策略细化：优先缩略图
  • 使用WebP格式图片

网络请求质量优化

 质量指标

• 网络请求成功率
• 网络请求速度

Http请求过程

发出来一个请求，请求到达运营商Dns 服务器然后会被解析成对应的ip 地址
然后会创建了连接，它会走TCP的三次握手，根据ip地址找到相应的服务器发送一个请求
服务器找到相对应的资源原路返回访问的用户

问题：DNS被劫持，DNS解析慢都会影响用户的体验

• DNS被劫持说明用户得到的数据并不是真实想要提供给用户的数据
• DNS解析慢说明用户等待请求时间就会变长

所以说DNS优化是质量优化的第一步

解决：使用HttpDNS 绕过运营商域名解析过程，它采用http协议向DNS服务器的发令端口发送请求
优势：降低DNS被劫持，绕过运营商的域名解析过程，降低平均访问时长，节省了一次解析过程，提高连接成功率

Http协议版本优化

网络请求有一步是创建连接，当中会有TCP的三次握手，这个时间是比较长的，如果每一次网络请求都要走三次握手，效率非常低，HTTP版本对这个的优化

• 1.0：版本TCP连接不复用，每个TCP的连接只能发送一个请求，如果还要请求别的资源，需要重新建立一个连接，而TCP 创建连接的成本非常高，需要三次握手，并且在开始发送的速度有点慢，这个版本的性能非常差
• 1.1 ：只比1.0晚了半年，最大的改变就是引入了持久链连接，从这个版本开始TCP 的连接默认不关闭，会被多个网络请求所复用，效率有了保证，但是还是有缺陷，虽然允许了TCP 的复用，但是同一个TCP 连接里所有的通讯必须按照次序来，完成一个请求之后才能进行下一个请求，如果其中一个请求比较慢，后面的请求就必须等待
• 2：二进制协议，非常大的好处就是多工，也是默认了TCP 连接的复用，有个特别大的好处就是客户端和服务端可以同时发送多个请求和回应，不需要按照顺序一一对应，是一个双向的实时通讯

网络请求质量监控

• 接口请求耗时，成功率，错误吗
• 图片加载的每一步耗时