默认
打赏 发表评论 9
想开发IM:买成品怕坑?租第3方怕贵?找开源自已撸?尽量别走弯路了... 找站长给点建议
移动端IM登录时拉取数据如何作到省流量?
微信扫一扫关注!

1、前言


移动网络时代,手机的流量是个很昂贵的资源(至少暂时是这样)。一个典型的移动端IM在登录后,往往要向服务器同步非常多的数据,如果处理的不好是很费流量的,那么从技术上来讲,有没有节省流量的方法呢?这就是本文要讨论的话题。

2、IM开发干货系列文章


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


另外,如果您是IM开发初学者,强烈建议首先阅读《新手入门一篇就够:从零开发移动端IM》。

3、移动端IM登录时需要拉取什么数据?


移动端IM登陆时,一般要拉取两类数据,一类是“id列表型数据”,一类是“信息详情型数据”。

以微信为例,需要拉取:

  • 1)好友列表List<user-id>,即所有好友的id(id+name);
  • 2)群组列表List<group-id>,即所有加入群的id(id+name);
  • 3)群友列表Map<group-id, List<group-user-id>>,所有群友的id(id+name);
  • 4)好友详情Map<user-id, User>,所有好友的详情(昵称,备注,标签,地区,相册等);
  • 5)群组详情Map<group-id, Group>,所有群组的详情(二维码,公告,是否免打扰等);
  • 6)群友详情Map<group-id, Map<user-id, User>>,所有群友的详情(昵称,备注,标签,地区,相册等);
  • 7)其他,例如离线消息…

4、能不能在登录的过程中不拉取这些数据,而在登录后拉取?


如果登录时不拉取,登陆后刷好友列表,刷群列表,群成员会很慢。

如果登录时拉取,登陆过程可能会很慢(微信的“大月亮背景”要等多长时间?QQ登录要等30s?)。

通常,为了保证登录后的体验,一般是在登录过程中拉取。

5、能不能直接复用客户端本地的数据?


原则上,不能直接复用客户端本地的数据,因为不能确保本地的数据是最新的。

但是每次登录都需要拉取,太费流量了,有没有优化方法?

常用优化方法有两种:

  • 1)延迟拉取,按需拉取;
  • 2)时间戳。

6、延迟拉取,按需拉取为什么有效?为什么能够减少拉取流量?


用户在使用移动端IM的过程中,有些数据是一定会使用到的,有些数据是不一定会使用到的。对于一定会使用到的数据,登录时拉取可以提升后续用户体验。对于不一定会使用到的数据,登录时拉取可能浪费流量,这些数据如果进行“延迟拉取”,可以节省流量。

7、哪些数据不登录后不一定会使用,可以延迟拉取?


这个问题的答案和业务紧密相关,以微信为例:

一定会使用到的数据:好友列表(主页面要展示user-name),群组列表(主界面要展示group-name)。
不一定会使用到的数据:好友详情,群组详情,群友列表,群友详情。

故,对于微信,登录时只需要拉取好友列表(id+name)与群组列表(id+name)即可,而其他数据,等用户真正点击和使用时再拉取即可,这样就可以大大减少拉取流量。

8、时间戳为什么有效?为什么能够减少拉取流量?


本地数据不能直接使用的原因是,不确定数据是否最新,拉取服务器时间戳与本地时间戳进行比对,如果本地是最新的数据,就能避免重新拉取。id列表数据的变化频度是比较低的(增加id,减少id),时间戳机制非常的有效。

9、加入时间戳机制后,数据拉取流程有什么变化?


假设有100个好友,以好友详情数据的拉取为例,没有时间戳之前,直接向服务器拉取这100个好友的详情数据。

在有了时间戳之后,数据拉取流程变为:

  • 1)先拉取100个好友的时间戳;
  • 2)客户端将100个好友的时间戳与本地时间戳对比,找出差异,假设有10个好友的信息发生了变化,时间戳改变了;
  • 3)拉取有变化的10个好友的信息。

优点是:大大减少了数据传输量(由拉取100个好友,降低到拉取10个好友);
缺点是:增加了一次网络交互(原来直接拉取,现在需要分别拉取时间戳与差异数据)。

10、使用时间戳的同时,能否降低网络交互次数呢?


答案是:可以!

客户端对时间戳的使用,往往采取“客户端拉取时间戳”+“客户端比对时间戳”+“客户端再次拉取差异数据”的方式进行,“时间戳比对”的的CPU计算发生在客户端,其实,这个计算可以转嫁到服务器。

具体步骤为:

  • 1)客户端上传100个好友的时间戳;
  • 2)“服务端”收到客户端上传的时间戳,与最新时间戳对比,找出差异,假设有10个好友的信息发生了变化,服务端可以直接将有差异的10个好友的数据返回。

优点是:客户端减少了一次网络请求;
缺点是:比对时间戳差异的CPU计算由“端”转嫁到了“云”。

(原文链接:点此进入

全站即时通讯技术资料分类


[1] 网络编程基础资料:
TCP/IP详解 - 第11章·UDP:用户数据报协议
TCP/IP详解 - 第17章·TCP:传输控制协议
TCP/IP详解 - 第18章·TCP连接的建立与终止
TCP/IP详解 - 第21章·TCP的超时与重传
技术往事:改变世界的TCP/IP协议(珍贵多图、手机慎点)
通俗易懂-深入理解TCP协议(上):理论基础
通俗易懂-深入理解TCP协议(下):RTT、滑动窗口、拥塞处理
理论经典:TCP协议的3次握手与4次挥手过程详解
理论联系实际:Wireshark抓包分析TCP 3次握手、4次挥手过程
计算机网络通讯协议关系图(中文珍藏版)
UDP中一个包的大小最大能多大?
Java新一代网络编程模型AIO原理及Linux系统AIO介绍
NIO框架入门(一):服务端基于Netty4的UDP双向通信Demo演示
NIO框架入门(二):服务端基于MINA2的UDP双向通信Demo演示
NIO框架入门(三):iOS与MINA2、Netty4的跨平台UDP双向通信实战
NIO框架入门(四):Android与MINA2、Netty4的跨平台UDP双向通信实战
P2P技术详解(一):NAT详解——详细原理、P2P简介
P2P技术详解(二):P2P中的NAT穿越(打洞)方案详解
P2P技术详解(三):P2P技术之STUN、TURN、ICE详解
高性能网络编程(一):单台服务器并发TCP连接数到底可以有多少
高性能网络编程(二):上一个10年,著名的C10K并发连接问题
高性能网络编程(三):下一个10年,是时候考虑C10M并发问题了
高性能网络编程(四):从C10K到C10M高性能网络应用的理论探索
>> 更多同类文章 ……

[2] 有关IM/推送的通信格式、协议的选择:
为什么QQ用的是UDP协议而不是TCP协议?
移动端即时通讯协议选择:UDP还是TCP?
如何选择即时通讯应用的数据传输格式
强列建议将Protobuf作为你的即时通讯应用数据传输格式
全方位评测:Protobuf性能到底有没有比JSON快5倍?
移动端IM开发需要面对的技术问题(含通信协议选择)
简述移动端IM开发的那些坑:架构设计、通信协议和客户端
理论联系实际:一套典型的IM通信协议设计详解
58到家实时消息系统的协议设计等技术实践分享
>> 更多同类文章 ……

[3] 有关IM/推送的心跳保活处理:
Android进程保活详解:一篇文章解决你的所有疑问
Android端消息推送总结:实现原理、心跳保活、遇到的问题等
深入的聊聊Android消息推送这件小事
为何基于TCP协议的移动端IM仍然需要心跳保活机制?
微信团队原创分享:Android版微信后台保活实战分享(进程保活篇)
微信团队原创分享:Android版微信后台保活实战分享(网络保活篇)
移动端IM实践:实现Android版微信的智能心跳机制
移动端IM实践:WhatsApp、Line、微信的心跳策略分析
>> 更多同类文章 ……

[4] 有关WEB端即时通讯开发:
新手入门贴:史上最全Web端即时通讯技术原理详解
Web端即时通讯技术盘点:短轮询、Comet、Websocket、SSE
SSE技术详解:一种全新的HTML5服务器推送事件技术
Comet技术详解:基于HTTP长连接的Web端实时通信技术
WebSocket详解(一):初步认识WebSocket技术
WebSocket详解(二):技术原理、代码演示和应用案例
WebSocket详解(三):深入WebSocket通信协议细节
socket.io实现消息推送的一点实践及思路
LinkedIn的Web端即时通讯实践:实现单机几十万条长连接
Web端即时通讯技术的发展与WebSocket、Socket.io的技术实践
>> 更多同类文章 ……

[5] 有关IM架构设计:
浅谈IM系统的架构设计
简述移动端IM开发的那些坑:架构设计、通信协议和客户端
一套原创分布式即时通讯(IM)系统理论架构方案
从零到卓越:京东客服即时通讯系统的技术架构演进历程
蘑菇街即时通讯/IM服务器开发之架构选择
腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT
微信技术总监谈架构:微信之道——大道至简(演讲全文)
如何解读《微信技术总监谈架构:微信之道——大道至简》
快速裂变:见证微信强大后台架构从0到1的演进历程(一)
17年的实践:腾讯海量产品的技术方法论
>> 更多同类文章 ……

[6] 有关IM安全的文章:
即时通讯安全篇(一):正确地理解和使用Android端加密算法
即时通讯安全篇(二):探讨组合加密算法在IM中的应用
即时通讯安全篇(三):常用加解密算法与通讯安全讲解
即时通讯安全篇(四):实例分析Android中密钥硬编码的风险
即时通讯安全篇(五):对称加密技术在Android平台上的应用实践
即时通讯安全篇(六):非对称加密技术的原理与应用实践
传输层安全协议SSL/TLS的Java平台实现简介和Demo演示
理论联系实际:一套典型的IM通信协议设计详解(含安全层设计)
微信新一代通信安全解决方案:基于TLS1.3的MMTLS详解
来自阿里OpenIM:打造安全可靠即时通讯服务的技术实践分享
简述实时音视频聊天中端到端加密(E2EE)的工作原理
移动端安全通信的利器——端到端加密(E2EE)技术详解
>> 更多同类文章 ……

[7] 有关实时音视频开发:
即时通讯音视频开发(一):视频编解码之理论概述
即时通讯音视频开发(二):视频编解码之数字视频介绍
即时通讯音视频开发(三):视频编解码之编码基础
即时通讯音视频开发(四):视频编解码之预测技术介绍
即时通讯音视频开发(五):认识主流视频编码技术H.264
即时通讯音视频开发(六):如何开始音频编解码技术的学习
即时通讯音视频开发(七):音频基础及编码原理入门
即时通讯音视频开发(八):常见的实时语音通讯编码标准
即时通讯音视频开发(九):实时语音通讯的回音及回音消除概述
即时通讯音视频开发(十):实时语音通讯的回音消除技术详解
即时通讯音视频开发(十一):实时语音通讯丢包补偿技术详解
即时通讯音视频开发(十二):多人实时音视频聊天架构探讨
即时通讯音视频开发(十三):实时视频编码H.264的特点与优势
即时通讯音视频开发(十四):实时音视频数据传输协议介绍
即时通讯音视频开发(十五):聊聊P2P与实时音视频的应用情况
即时通讯音视频开发(十六):移动端实时音视频开发的几个建议
即时通讯音视频开发(十七):视频编码H.264、VP8的前世今生
网易视频云技术分享:音频处理与压缩技术快速入门
学习RFC3550:RTP/RTCP实时传输协议基础知识
简述开源实时音视频技术WebRTC的优缺点
良心分享:WebRTC 零基础开发者教程(中文)
开源实时音视频技术WebRTC中RTP/RTCP数据传输协议的应用
基于RTMP数据传输协议的实时流媒体技术研究(论文全文)
声网架构师谈实时音视频云的实现难点(视频采访)
浅谈开发实时视频直播平台的技术要点
还在靠“喂喂喂”测试实时语音通话质量?本文教你科学的评测方法!
实现延迟低于500毫秒的1080P实时音视频直播的实践分享
移动端实时视频直播技术实践:如何做到实时秒开、流畅不卡
如何用最简单的方法测试你的实时音视频方案
技术揭秘:支持百万级粉丝互动的Facebook实时视频直播
简述实时音视频聊天中端到端加密(E2EE)的工作原理
>> 更多同类文章 ……

[8] IM开发综合文章:
移动端IM开发需要面对的技术问题
开发IM是自己设计协议用字节流好还是字符流好?
请问有人知道语音留言聊天的主流实现方式吗?
IM消息送达保证机制实现(一):保证在线实时消息的可靠投递
IM消息送达保证机制实现(二):保证离线消息的可靠投递
如何保证IM实时消息的“时序性”与“一致性”?
IM单聊和群聊中的在线状态同步应该用“推”还是“拉”?
IM群聊消息如此复杂,如何保证不丢不重?
谈谈移动端 IM 开发中登录请求的优化
移动端IM登录时拉取数据如何作到省流量?
完全自已开发的IM该如何设计“失败重试”机制?
微信对网络影响的技术试验及分析(论文全文)
即时通讯系统的原理、技术和应用(技术论文)
开源IM工程“蘑菇街TeamTalk”的现状:一场有始无终的开源秀
腾讯原创分享(一):如何大幅提升移动网络下手机QQ的图片传输速度和成功率
如约而至:微信自用的移动端IM网络层跨平台组件库Mars已正式开源
>> 更多同类文章 ……

[9] 开源移动端IM技术框架资料:
开源移动端IM技术框架MobileIMSDK:快速入门
开源移动端IM技术框架MobileIMSDK:常见问题解答
开源移动端IM技术框架MobileIMSDK:压力测试报告
>> 更多同类文章 ……

[10] 有关推送技术的文章:
iOS的推送服务APNs详解:设计思路、技术原理及缺陷等
Android端消息推送总结:实现原理、心跳保活、遇到的问题等
扫盲贴:认识MQTT通信协议
一个基于MQTT通信协议的完整Android推送Demo
IBM技术经理访谈:MQTT协议的制定历程、发展现状等
求教android消息推送:GCM、XMPP、MQTT三种方案的优劣
移动端实时消息推送技术浅析
扫盲贴:浅谈iOS和Android后台实时消息推送的原理和区别
绝对干货:基于Netty实现海量接入的推送服务技术要点
移动端IM实践:谷歌消息推送服务(GCM)研究(来自微信)
为何微信、QQ这样的IM工具不使用GCM服务推送消息?
极光推送系统大规模高并发架构的技术实践分享
从HTTP到MQTT:一个基于位置服务的APP数据通信实践概述
魅族2500万长连接的实时消息推送架构的技术实践分享
专访魅族架构师:海量长连接的实时消息推送系统的心得体会
深入的聊聊Android消息推送这件小事
基于WebSocket实现Hybrid移动应用的消息推送实践(含代码示例)
一个基于长连接的安全可扩展的订阅/推送服务实现思路
>> 更多同类文章 ……

[11] 更多即时通讯技术好文分类:
http://www.52im.net/forum.php?mod=collection&op=all

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

评分

1

查看评分

上一篇:IM分布式离线消息分页,怎么减少重复请求?下一篇:微信后台团队:微信后台异步消息队列的优化升级实践分享

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

推荐方案
评论 9
很好
签名: 啊啊啊
总结的不错,有借鉴意义
签名: 该会员没有填写今日想说内容.
引用:一地鼻血 发表于 2017-04-30 16:41
总结的不错,有借鉴意义

微信的做法类似
好文章,收藏了
开拓思路
签名: now start 。。。
时间戳换成版本号是不是更恰当
引用:七海的游风 发表于 2020-01-13 17:06
时间戳换成版本号是不是更恰当

可以,这个没有固定的套路,能达到目的就可以了
打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

返回顶部