1、前言
移动网络时代，手机的流量是个很昂贵的资源（至少暂时是这样）。一个典型的移动端IM在登录后，往往要向服务器同步非常多的数据，如果处理的不好是很费流量的，那么从技术上来讲，有没有节省流量的方法呢？这就是本文要讨论的话题。
2、IM开发干货系列文章
《IM消息送达保证机制实现(一)：保证在线实时消息的可靠投递》
《IM消息送达保证机制实现(二)：保证离线消息的可靠投递》
《如何保证IM实时消息的“时序性”与“一致性”？》
《IM单聊和群聊中的在线状态同步应该用“推”还是“拉”？》
《IM群聊消息如此复杂，如何保证不丢不重？》
《一种Android端IM智能心跳算法的设计与实现探讨（含样例代码）》
《移动端IM登录时拉取数据如何作到省流量？》（本文）
《通俗易懂：基于集群的移动端IM接入层负载均衡方案分享》
《浅谈移动端IM的多点登陆和消息漫游原理》
本系列由公号“编码前线”整理。
3、移动端IM登录时需要拉取什么数据？
移动端IM登陆时，一般要拉取两类数据，一类是“id列表型数据”，一类是“信息详情型数据”。
以微信为例，需要拉取：
1）好友列表List
2）群组列表List
3）群友列表Map
4）好友详情Map
5）群组详情Map
6）群友详情Map
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计算由“端”转嫁到了“云”。