网络优化

“设置”里面可以看到具体app的流量消耗

网络优化是多维的，仅仅重视流量不够

网络流量的消耗量统计需要全面+精确：假若线上用户反馈app消耗流量多，但是如果我们不知道用户总共使用该app多长时间，其实我们是不好断定的。如果使用时间比较久，那流量消耗多一点，其实很可能是正常的；再比如说用户可能反馈app在后台消耗流量比较多，如果只有一个整体的值，其实无法断定这个app一定是在后台消耗得比较多。

要建立全面的网络监控体系，粗粒度监控不能帮助我们发现、解决深层次的问题

网络优化的纬度：

1、流量消耗纬度：一段时间流量消耗的精准度量，网络类型、前后台消耗量；监控相关（用户流量消耗均值、异常率（消耗多、次数多）），最好是有完整链路的全部监控（request、response），主动上报

2、网络请求质量纬度：直接对应用户的真实体验（请求速度、成功率）；监控相关（请求时长、业务成功率、失败率、Top失败接口）

3、其它纬度：公司成本（带宽、服务器数、CDN）；网络请求密集，对手机耗电的影响

优化的误区：

只关注流量消耗，忽视其它纬度

只关注均值、整体，忽视个体

 

工具选择：

network profiler：android studio自带，显示实时网络活动（发送、接收数据及连接数）-->需要启用高级分析，但是只支持HttpURLConnection和okhttp库 

抓包工具：Charles、fiddler（重点）、wireshark、tcpdump

stetho：一个需要代码依赖的工具（功能类似network profiler）

如何判断app流量消耗偏高？这个问题对应了什么时候该进行优化：首先，流量的绝对值看不出高低，不能简单地做一个测试，说app消耗量10M流量，那就一定要马上优化它，绝对值不能作为流量是否偏高的唯一统计标准。最好是去对比竞品，相同case对比流量消耗。同时，还要判断新上的功能对应的流量消耗，比如，要设定使用这个功能之后，他单次消耗的流量是300k左右，但是上线之后如果超过了预期值，那这种情况下需要去确定是否偏高了，采取优化措施。

TrafficStats：设备重启到现在的流量值（不实用）

NetworkStatsManager：可获取指定时间间隔内的流量信息、不同网络类型下的消耗（线上的话，需要后台配合，传输值）

前后台流量获取方案：上述只获取一个时间段内的值，并不能判断是是在前台还是在后台消耗的。可以每间隔30s，判断在前台还是在后台（onResume、onPause），分别加起来统计，虽然存在误差（期间有前后台切换），但是在可接受范围内

 

网络请求流量优化：

数据：Api、资源包（升级包、H5、RN）、配置信息

        数据缓存：服务端返回加上过期时间，避免每次重新获取-->节约流量且大幅提升数据访问速度，更好的用户体验

                         okhttp做get的缓存，post一般是用于修改数据的，所以不做缓存。

        增量数据更新：加上版本概念，只传输有变化的数据（例如配置信息、省市区县的更新）

        数据压缩：post请求body使用gzip压缩；请求头压缩；图片上传前做压缩

        优化发送频率和时机：合并网络请求、减少请求次数（不要每次记录的日志都上传，比如说在wifi的状态下，再上传）

图片：下载、上传

        图片使用策略优化：优先缩略图（七牛云、阿里云支持将图片按照特定大小实时裁剪）

                                        使用webP格式

网络请求“质量”优化：分为两个维度：网络请求成功率，网络请求速度

        http请求过程：1请求到达运营商的Dns服务器并解析成对应的IP地址，2创建连接（三次握手），根据IP地址找到相应的服务器，发起一个请求，3服务器找到对应的资源原路返回给访问的用户。

所以请求的成功率和速度一上来就收到Dns的影响，假设Dns被劫持，Dns解析慢都会影响体验。

Dns优化是请求质量优化的第一步：使用httpDns（它不是使用传统Dns协议，向Dns服务器的53端口发送请求，而是使用http协议，向Dns服务器的80端口发送请求。可降低平均访问时长，提高连接成功率），绕过运营商域名解析过程-->eg:阿里云Dns解析框架。在okhttp拦截器中设置自己的Dns解析服务。

http协议版本的优化：创建连接的时候，如果每次都走三次握手，效率是非常低的。http1.0版本TCP连接不复用；http1.1引入持久连接（从这里开始，tcp链接默认不关闭，开闭多个网络连接所复用，提高了效率），但数据通讯按次序进行；http2版本多工，客户端、服务器双向实时通信

质量监控：APM相关、单点问题相关

          接口请求耗时、成功率、错误码

          图片加载的每一步耗时

          --->okhttp的回调：eventListener，可拿到上述参数

网络容灾机制：

   服务端：备用服务器分流；

   客户端：多次失败后一定时间内不进行请求，避免雪崩效应

其它：CDN加速，提高带宽，动静资源分离（更新后清理缓存）；减少传输量，注意请求时机及频率；Okhttp的请求池；

 

线下测试：只抓单独app、侧重点：请求有误、多余、网络切换、弱网、无网测试

线上监控：

     服务端：请求耗时（区分地域、时间段、版本、机型），失败率（业务失败（请求成功而数据错误）与请求失败），每隔一段时间检查Top失败接口、异常接口

     客户端：一些网络请求还没到达服务端，就已经失败了，所以在客户端监控更为全面

                接口的每一步详细信息（DNS、连接、请求等）

                请求次数、网络包大小、失败原因

                图片监控

异常监控体系：服务端：服务器防刷（超限拒绝访问）；客户端：大文件预警、异常兜底策略；单点问题追查