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

小早说：我们也一直在说，做产品，有时候相比于关注融资、模式和行业趋势，不如更多关注一些更具体的产品设计逻辑和实现逻辑。

编者按：

我们一直在说，一个优秀的产品经理，需要保有强烈的探索欲望和好奇心。我们也一直在说，做产品，有时候相比于关注融资、模式和行业趋势，不如更多关注一些更具体的产品设计逻辑和实现逻辑。

在如上两方面，这篇文章的作者都做到了。

希望这篇文章可以带给你一些启发，希望更多互联网从业者们都可以更少谈论一些宏大的融资和模式，更多关注一些实现和落地。

笔者发现一个存在很久且很奇特的现象，我有一个微信群，群中明明只有8个人，但是群缩略图上却有9个人的头像，且群内成员有好几个人换过头像了，但是缩略图还是老头像。在下面左边的群缩略图中，第三排最右边的用户实际并不在群里，群缩略图却显示了他的头像。另外，群缩略图中第二排最右边的头像对应的用户是我，虽然我后来换了头像(下图右边的样式)，但是群缩略图中并没有发生相应的改变：

也就是说群内没有的成员，缩略图却显示了他的头像，我换了头像，群缩略图却没有变化。于是我就感到奇怪了，难道是之前缓存好了就没有再刷新过?微信的前端(简单来讲，用户能用到的部分叫前端)和后端(简单来讲，用户看不到的逻辑部分叫后端)的交互就这么奇葩?

身为产品狗的我立马嗅到了一丝不可思议的信息：有可能微信前后端的交互逻辑还有更多奇葩的点。于是我开始着手研究微信前后端逻辑处理的问题，为了更好地还原并且验证这一命题，我花了一下午的时间在离线模式下使用微信。这样的目的是希望将微信的前端和后端彻底隔离开，单独看一下微信前端的表现。经过一下午的研究，我用脑图梳理了得出的成果，如下所示(由于微信有压缩，可能显示不清，需要原图的朋友欢迎在后台回复“97”查看)：

通过这张脑图，我们可以看出在离线情况下，微信前端的表现点还是很多的，最少有100多条记录。通过对这100多条记录的体验和观察，我发现微信做产品的一个原则：核心功能做到极致，辅助功能尽量做到降低成本。下面我们就详细来看看微信是怎么实践这个原则的。

如果每一条我们都来解读一下，那么就可以写一本书了，我也要累吐血。所以本文中，我只挑了几个相对比较有意思且大家比较熟悉的功能模块(下图所示)，给大家分享一下自己的观察，以及对微信PM为什么这么做的分析和复盘，供大家参考，也欢迎拍砖。

PS：以下的分析均是根据IOS系统上测试的结果进行的，安卓手机中部分结果可能会有差异，这里暂时不做考虑。

一、搜索

下图为我在离线状态下搜索关键词“腾讯”获取的第1、2、3屏的结果：

而当我搜索“王”字的时候，则得到如下的信息：

通过上图，我们可以看到从上到下依次是：最常使用、联系人、群聊、功能、游戏、使用过的小程序、关注的公众号、聊天记录、收藏、搜一搜(点击搜一搜不能打开页面)，且“最常使用”(王卡助手是小程序，王者集训营是服务号)和“联系人”排在“群聊”前面。

那么为什么会出现这样的先后排列情况，且“最常使用”和“联系人”排在最前面呢?对此我的分析是：

在离线状态下可以搜索到内容，说明这些内容可以确定是前端缓存下来的。微信中的搜索使用场景是，当我想找某一个内容(如某个微信好友)，但是可能因为自己微信上内容太多，出现怎么翻也找不到的情况，于是通过关键词搜索，快速定位到我想找到的内容。

至于“联系人”、“小程序”以及“公众号”这三个会优于“聊天记录”呈现，是因为这三者的内容量，和“聊天记录”这样的海量内容相比较，要少的多，所以用户能记住这三个场景的频次，以及据此去使用“搜索”这一功能的可能性，要远远大于使用“搜索”这一功能查找聊天记录。而这三者与用户的关联程度又是依次减弱的，所以出现的顺序会逐渐相对后置。

我们再来看看在上述图片中，显示在下部的“收藏”，对于用户来讲，其实每个人收藏的内容量并不是很大，且大多数场景下用户对于自己收藏的内容没有印象，因此依靠记忆去通过“搜索”这一功能来查找收藏的内容的可能性是很低的，因此排在末置位。

综上所述，聊天页面的“搜索”功能的使用场景频次由高到低是：微信好友、群聊好友、公众号&小程序、聊天记录、收藏。而由于用户在搜索信息呈现的页面下滑到“聊天记录”这个功能且通过“搜索”来查找聊天记录的场景比较少，频次比较低，所以在“聊天记录”这个功能之前，微信机智地插入了自己的广告：功能、游戏。

二、发送消息

这里涉及到“发送消息”的操作场景如下图所示：

在离线状态下，我们点击上图中的“视频聊天”、“实时共享位置”、“语音输入”时，微信都会给出“网络错误”的提示，而点击这个场景下的其他操作，并不会给出网络错误的提示：

为什么会出现上述的情况呢?对此，我的分析如下：

“视频聊天”和“实时定位”这两个功能的使用，对网络的稳定性要求很高。相信大家用微信语音通话的时候，都有过这样的体验：聊着聊着对方没声音了，这就是网络不稳定造成的。所以，在离线情况下使用这两个功能，微信会即时给出网络方面的提示。

而“语音输入”功能，则是因为用户对着微信说话，微信将语音转化成文字，属于用户与用户强关系社交下的即时通讯辅助。这时候对于用户来讲，他希望可以即时被告知“语音输入”功能是否能用，如果在用户不明确网络是否可行的前提下，用户点击了“语音输入”，等用户语音录入完毕、希望传达信息的时候，微信loading(加载)页反馈需要等待，或者提示网络不可用，这种体验对于用户来说是很伤的。

所以，微信将这三个功能(视频聊天、实时共享位置、语音输入)设置成在用户使用前就即时判断是否有网。

而其他的功能(如发送图片、个人名片)，逻辑和用户输入文字发送消息出去是一致的，原因是用户已经习惯且接受了当发送出去的内容因为网络的问题，对方收到消息会延迟或者收不到消息的情况。

此外需要注意的是，发红包和转账因为涉及到余额或者从银行卡支取钱，所以必须请求服务器才能完成。因此操作进行到支付环节的时候，因为需要请求服务器，导致这时候在离线情况下，流程将不能如常进行下去。

那么这里面有一个问题：既然知道支付环节要联网才能走完整个流程，为什么不在整个流程之初(点击“红包”、“转账”)的时候就直接出现“当前网络不可用”之类的弹屏提示呢?

对此，我是这么认为的：

第一，如果用户使用场景是一直处于离线状态，那么这个时候，用户通常不会使用微信等APP;

第二，弱网环境或者网络不稳定的环境，要比离线环境的使用场景多，如果在流程之初(点击“红包”、“转账”)，就需要请求服务器，告知“网络不可用”，那么用户很容易直接放弃该操作;

第三，这么做可以减少前端对服务器的请求次数，对于月活近十亿级用户的微信来说，减少对服务器的一次请求，在服务器端的支出都有可能降低很多。我想这第三点也应该是里面最重要的一点。

三、微信好友

对于微信的好友处理的相关操作，我发现微信的原则是：尽最大可能地减少对服务器的请求。这里面涉及到需要请求服务器的点有：保存标签、上传图片(新功能)、投诉、朋友圈权限设置、拉黑、删除。其中保存标签和上传图片的处理逻辑和发红包类似，到最后一步需要请求服务器的时候，才会发现没办法完成整个流程的操作。投诉是直接用的H5页面(像微信里面，需要加载的页面，其加载进度条在顶部的都属于H5页面)，是外部链接，所以需要有网络才能打开。

另外，朋友圈权限设置、拉黑、删除的操作，均可认为是对好友和自己的权限设置，不让他看我朋友圈和不看他朋友圈这两个容易理解，但是拉黑、删除我这样的操作所产生的结果，容易让人迷茫。不知道大家有没有注意到，当我们被对方删除或者被拉黑的时候，我们是不知道的，只有在我们给对方发消息的时候，微信才会提示我们已被删除或者已被拉黑。为此还有人在网上做了“怎样看自己被多少好友删除或拉黑”的教程，且用户对于这方面的内容关注度还挺高。

既然我们都不知道有没有被对方删除，那么我们完全可以理解为，对方对我们的消息做了权限设置。对此，我大胆猜想了当我们发消息给对方的时候，微信的判断机制，如下图所示：

结合前面的情况以及流程的分析，我认为在微信的服务器端，微信并没有对用户的聊天内容进行储存，只是将其作为一个信息传递的通道。对此，我们可以这样理解，我们发送的消息就像货物一样，被服务器由A站拉到B站然后卸载下来后，服务器就不管了，如果B站收了就收了，如果B站不收，也并不会把货物(聊天内容)让服务器带回去储存在服务器或者返回给A站。

四、收藏

“收藏”这边比较有意思的点，是在离线状态下可以新建收藏。但是“新建收藏”这个功能，我相信极少有人知道。

通过上图的操作，我们可以看出，新建一个收藏，其实是需要跳转六个页面，相对来说操作还是比较繁琐的，而且中间有很多步骤是需要探索才能完成。

对此，我认为该功能应该还是处于一个需求验证阶段，目前流程做得复杂一些，是为了验证真正有需求的用户有多少。既然处于验证阶段，那么以后有可能被下架也有可能继续优化(之所以判断该功能处于需求验证阶段，而不是直接吐槽其流程繁琐的原因是：我想微信的产品经理，应该比我水平高吧，我能看到这个流程繁琐他们能不知道?)。

此外，微信中还有一个地方，其实也是有隐藏功能的，就是对微信好友进行添加“描述——添加照片”的操作：

进行这个操作的时候，如果没网，那么上传图片最后会卡住。如果这时候，打开网络，那么照片可以上传成功，且立马返回到之前的好友“详细资料”页：

通过这两个隐藏功能点的观察和操作，我们可以看出，虽然都是添加图片的操作，但是逻辑却完全不一样。对微信好友进行添加“描述——添加图片”操作的时候，需要联网才行，而添加“收藏”却可以在离线状态下，进行录音、添加位置、添加图片的操作。(对于这背后的产品逻辑和出发点，我还是有点费解的。如果你有相关的想法，可以留言告诉我，十分感谢。)

五、设置

通过这张图我们可以看到，涉及到账号安全的功能模块，在离线状态下都是没有办法使用的，这是因为账号安全的相关处理，放在后端要比前端安全的多，所以不只是微信，其他平台也是这样，即选择通过后台来处理和账号安全相关的问题，是比较普遍的做法。

“消息通知”和“隐私”这两个模块更像是对权限上的控制，离线状态下可以随意对其操作，避免了每次切换操作都需要请求服务器的情况，从而降低服务器压力，减少在这方面的支出，这个机制对应的原理和拉黑、删除好友类似，前面已经详细分析过，这里就不多阐述了。

在“通用”模块中，我们可以看到除了管理表情需要请求服务器，其他的功能都不需要请求服务器，这样的设置大大降低了对服务器的请求。

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

1. “半年内无单聊”

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

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

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

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

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

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

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

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

六、朋友圈

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

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

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

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

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

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

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

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

七、总结

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

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

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

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

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

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

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

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

本文链接: http://www.yixieshi.com/93707.html (转载请保留)