请选择 进入手机版 | 继续访问电脑版

默认
打赏 发表评论 6
腾讯原创分享(三):如何大幅压缩移动网络下APP的流量消耗(下篇)

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


1、前言


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

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

2、系列文章


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


3、内容概述


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

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


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

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

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

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

1.jpg
▲ 全量与增量拉取数据对比

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

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

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

2.jpg
▲ 热词示意

即使使用了增量拉取,一天中也会出现 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个月时)
一个微信实习生自述:我眼中的微信开发团队
>> 更多同类文章 ……

即时通讯网 - 即时通讯开发者社区! 来源: - 即时通讯开发者社区!

上一篇:腾讯原创分享(二):如何大幅压缩移动网络下APP的流量消耗(上篇)下一篇:mina2 数据丢失的问题求助

本帖已收录至以下技术专辑

推荐方案
评论 6
貌似没有中篇,很长不错的文章,学习了
签名: 不错!!!!!!!!!!!!!!!
引用:rilaohn 发表于 2017-02-11 14:43
貌似没有中篇,很长不错的文章,学习了

上下两篇就是全部了。
签名: 《快速读懂量子通信、量子加密技术》http://www.52im.net/thread-1604-1-1.html
学习下了,不错。
签名: 地方
已收藏,慢慢研究...
已收藏,慢慢研究...
好东西
打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

返回顶部