腾讯原创分享(三)：如何大幅压缩移动网络下APP的流量消耗（下篇）

导读：在移动应用开发中，应用上线了只是一个开始，噩梦在后面：手机越用越卡为哪般？手机发烫是为何？谁偷走了用户的钱包？如何瘦成一道闪电？这些问题解决起来都是非常麻烦的，腾讯移动品质中心（TMQ）成立了专项测试团队来解决这些问题。

1、前言

在上篇《腾讯原创分享(二)：如何大幅压缩移动网络下APP的流量消耗（上篇）》中，我们对文章中产品的流量消耗情况进行了详细的摸底，我们搞清楚了流量到底消耗在哪了，以及有没有多余和浪费。本篇中将详细介绍我们的具体分析方法和实践优化思路，以及在优化过程中总结出来的法则等。

强烈建议您同时阅读：《现代移动端网络短连接的优化手段总结：请求速度、弱网适应、安全保障》《移动端IM开发者必读(一)：通俗易懂，理解移动网络的“弱”和“慢”》、《移动端IM开发者必读(二)：史上最全移动弱网络优化方法总结》。

2、系列文章

本文是系列文章中的第3篇，总目录如下：

• 《腾讯原创分享(一)：如何大幅提升复杂移动网络下手机QQ的图片传输速度和成功率》
• 《腾讯原创分享(二)：如何大幅压缩移动网络下APP的流量消耗（上篇）》
• 《腾讯原创分享(三)：如何大幅压缩移动网络下APP的流量消耗（下篇）》（本文）
  

3、内容概述

搞清楚了所有交互的报文后（见上篇《腾讯原创分享(二)：如何大幅压缩移动网络下APP的流量消耗（上篇）》），我们需要来优化具体的逻辑和报文，对于各个功能，如何在对原有逻辑无损和不影响用户体验的情况下进行流量优化呢，下面我们详细介绍一下我们的分析方法和优化思路，以及在优化过程中总结出来的法则。

4、单个协议内容消除重复和浪费

项目之初，面对众多的协议，对这些协议的功能和发送逻辑也不是很了解，很多人感觉无从下手。我们的经验就是按流量消耗从大到小依次分析各个协议报文，这里对单个协议的分析包含功能和代码逻辑的分析，优化主要是不影响功能的情况下去除交互报文的冗余。

我们将协议交互的请求和响应各个字段都打印出来，详细的进行分析，很快我们就看到响应报文中是存在冗余和浪费的，最典型的一个协议报文就是动态获取配置，一般 APP 的配置都不是客户端写死的，而是服务器上动态配置的，这样对于一些功能，能方便的在服务器上更改配置，而不需要发布版本。我们的 APP 的配置项也很多，比如报文发送的时间点策略，其他的策略，我们从打印中就能看出，一次响应中的配置项的报文长度就高达 4KB，而且获取配置的报文是一小时发送一次的，一天 24 次，就是 96KB 的流量消耗，在配置不变的情况下，每次响应的 4KB 报文的配置数据是完全一致的，这个完全没必要，每次只需要将有变化的配置项下发下来即可。

我们当即与开发团队讨论，开发团队也表示，当初这种实现方法是最简单的，要做到增量下发配置项实现上复杂一些，因为不同的终端当前的配置项都是不一样的，后台服务器如何判断哪些配置项需要下发给某个终端，哪些不需要，是一个难题。我们经过讨论和方案设计，找到了一个较好的解决方案。下面我们将我们的解决方案总结一下。

我们为服务器的全体配置项引入一个新的参数：版本号 version，从 1 开始递增（ 0 表示没有获取过配置项），每次后台服务器修改了某一个配置项，即更新当前最新的版本号，同时记录下该版本号变化的配置项的索引号，每次客户端的请求报文中都必须携带客户端的配置项的版本号，服务器将客户端的版本号与最新的版本号比较，然后从配置项变化表中查询变化的配置项，将变化的配置项的内容和最新的版本号下发给客户端。整个过程如下图所示。


▲ 全量与增量拉取数据对比

例子中 Server 有四个配置项，中间修改了第二个配置项，全量拉取的方法每次都将四个配置项的信息都下发，修改成增量拉取后， Server 只需要维持一张各个 Version 变动的配置项的索引号表，即可实现对每个客户端每次只下发有变化的配置项了。 Version 1 由于是第一个版本号，所以表中记录了所有的配置项索引号，表示客户端第一次拉取的配置项是全量下发的。

我们使用该方法分析了其他的协议，还有两个协议存在该问题，也使用同样的方法进行了优化，效果显著。

使用了该方法优化后，我们仍发现有个别协议较耗流量，其中有一个协议为拉取热词，即 APP 搜索框中推荐的用户搜索最多的词语，这个功能也是所有 APP 中常用的一个功能，如下图所示。


▲ 热词示意

即使使用了增量拉取，一天中也会出现 2~3 次的拉取，因为这个内容一天中确实会变化，因为用户每天搜索的词语都是不一样的。由于热词一次下发的量过大，我们最终从功能逻辑上分析， APP 在后台运行，用户没有操作的情况下，有没有必要拉取这个信息？原先的设计是在用户没有操作的情况下，预取该信息，在用户打开 APP 时搜索框直接就显示最新的热词，在用户体验方面当然是最好的了，如果不预取，我们只要保证每次用户点开 APP 去增量获取一次最新的热词即可，所以在移动网络后台运行时我们修改成不发送该协议， WiFi 下的预取策略我们维持了原样，毕竟 WiFi 下是不消耗移动网络流量的。

我们把这一阶段的优化经验提炼成两个优化法则：

法则一：增量拉取数据
APP 与后台服务器交互时，每次只传输有变化的数据，不变的数据不要重复传输。

法则二：界面展示的数据非 WiFi 下不预取
非 WiFi 情况下，对于 APP 界面展示的数据，在 APP 后台运行时尽量不去拉取。

5、报文发送频率和时机的优化

在将单个协议报文的流量优化之后，我们需要继续从系统层面深度挖掘优化方法，我们通过和竞品对比，发现我们每天发送的报文数量是远远高于竞品的，于是我们思考， APP 后台运行时用户没有操作，是什么驱动我们的 APP 发送了这么多报文的 ?

首先我们发现的是信息上报，对于每款 APP 来说，由于运营的需要，需要后台服务器上采集终端的一些信息，比如上面所说的后台服务器的配置更改，每次配置更改后我们需要统计，有多少用户的 APP 配置已经生效，这里就需要在终端拉取了最新的配置后上报给服务器一条信息，就是终端成功更新配置的时间或者版本号。类似于这种运营需要信息上报的地方很多，我们发现 APP 后台运行时这些信息上报都是实时上报的，如上配置项举例， APP 每次成功拉取到最新配置后即实时上报一条信息。这样导致我们的 APP 一天有 30 多条的信息上报，每次信息上报的报文的实际内容其实是不大的，但是报文的头部是很大的，因为需要标识是哪个终端，就需要使用终端 ID，常用的是 GUID，一个 100 多字节的字符串，还有很多其他字段，由于历史原因，我们 APP 的协议报文头共有 400 字节，我们想优化这个报文头，但是经过详细的与开发了解背景后决定先不改了，因为很多字段都是因为历史原因添加上去的，是有用的。

经过思考，我们对这种实时信息上报提出疑问，后台服务器需要立即得到这种信息吗？答案肯定是否的，运营也不是实时去查看这种数据的，所以我们只要保证用户当天上报该类统计信息即可。于是我们做了一个信息缓存，将需要上报的信息先缓存起来，然后周期性的上报，这里我们选取了 3 小时的周期，一天上报 8 次，这种非实时信息上报为我们节省了很多流量。

其次，我们发现对于某些发送频率较高的协议报文，研究了功能后发现移动网络下用户点击的概率其实是不高的，比如视频的推送，应用更新的推送等等，这些功能都是较费流量的，对于这些功能，移动网络下其实发送频率可以降低，但是不能不发，因为存在某些用户，流量是足够的。所以修改后的方法是 WiFi 下发送频率不变，非 WiFi 下发送频率减半，这样流量可以节省一半。

我们把这一阶段的优化经验提炼成两个优化法则：

法则三：实时的信息上报后台运行时改成非实时上报
后台运行时产生的日志，先缓存起来，后续周期性的统一上报。

法则四：非 WiFi 场景降低耗流量的功能的网络通信频率
对于某些网络通信，给用户推送了一些较费流量的功能，这些网络通信在非 WiFi 场景下可以适当降低频率。

6、多个报文合并发送

经过前面的优化，我们已经发现报文的头是有 400 字节的，由于产品开发团队的现状，分属于不同 feature team 的功能都是在各自的模块中实现的，所以各个团队的周期性的任务都是分别进行的，比如后台运行时 1 小时与后台交互一次，这种消息我们就发现有两个， 3 小时与后台交互一次的消息又有两个。这种现状最直接的影响就是报文数量比竞品多很多，报文的协议头开销就不容忽视。简单计算一下， 1 小时周期的报文一天发送 24 次， 3 小时的报文一天发送 8 次，这样一天共有 24*2+8*2 = 64 个消息，报文头开销 400*64 = 25600 字节。

对于这种情况，我们将这些周期性的发送消息进行了合并，放在一个消息中与后台服务器交互，打破了 feature team 的壁垒，这样一天只有 24 次的消息通信，报文头的开销为 400*24 = 9600 字节，流量消耗大大降低。

这一阶段提炼了一个准则：

法则五：合并网络请求，减少请求次数

7、充分利用 WiFi 传输信息

相信进行到这一步，可挖的优化点已经不多，其实换一个角度，我们还能想到一些优化点。目前大部分用户每天都是能连接 WiFi 一段时间的，不管是公共 WiFi 和公司或者家里的 WiFi，我们后台运行的那些报文如果能充分利用好 WiFi，也能为用户节省流量。比如非实时信息上报，前面优化完之后是 3 小时周期上报，但是上报的时机如果用户不是连接的 WiFi，也会上报，就会消耗流量，其实我们做一个简单的处理，就能收到很好的效果，每次非实时信息上报时都判断一下网络，如果是 WiFi，则立即上报，如果不是 WiFi，则再等待一个周期，如果下一个周期 3 小时内用户连接了 WiFi，则在连接 WiFi 的时刻立即上报，如果用户 3 小时内没有连接 WiFi，仍然是在移动网络下上报。

当然，具体的协议和功能需要根据其特点灵活的利用 WiFi 传输信息，在 WiFi 时需要尽量传输信息，不在 WiFi 时要尽量等待下一个 WiFi 连接的到来。

这一阶段提炼了一个准则：

法则六：尽量利用 WiFi 传输信息

当然，流量优化的方法不限于这六个法则，需要结合具体的逻辑，制定最佳的方案。比如长连接对于 push 类的消息的下发是比较省流量的，它只需要少量的心跳来维持连接，然后服务器有更新和推送等消息时直接通过长连接下发下来，不需要客户端周期性的向服务器发送请求，竞品里面有很多逻辑就是使用了长连接，所以流量消耗较少。但是考虑到引入长连接对产品的架构改动较大，所以这个优化只是排了一个长期计划来一步步实现，不可能短期内实现。

8、优化过程中的经验与思考

本案例讲解了一般的流量测试和优化方法，简单将我们整个流量优化过程中的一些项目经验总结一下。

1）流量优化开始，需要对当前流量的协议和各个协议的流量消耗进行精细化监控，摸清当前的现状。各个协议背后的业务逻辑也需要了解清楚，当初为啥要这样设计，报文交互的频率是基于什么考虑的，后续的优化是需要在此基础上继续探讨可行性方案的。

2）流量优化团队的工作因为涉及到各个开发小组，在项目开始之初是需要得到各个开发小组的支撑许诺的，各个开发小组需要给流量优化项目预留人力的，后续分析的各个优化点涉及的团队是需要进行相关的开发工作的。

3）小步快跑，优化点按计划分批合入发布版本。流量优化涉及到的优化点比较多，实务比较杂，可以按照一个月一个发布版本的节奏，及时将完成的优化点合入版本发布，不要等到最后一次性合入，因为主版本的代码随着特性开发总是在变的，不及时合入发布版本，时间一长，优化点的代码就会和主线产生差异，合入的代价就会增大。

4）自动化流量监控平台需要项目之初就搭建，该平台的精细化监控，既可以提供流量优化分析的素材，又可以快速验证每个优化点修改后的版本，会大大提升开发和测试效率。

5）及时总结，每一阶段的优化完成后，需要将经验总结和固化，后续的优化根据这些经验，能更快的进行分析。

6）不能为了流量优化而牺牲功能，这一点尤其重要，我们在整个流量过程中都遵循该原则，每个优化点的修改都不能降低用户体验。如果因为降流量，用户的体验降低，这个就是舍本逐末，毕竟，用户体验是第一位的。

（原文链接：点此进入）

附录：相关文章汇总

[1] 有关QQ、微信的技术文章：
《微信后台团队：微信后台异步消息队列的优化升级实践分享》
《微信团队原创分享：微信客户端SQLite数据库损坏修复实践》
《腾讯原创分享(一)：如何大幅提升移动网络下手机QQ的图片传输速度和成功率》
《腾讯原创分享(二)：如何大幅压缩移动网络下APP的流量消耗（下篇）》
《腾讯原创分享(二)：如何大幅压缩移动网络下APP的流量消耗（上篇）》
《微信Mars：微信内部正在使用的网络层封装库，即将开源》
《如约而至：微信自用的移动端IM网络层跨平台组件库Mars已正式开源》
《开源libco库：单机千万连接、支撑微信8亿用户的后台框架基石 [源码下载]》
《微信新一代通信安全解决方案：基于TLS1.3的MMTLS详解》
《微信团队原创分享：Android版微信后台保活实战分享(进程保活篇)》
《微信团队原创分享：Android版微信后台保活实战分享(网络保活篇)》
《Android版微信从300KB到30MB的技术演进(PPT讲稿) [附件下载]》
《微信团队原创分享：Android版微信从300KB到30MB的技术演进》
《微信技术总监谈架构：微信之道——大道至简(演讲全文)》
《微信技术总监谈架构：微信之道——大道至简(PPT讲稿) [附件下载]》
《如何解读《微信技术总监谈架构：微信之道——大道至简》》
《微信海量用户背后的后台系统存储架构(视频+PPT) [附件下载]》
《微信异步化改造实践：8亿月活、单机千万连接背后的后台解决方案》
《微信朋友圈海量技术之道PPT [附件下载]》
《微信对网络影响的技术试验及分析（论文全文）》
《一份微信后台技术架构的总结性笔记》
《架构之道：3个程序员成就微信朋友圈日均10亿发布量[有视频]》
《快速裂变：见证微信强大后台架构从0到1的演进历程（一）》
《快速裂变：见证微信强大后台架构从0到1的演进历程（二）》
《微信团队原创分享：Android内存泄漏监控和优化技巧总结》
《全面总结iOS版微信升级iOS9遇到的各种“坑”》
《微信团队原创资源混淆工具：让你的APK立减1M》
《微信团队原创Android资源混淆工具：AndResGuard [有源码]》
《Android版微信安装包“减肥”实战记录》
《iOS版微信安装包“减肥”实战记录》
《移动端IM实践：iOS版微信界面卡顿监测方案》
《微信“红包照片”背后的技术难题》
《移动端IM实践：iOS版微信小视频功能技术方案实录》
《移动端IM实践：Android版微信如何大幅提升交互性能（一）》
《移动端IM实践：Android版微信如何大幅提升交互性能（二）》
《移动端IM实践：实现Android版微信的智能心跳机制》
《移动端IM实践：WhatsApp、Line、微信的心跳策略分析》
《移动端IM实践：谷歌消息推送服务(GCM)研究（来自微信）》
《移动端IM实践：iOS版微信的多设备字体适配方案探讨》
>> 更多同类文章 ……

[2] 有关QQ、微信的技术故事：
《技术往事：创业初期的腾讯——16年前的冬天，谁动了马化腾的代码》
《技术往事：史上最全QQ图标变迁过程，追寻IM巨人的演进历史》
《开发往事：深度讲述2010到2015，微信一路风雨的背后》
《开发往事：微信千年不变的那张闪屏图片的由来》
《开发往事：记录微信3.0版背后的故事（距微信1.0发布9个月时）》
《一个微信实习生自述：我眼中的微信开发团队》
>> 更多同类文章 ……

貌似没有中篇，很长不错的文章，学习了

引用：rilaohn 发表于 2017-02-11 14:43
貌似没有中篇，很长不错的文章，学习了

上下两篇就是全部了。

学习下了，不错。

已收藏,慢慢研究...

已收藏,慢慢研究...

好东西