IM即时通讯开如何压缩APP的流量消耗（上）

最近几年，我们针对 Apps 的网络性能优化工作并不多，但每一次都是投入人手较多、时间跨度较长的大任务。本文将给读者们一个一年多以前为公司的某产品成功优化网络流量的案例。速度、成功率与流量正好是 Apps 网络优化的几大重点，希望本文我们分享的思路能够给诸位正在开展或将来会开展此类工作的读者们一些启发。

目前，国内几大运营商的移动数据业务还都处于按流量计费状态，且超出套餐外的流量收费较为昂贵。 那么，一款 APP 是否消耗过多的流量，在用户体验方面影响就显得比较大。

 

一年多前，部门内的某安卓版的产品收到用户投诉，从安卓系统的流量统计中查看到该产品消耗的背景流量偏高，背景流量即 APP 在用户无操作时后台运行消耗的流量，主要用于一些推荐和更新等信息的推送，这部分流量对用户是有意义的，但是如果消耗过多而用户没有感知到足够信息的推送，在用户看来就等于是变相的“偷”走了用户的金钱。

整个流量优化阶段现在回头想来，经历过三个大的阶段：

首先：我们花了大量的精力研究如何测试流量消耗，如何精确的得到每个功能点消耗了多少流量，因为如果我们不了解现状，根本无法去优化流量；

其次：我们针对每个功能点，根据其功能逻辑，探讨优化方法，以及从全局来看，这些功能点有无精简的可能，从项目之初的无任何优化经验，到项目结束时总结和固化了众多的流量优化经验，我们成功的将流量降到了理想范围；

最后：我们思考如何将本次优化的成果持续保持下去，即后续的新增特性不能恶化流量消耗，我们开发并完善了流量自动化监控系统，有力的保障了后续的版本流量不恶化。

流量测试方法

首先我们对该产品 24 小时的消耗的背景流量进行测试。那么流量测试都有什么方法呢？首先得搞清楚流量是什么？我们的手机通过运营商的网络访问 Internet，运营商替我们的手机转发数据报文，数据报文的总大小（字节数）即流量，这里的数据报文包含手机上下行的报文。由于数据报文采用 IP 协议传输，运营商计算的流量一般都是包含 IP 头的数据报文大小。

搞清楚了流量的定义之后，那么我们可以思考如何来获取应用消耗的流量。最直接的办法就是在手机上抓包，