我們一直在說，一個優(yōu)秀的產品經(jīng)理，需要保有強烈的探索欲望和好奇心。我們也一直在說，做產品，有時候相比于關注融資、模式和行業(yè)趨勢，不如更多關注一些更具體的產品設計邏輯和實現(xiàn)邏輯。

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

希望這篇文章可以帶給你一些啟發(fā)，希望更多互聯(lián)網(wǎng)從業(yè)者們都可以更少談論一些宏大的融資和模式，更多關注一些實現(xiàn)和落地。

希望你喜歡。

筆者發(fā)現(xiàn)一個存在很久且很奇特的現(xiàn)象，我有一個微信群，群中明明只有 8 個人，但是群縮略圖上卻有 9 個人的頭像，且群內成員有好幾個人換過頭像了，但是縮略圖還是老頭像。在下面左邊的群縮略圖中，第三排最右邊的用戶實際并不在群里，群縮略圖卻顯示了他的頭像。另外，群縮略圖中第二排最右邊的頭像對應的用戶是我，雖然我后來換了頭像(下圖右邊的樣式)，但是群縮略圖中并沒有發(fā)生相應的改變：

也就是說群內沒有的成員，縮略圖卻顯示了他的頭像，我換了頭像，群縮略圖卻沒有變化。于是我就感到奇怪了，難道是之前緩存好了就沒有再刷新過?微信的前端(簡單來講，用戶能用到的部分叫前端)和后端(簡單來講，用戶看不到的邏輯部分叫后端)的交互就這么奇葩?

身為產品狗的我立馬嗅到了一絲不可思議的信息：有可能微信前后端的交互邏輯還有更多奇葩的點。于是我開始著手研究微信前后端邏輯處理的問題，為了更好地還原并且驗證這一命題，我花了一下午的時間在離線模式下使用微信。這樣的目的是希望將微信的前端和后端徹底隔離開，單獨看一下微信前端的表現(xiàn)。經(jīng)過一下午的研究，我用腦圖梳理了得出的成果，如下所示(由于微信有壓縮，可能顯示不清，需要原圖的朋友歡迎在后臺回復“0905”)：

通過這張腦圖，我們可以看出在離線情況下，微信前端的表現(xiàn)點還是很多的，最少有 100 多條記錄。通過對這 100 多條記錄的體驗和觀察，我發(fā)現(xiàn)微信做產品的一個原則：核心功能做到極致，輔助功能盡量做到降低成本。下面我們就詳細來看看微信是怎么實踐這個原則的。

如果每一條我們都來解讀一下，那么就可以寫一本書了，我也要累吐血。所以本文中，我只挑了幾個相對比較有意思且大家比較熟悉的功能模塊(下圖所示)，給大家分享一下自己的觀察，以及對微信PM為什么這么做的分析和復盤，供大家參考，也歡迎拍磚。

PS：以下的分析均是根據(jù)IOS系統(tǒng)上測試的結果進行的，安卓手機中部分結果可能會有差異，這里暫時不做考慮。

一、搜索

下圖為我在離線狀態(tài)下搜索關鍵詞“騰訊”獲取的第1、2、 3 屏的結果：

而當我搜索“王”字的時候，則得到如下的信息：

通過上圖，我們可以看到從上到下依次是：最常使用、聯(lián)系人、群聊、功能、游戲、使用過的小程序、關注的公眾號、聊天記錄、收藏、搜一搜(點擊搜一搜不能打開頁面)，且“最常使用”(王卡助手是小程序，王者集訓營是服務號)和“聯(lián)系人”排在“群聊”前面。

那么為什么會出現(xiàn)這樣的先后排列情況，且“最常使用”和“聯(lián)系人”排在最前面呢?對此我的分析是：

在離線狀態(tài)下可以搜索到內容，說明這些內容可以確定是前端緩存下來的。微信中的搜索使用場景是，當我想找某一個內容(如某個微信好友)，但是可能因為自己微信上內容太多，出現(xiàn)怎么翻也找不到的情況，于是通過關鍵詞搜索，快速定位到我想找到的內容。

至于“聯(lián)系人”、“小程序”以及“公眾號”這三個會優(yōu)于“聊天記錄”呈現(xiàn)，是因為這三者的內容量，和“聊天記錄”這樣的海量內容相比較，要少的多，所以用戶能記住這三個場景的頻次，以及據(jù)此去使用“搜索”這一功能的可能性，要遠遠大于使用“搜索”這一功能查找聊天記錄。而這三者與用戶的關聯(lián)程度又是依次減弱的，所以出現(xiàn)的順序會逐漸相對后置。

我們再來看看在上述圖片中，顯示在下部的“收藏”，對于用戶來講，其實每個人收藏的內容量并不是很大，且大多數(shù)場景下用戶對于自己收藏的內容沒有印象，因此依靠記憶去通過“搜索”這一功能來查找收藏的內容的可能性是很低的，因此排在末置位。

綜上所述，聊天頁面的“搜索”功能的使用場景頻次由高到低是：微信好友、群聊好友、公眾號&小程序、聊天記錄、收藏。而由于用戶在搜索信息呈現(xiàn)的頁面下滑到“聊天記錄”這個功能且通過“搜索”來查找聊天記錄的場景比較少，頻次比較低，所以在“聊天記錄”這個功能之前，微信機智地插入了自己的廣告：功能、游戲。

二、發(fā)送消息

這里涉及到“發(fā)送消息”的操作場景如下圖所示：

在離線狀態(tài)下，我們點擊上圖中的“視頻聊天”、“實時共享位置”、“語音輸入”時，微信都會給出“網(wǎng)絡錯誤”的提示，而點擊這個場景下的其他操作，并不會給出網(wǎng)絡錯誤的提示：

為什么會出現(xiàn)上述的情況呢?對此，我的分析如下：

“視頻聊天”和“實時定位”這兩個功能的使用，對網(wǎng)絡的穩(wěn)定性要求很高。相信大家用微信語音通話的時候，都有過這樣的體驗：聊著聊著對方?jīng)]聲音了，這就是網(wǎng)絡不穩(wěn)定造成的。所以，在離線情況下使用這兩個功能，微信會即時給出網(wǎng)絡方面的提示。

而“語音輸入”功能，則是因為用戶對著微信說話，微信將語音轉化成文字，屬于用戶與用戶強關系社交下的即時通訊輔助。這時候對于用戶來講，他希望可以即時被告知“語音輸入”功能是否能用，如果在用戶不明確網(wǎng)絡是否可行的前提下，用戶點擊了“語音輸入”，等用戶語音錄入完畢、希望傳達信息的時候，微信loading(加載)頁反饋需要等待，或者提示網(wǎng)絡不可用，這種體驗對于用戶來說是很傷的。

所以，微信將這三個功能(視頻聊天、實時共享位置、語音輸入)設置成在用戶使用前就即時判斷是否有網(wǎng)。

而其他的功能(如發(fā)送圖片、個人名片)，邏輯和用戶輸入文字發(fā)送消息出去是一致的，原因是用戶已經(jīng)習慣且接受了當發(fā)送出去的內容因為網(wǎng)絡的問題，對方收到消息會延遲或者收不到消息的情況。

此外需要注意的是，發(fā)紅包和轉賬因為涉及到余額或者從銀行卡支取錢，所以必須請求服務器才能完成。因此操作進行到支付環(huán)節(jié)的時候，因為需要請求服務器，導致這時候在離線情況下，流程將不能如常進行下去。

那么這里面有一個問題：既然知道支付環(huán)節(jié)要聯(lián)網(wǎng)才能走完整個流程，為什么不在整個流程之初(點擊“紅包”、“轉賬”)的時候就直接出現(xiàn)“當前網(wǎng)絡不可用”之類的彈屏提示呢?

對此，我是這么認為的：

第一，如果用戶使用場景是一直處于離線狀態(tài)，那么這個時候，用戶通常不會使用微信等APP;

第二，弱網(wǎng)環(huán)境或者網(wǎng)絡不穩(wěn)定的環(huán)境，要比離線環(huán)境的使用場景多，如果在流程之初(點擊“紅包”、“轉賬”)，就需要請求服務器，告知“網(wǎng)絡不可用”，那么用戶很容易直接放棄該操作;

第三，這么做可以減少前端對服務器的請求次數(shù)，對于月活近十億級用戶的微信來說，減少對服務器的一次請求，在服務器端的支出都有可能降低很多。我想這第三點也應該是里面最重要的一點。

三、微信好友

對于微信的好友處理的相關操作，我發(fā)現(xiàn)微信的原則是：盡最大可能地減少對服務器的請求。這里面涉及到需要請求服務器的點有：保存標簽、上傳圖片(新功能)、投訴、朋友圈權限設置、拉黑、刪除。其中保存標簽和上傳圖片的處理邏輯和發(fā)紅包類似，到最后一步需要請求服務器的時候，才會發(fā)現(xiàn)沒辦法完成整個流程的操作。投訴是直接用的H5 頁面(像微信里面，需要加載的頁面，其加載進度條在頂部的都屬于H5 頁面)，是外部鏈接，所以需要有網(wǎng)絡才能打開。

另外，朋友圈權限設置、拉黑、刪除的操作，均可認為是對好友和自己的權限設置，不讓他看我朋友圈和不看他朋友圈這兩個容易理解，但是拉黑、刪除我這樣的操作所產生的結果，容易讓人迷茫。不知道大家有沒有注意到，當我們被對方刪除或者被拉黑的時候，我們是不知道的，只有在我們給對方發(fā)消息的時候，微信才會提示我們已被刪除或者已被拉黑。為此還有人在網(wǎng)上做了“怎樣看自己被多少好友刪除或拉黑”的教程，且用戶對于這方面的內容關注度還挺高。

既然我們都不知道有沒有被對方刪除，那么我們完全可以理解為，對方對我們的消息做了權限設置。對此，我大膽猜想了當我們發(fā)消息給對方的時候，微信的判斷機制，如下圖所示：

結合前面的情況以及流程的分析，我認為在微信的服務器端，微信并沒有對用戶的聊天內容進行儲存，只是將其作為一個信息傳遞的通道。對此，我們可以這樣理解，我們發(fā)送的消息就像貨物一樣，被服務器由A站拉到B站然后卸載下來后，服務器就不管了，如果B站收了就收了，如果B站不收，也并不會把貨物(聊天內容)讓服務器帶回去儲存在服務器或者返回給A站。

四、收藏

“收藏”這邊比較有意思的點，是在離線狀態(tài)下可以新建收藏。但是“新建收藏”這個功能，我相信極少有人知道。

通過上圖的操作，我們可以看出，新建一個收藏，其實是需要跳轉六個頁面，相對來說操作還是比較繁瑣的，而且中間有很多步驟是需要探索才能完成。

對此，我認為該功能應該還是處于一個需求驗證階段，目前流程做得復雜一些，是為了驗證真正有需求的用戶有多少。既然處于驗證階段，那么以后有可能被下架也有可能繼續(xù)優(yōu)化(之所以判斷該功能處于需求驗證階段，而不是直接吐槽其流程繁瑣的原因是：我想微信的產品經(jīng)理，應該比我水平高吧，我能看到這個流程繁瑣他們能不知道?)。

此外，微信中還有一個地方，其實也是有隱藏功能的，就是對微信好友進行添加“描述——添加照片”的操作：

進行這個操作的時候，如果沒網(wǎng)，那么上傳圖片最后會卡住。如果這時候，打開網(wǎng)絡，那么照片可以上傳成功，且立馬返回到之前的好友“詳細資料”頁：

通過這兩個隱藏功能點的觀察和操作，我們可以看出，雖然都是添加圖片的操作，但是邏輯卻完全不一樣。對微信好友進行添加“描述——添加圖片”操作的時候，需要聯(lián)網(wǎng)才行，而添加“收藏”卻可以在離線狀態(tài)下，進行錄音、添加位置、添加圖片的操作。(對于這背后的產品邏輯和出發(fā)點，我還是有點費解的。如果你有相關的想法，可以留言告訴我，十分感謝。)

五、設置

通過這張圖我們可以看到，涉及到賬號安全的功能模塊，在離線狀態(tài)下都是沒有辦法使用的，這是因為賬號安全的相關處理，放在后端要比前端安全的多，所以不只是微信，其他平臺也是這樣，即選擇通過后臺來處理和賬號安全相關的問題，是比較普遍的做法。

“消息通知”和“隱私”這兩個模塊更像是對權限上的控制，離線狀態(tài)下可以隨意對其操作，避免了每次切換操作都需要請求服務器的情況，從而降低服務器壓力，減少在這方面的支出，這個機制對應的原理和拉黑、刪除好友類似，前面已經(jīng)詳細分析過，這里就不多闡述了。

在“通用”模塊中，我們可以看到除了管理表情需要請求服務器，其他的功能都不需要請求服務器，這樣的設置大大降低了對服務器的請求。

值得一提的是，最近上線的“管理不常聯(lián)系人”的功能中的“半年內無單聊”、“無共同小群”，是可以在離線狀態(tài)下正常使用的，而“半年內沒有回復過他(她)的朋友圈” 的信息，需要聯(lián)網(wǎng)才能獲取到。這三個功能對應的算法邏輯，是值得我們去探究的。下面我們一個一個來說。

1. “半年內無單聊”

我們在前面推斷過，微信的后臺服務器并沒有儲存我們的聊天記錄，那么據(jù)此推斷，“半年內無單聊”這個功能在離線模式下可以使用也是成立的。在這里我們不妨思考一個問題：當我找一個好友聊天后，然后主動在聊天列表中刪除他，那么我搜索“半年內無單聊”能搜到他嗎?對此我做了如下測試，測試結果顯示是可以搜索到的：

通過上述操作驗證后，我認為該功能的搜索算法是通過讀取微信本地聊天列表的內容來進行相關判斷的，如果不在聊天列表內，則直接判定為半年無單聊，如果在聊天列表內，則提取最近一條聊天記錄，判斷該內容距離現(xiàn)在是否超過半年：

再來思考微信為什么這么做，我想原因就應該是后臺并沒有儲存用戶的聊天記錄，所以才會有上面這個看上去有點奇葩的算法。這也可以清楚地解釋為什么我們在第一次使用這個功能的時候，需要加載幾分鐘(手機處理數(shù)據(jù)的能力和服務器不是一個數(shù)量級的)，而第二次則很快就能加載出來。

但是從某種程度上來講，這樣的算法又有自己的合理性，試想一下我都把一個人從聊天記錄刪除了，那么通常情況下是我不想聯(lián)系他了。對于他出現(xiàn)在我不常聯(lián)系的好友潛在名單里面，且這樣能夠被搜索出來，反而多了一層人性化的味道，而不是一味追求邏輯上的正確。

這一點對于我們做產品而言，其實是一個很大的啟發(fā)。一味追求邏輯正確是標準的技術思維，而一味追求用戶體驗，不考慮邏輯和技術又屬于空談。三節(jié)課聯(lián)合創(chuàng)始人后顯慧(Luke)老師說過這樣一句經(jīng)典的話“看啊，那就是一只走在科技和人文之間的一條狗”，在體驗過微信這點的人性化操作后，我對此頗有感觸。

2.  “無共同小群”、“半年內朋友圈未回復”

對于“半年內無單聊”，因為前面對“半年內無單聊”進行了邏輯的詳細分析，那么“無共同小群”的相應邏輯，就更好理解一些：如果在聊天列表的群里面和在自己通訊錄里面的群聊列表里面，找不到該用戶，那么就會被篩選出來。

對于“半年內朋友圈未回復”，則是因為前端不能保證儲存半年內朋友圈的所有數(shù)據(jù)，所以該功能需要請求服務器來判斷，判斷所依附的邏輯，正如該功能自己的文案所示：半年內朋友圈未回復。

六、朋友圈

對于朋友圈，我們可以看到其核心功能，如發(fā)朋友圈、評論、回復、點贊、刪除都做了離線處理，且刷新的loading(加載)也做了最優(yōu)處理。

綜合來看，微信一共有三種loading(加載)機制：

• loading過程中不能進行任何操作的，只能等提示網(wǎng)絡超時;

• loading過程中可以點擊返回或者取消等操作，來停止loading;

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

而在朋友圈頁面中l(wèi)oading的加載機制即為第三種：

對此我的分析是，朋友圈在使用頻率上可以說僅次于即時通訊，一個小小的優(yōu)化影響到十億用戶的高頻使用，這時候弱網(wǎng)環(huán)境、斷網(wǎng)環(huán)境的容錯性就變得尤為重要。對于這樣一個使用頻率較高的功能，當用戶在行駛的地鐵上或者火車上等信號非常不穩(wěn)定的場景下，還可以進行正常發(fā)朋友圈、點贊、評論、回復的操作體驗，這樣的設計就顯得格外重要了。

而且，朋友圈相對即時通訊，其實是屬于弱關系社交，天然的場景下是不需要對方馬上做出回復、點贊、評論等互動。所以，這種邏輯可以說是保證在離線狀態(tài)下可以使用該功能，且互動信息在有網(wǎng)環(huán)境下推送給對方這樣符合用戶使用場景的最優(yōu)解決方案了。雖然這一點技術上實現(xiàn)起來應該是相當困難的，但是一旦實現(xiàn)價值也是顯而易見的，通過微信朋友圈這個成功的產品就能明顯看出來。

七、總結

通過對離線版微信一些常見的功能以及對應操作的分析，我發(fā)現(xiàn)微信對于前后端交互處理的原則有以下幾點：

• 對于非核心功能，為了盡可能減少對服務器的壓力，微信做了大量的前端緩存、前端交互邏輯;

• 在不得不請求服務器時，微信會考慮該結果是用戶即時想要的還是可以延后的，如果是即時想要的，就即時請求服務器(如支付)，如果不是那么急迫，則有可能延后請求，以保證網(wǎng)絡環(huán)境較差的時候，流程可以走通(如拉黑、刪除);

•  對于核心功能(如朋友圈)，做到最大限度的容錯性以保障用戶體驗。

另外，在這整個過程中，作為一枚產品狗，我得到了如下的一些啟發(fā)，且這些信息可以應用到我的工作中，希望也可以對你有幫助：

• 對于成本控制的意識，應該納入產品方案中去，也許我們做不到像微信那么極致，但是有意識的往這方面考慮，也許會有更好的產品方案;

• 對于核心功能花多大精力去優(yōu)化，都不為過，因為這才是我們安身立命的根本;

• 不要一味追求邏輯正確，可能有些時候邏輯合適才是更重要的。