移动端通讯录的实现方式

   最近优化了通讯录拉取的实现方式，对它进行整理。

   通讯录涉及用户的关系链，用户的具体数据，包括头像，昵称，战绩，在线状态等信息。

   之前的实现方式如下：

   统一的协议，定义TID字段，由客户端填充具体的TID，来拉取用户的信息，由于数据库不属于我们，客户端又需要排序等信息，所以每次拉取，都必须全量拉取。

   结果：

   协议失败率高，客户端经常要等比较久的时间，才能拉取完整。消耗客户端的流量，其中有很多不必要的信息，没必要重复拉取。

   优化后的方式：

   将协议一分为三，包括关系链信息，用户的动态信息（经常变换的信息，如在线状态），用户的静态信息（如昵称，性别等）。

   关系链信息，由于我们只有备份数据库，所以无法完整的了解关系链的变化情况（增加，修改，可以通过时间戳了解，但是删除好友，无法事实的知道。），所以，我们统一采用MD5值的方式进行比较。

   用户端请求上来，会带上次的MD5值，服务器进行对比，如果MD5值有变化，则把新的关系链信息压缩，传送给客户端。

   动态信息，我们获取用户的在线状态，只返回在线的用户数据，因为离线的好友，肯定比在线的好友数量多，所以降低了拉取的数据。

   静态信息，客户端隔一段时间定时拉取（目前是一天），除非用户主动来拉取，不然不会有变化。

   通过这个优化，协议的成功率，提高了5%，还是蛮有成就感的。