我研究了微信的121处离线交互逻辑……

值得一提的是，最近上线的“管理不常联系人”的功能中的“半年内无单聊”、“无共同小群”，是可以在离线状态下正常使用的，而“半年内没有回复过他(她)的朋友圈” 的信息，需要联网才能获取到。这三个功能对应的算法逻辑，是值得我们去探究的。下面我们一个一个来说。

1. “半年内无单聊”

我们在前面推断过，微信的后台服务器并没有储存我们的聊天记录，那么据此推断，“半年内无单聊”这个功能在离线模式下可以使用也是成立的。在这里我们不妨思考一个问题：当我找一个好友聊天后，然后主动在聊天列表中删除他，那么我搜索“半年内无单聊”能搜到他吗?对此我做了如下测试，测试结果显示是可以搜索到的：

通过上述操作验证后，我认为该功能的搜索算法是通过读取微信本地聊天列表的内容来进行相关判断的，如果不在聊天列表内，则直接判定为半年无单聊，如果在聊天列表内，则提取最近一条聊天记录，判断该内容距离现在是否超过半年：

再来思考微信为什么这么做，我想原因就应该是后台并没有储存用户的聊天记录，所以才会有上面这个看上去有点奇葩的算法。这也可以清楚地解释为什么我们在第一次使用这个功能的时候，需要加载几分钟(手机处理数据的能力和服务器不是一个数量级的)，而第二次则很快就能加载出来。

但是从某种程度上来讲，这样的算法又有自己的合理性，试想一下我都把一个人从聊天记录删除了，那么通常情况下是我不想联系他了。对于他出现在我不常联系的好友潜在名单里面，且这样能够被搜索出来，反而多了一层人性化的味道，而不是一味追求逻辑上的正确。

这一点对于我们做产品而言，其实是一个很大的启发。一味追求逻辑正确是标准的技术思维，而一味追求用户体验，不考虑逻辑和技术又属于空谈。三节课联合创始人后显慧(Luke)老师说过这样一句经典的话“看啊，那就是一只走在科技和人文之间的一条狗”，在体验过微信这点的人性化操作后，我对此颇有感触。

2.  “无共同小群”、“半年内朋友圈未回复”

对于“半年内无单聊”，因为前面对“半年内无单聊”进行了逻辑的详细分析，那么“无共同小群”的相应逻辑，就更好理解一些：如果在聊天列表的群里面和在自己通讯录里面的群聊列表里面，找不到该用户，那么就会被筛选出来。

对于“半年内朋友圈未回复”，则是因为前端不能保证储存半年内朋友圈的所有数据，所以该功能需要请求服务器来判断，判断所依附的逻辑，正如该功能自己的文案所示：半年内朋友圈未回复。

六、朋友圈

对于朋友圈，我们可以看到其核心功能，如发朋友圈、评论、回复、点赞、删除都做了离线处理，且刷新的loading(加载)也做了最优处理。

综合来看，微信一共有三种loading(加载)机制：

• loading过程中不能进行任何操作的，只能等提示网络超时;

• loading过程中可以点击返回或者取消等操作，来停止loading;

• loading和其他操作互不影响的。

而在朋友圈页面中loading的加载机制即为第三种：

对此我的分析是，朋友圈在使用频率上可以说仅次于即时通讯，一个小小的优化影响到十亿用户的高频使用，这时候弱网环境、断网环境的容错性就变得尤为重要。对于这样一个使用频率较高的功能，当用户在行驶的地铁上或者火车上等信号非常不稳定的场景下，还可以进行正常发朋友圈、点赞、评论、回复的操作体验，这样的设计就显得格外重要了。

而且，朋友圈相对即时通讯，其实是属于弱关系社交，天然的场景下是不需要对方马上做出回复、点赞、评论等互动。所以，这种逻辑可以说是保证在离线状态下可以使用该功能，且互动信息在有网环境下推送给对方这样符合用户使用场景的最优解决方案了。虽然这一点技术上实现起来应该是相当困难的，但是一旦实现价值也是显而易见的，通过微信朋友圈这个成功的产品就能明显看出来。

七、总结

通过对离线版微信一些常见的功能以及对应操作的分析，我发现微信对于前后端交互处理的原则有以下几点：

• 对于非核心功能，为了尽可能减少对服务器的压力，微信做了大量的前端缓存、前端交互逻辑;

• （编辑：PHP编程网 - 黄冈站长网）

  【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!