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

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

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

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

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

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

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

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

六、朋友圈

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

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

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

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

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

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

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

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

七、总结

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

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

• 在不得不请求服务器时，微信会考虑该结果是用户即时想要的还是可以延后的，如果是即时想要的，就即时请求服务器(如支付)，如果不是那么急迫，则有可能延后请求，以保证网络环境较差的时候，流程可以走通(如拉黑、删除);

•  对于核心功能(如朋友圈)，做到最大限度的容错性以保障用户体验。

另外，在这整个过程中，作为一枚产品狗，我得到了如下的一些启发，且这些信息可以应用到我的工作中，希望也可以对你有帮助：

• 对于成本控制的意识，应该纳入产品方案中去，也许我们做不到像微信那么极致，但是有意识的往这方面考虑，也许会有更好的产品方案;

• 对于核心功能花多大精力去优化，都不为过，因为这才是我们安身立命的根本;

• 不要一味追求逻辑正确，可能有些时候逻辑合适才是更重要的。

(完)

（编辑：西安站长网）

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