六. Android 网络优化

1 网络优化从哪些纬度开展?

仅仅重视流量不够。
网络流量的消耗量：精确
整体均值掩盖单点问题

正确认识：
网络相关监控：全面。 请求成功率
粗粒度监控不能帮助我们发现、解决深层次问题。

网络优化维度：
1）流量消耗：
一段时间流量消耗的精准度量，网络类型、前后台
2）监控相关：
用户流量消耗均值、异常率（消耗多、次数多）
完整链路全部监控（Request、Response），主动上报
3）网络请求质量
4）用户体验：请求速度、成功率
5）监控相关：请求时长、业务成功率、失败率、Top失败接口
6）其他
公司成本：带宽、服务器数、CDN
7）耗电
优化误区：
只关注流量消耗、忽视其他维度
只关注均值、整体，忽略了个体数据。 但看百分占比没有意义。

2. 网络优化工具选择

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

抓包工具
Charles、Fiddler、Wireshark、TcpDump
Charles
1）断点功能
2）Map Local。模拟假数据
3）弱网环境模拟。 Throttle
Stetho
强大的应用调试桥，连接Android 和 Chrome
对比竞品，相同case对比流量消耗
异常监控超过正常指标

3. 精准获取流量消耗实战
线上线下流量获取
前台后台流量获取
如何判断App流量消耗偏高？
绝对值看不出高低

测试方案
设置—— 流量管理
抓包工具：只允许本App联网
可以解决大多数问题，但是线上场景线下可能遇不到

线上流量获取方案
TrafficStats:
API8 以上重启以来的流量数据统计 （无法获取某个时间段内的流量消耗。）
getUidRxBytes(int uid ) 制定Uid的接收流量
getTotalTxBytes() 总发送流量

NetwortStatsManager：
API23之后流量统计
可获取指定时间间隔内的流量信息
可获取不同网络类型下的消耗
难题：线上反馈App后台跑流量
只获取一个时间段的值不够全面。
后台定时任务 ——> 获取时间间隔内流量
——> 记录前后台 ——> 分别计算
——> 上报APM后台 ——> 流量治理依据

ExecutorService
          .newScheduleThreadPool(1)
        .schedule(new Runnable(){}, 30, TimeUnit.SECONDS);

getApplication().registerActivityLifecycleCallbacks(){
            onActivityCreated
            onActivityStarted
            onActivityResumed
            
            // 认为是在前台
            onActivityPaused
            // 退到后台去了
}

4. 网络请求流量优化实战

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

服务器返回加上过期时间，避免每次重新获取。
节约流量且大幅提高数据访问速度，更好的用户体验
OkHttp都有较好实践。

增量数据更新
加上版本的概念，只传输有变化的数据。
配置信息、省市区县等更新
数据压缩
Post请求Body使用GZip压缩
请求头压缩
图片上传之前必须压缩

图片压缩库：Luban
优化发送频率和时机

合并网络请求、减少请求次数。 （节约Header）
性能日志上报：批量 + 特定场景上报 （wifi下上传。）

图片相关
图片使用策略细化：优先缩略图
使用webp格式

5. 网络请求质量优化实战

质量指标：
网络请求成功率、网络请求速度

Http请求过程
请求到达运营商的Dns服务器并解析成对应的IP地址
创建连接，根据IP地址找到对应的服务器，发起一个请求
服务器找到对应的资源原路返回访问的用户

DNS相关
问题：DNS被劫持、DNS解析慢
方案：使用HttpDNS，绕过运营商域名解析过程
不是传统地向DNS服务器的53端口发送请求。而是使用Http协议向DNS服务器的80端口发送请求。
优势：绕过LocalDNS的劫持。加快解析过程。降低平均访问时长、提高连接成功率。

协议版本升级
1.0：版本TCP连接不复用
1.1：引入持久连接，但数据通讯按次序进行
2.0：多工，客户端、服务端双向实时通信

网络请求质量监控
接口请求耗时、成功率、错误码
图片加载的每一步耗时
网络容灾机制
备用服务器分流。
多次失败后一定时间内不进行请求，避免雪崩效应。

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

6. 网络体系化方案建设

线下测试相关

方案：只抓单独APP
侧重点：请求有误、多余，网络切换、弱网、无网测试

线上监控相关

1）服务端监控
请求耗时（区分地域、时间段、版本、机型）
失败率（业务失败与请求失败）
Top失败接口、异常接口

2）客户端监控
接口的每一步详细信息（DNS、连接、请求等）
请求次数、网络包大小、失败原因

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

7. 网络优化问题

1）在网络方面你们做了哪些监控，建立了哪些指标
演进过程、优化背景。
初期没有意识到，由于wifi场景下网速快，成功率也就比较高。没有注意到相关问题。
用户量增大，界面打不开或者比较慢。流量消耗比较多。刚开始没有数据支撑所有没有办法确认用户的反馈是否正确。
不知道线上用户的真实用户体验是怎么样。
如果单纯依靠用户反馈，那么这样的异常感知灵敏度是非常低的。所以就补上了网络情况的监控。

1——流量监控 2——质量监控
质量：请求成功率、每步耗时、状态码
客户端统计了每个请求的每步耗时，比如DNS解析时间，建立连接等时间，接口失败原因。在合适时间点上报给服务器。
流量：精确统计、前后台
下发指令。获取用户的流量消耗情况。如何获取的前后端获取的。讲述一下。单日消耗流量均值，以及前后台消耗。

2）如何有效的降低用户流量消耗
数据：缓存、增量更新
梳理了项目中展示类的接口，选出了对时效性不是那么强的接口，做了数据的缓存。一段时间内的数据直接从本地读取而不重新走网络请求。避免无意义的浪费。
添加进了版本号的概念，每次更新只添加变化的数据。可以非常多地减少流量消耗。

上传：压缩。body的压缩。图片的压缩。
Feed时仅采用缩略图，同样格式的图片转换成webp，也有一定比例的压缩。均有云服务轻松帮我们转换。

3）用户反馈消耗流量多这种问题怎么查？
部分用户遇到流量消耗比较多肯定存在，用户很多反馈类型也很多。有些用户的操作路径很诡异，让自己的账户体系出错。从而遇到了异常情况，部分用户遇到了A/B Test。更多地消耗了流量。

精确流量获取能力。
所有请求大小及次数的监控。
主动预警能力。
体系化的思维能力！