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

2、IM开发干货系列文章
《IM消息送达保证机制实现(一)：保证在线实时消息的可靠投递》

《IM消息送达保证机制实现(二)：保证离线消息的可靠投递》

《如何保证IM实时消息的“时序性”与“一致性”？》

《IM单聊和群聊中的在线状态同步应该用“推”还是“拉”？》

《IM群聊消息如此复杂，如何保证不丢不重？》

《一种Android端IM智能心跳算法的设计与实现探讨（含样例代码）》

《移动端IM登录时拉取数据如何作到省流量？》（本文）

《通俗易懂：基于集群的移动端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计算由“端”转嫁到了“云”。