微信不更新是如何作到控制朋友圈的表情評論

因爲做者本文是作IM出生，自己對即時通信技術比較感興趣，加上身邊都是作即時通信的朋友，因而那天一塊兒吐槽了一下這個功能。對於已經穩定的微信架構，在前端加一些這些功能點，自己就so easy，只是張小龍願不肯意作而已 

這裏不得不佩服的是，微信真的目前來講已經很穩了，之前咱們公司，本身搭建的國際服務器，會每隔段時間出一次事故，即使國內億級用戶量的架構師都已經參與進來了（在這裏深深佩服Telegram的開發者）。即時通信裏面出現一個小問題，就會被無限放大，由於它不像傳統的網站，它是客戶端，須要下載安裝，若是用戶使用發現了問題，就會一直不斷重現，假如是說這個版本的消息推送一直有問題，那麼這個版本，用戶就要被這個問題一直無限的重複騷擾。並且可能你不知不覺，他已經卸載了

總之，想提高技術，推薦能夠去作即時通信，那裏面一年有你在外面五年都學不到的東西，遊戲、社交都算，年終獎也是最高的

---

正式開始

首先，微信採用原生開發，例如IOS，採用的是object-c編寫，那麼就叫客戶端，每一個即時通

訊的客戶端，也是一臺服務器，因此作即時通信的客戶端開發，自己就至關半個全棧工程師。客戶端，就該擁有客戶端的能力，那麼它就擁有數據庫，例如sqlite3，嵌入式的數據庫。Node.js也可使用，例如Electron

據我觀察，微信的表情包評論，也是灰度發佈，即便你先更新了，但不會立馬就能使用，不過你確定能夠看到。

首次更新、登錄，獲得這個結果，而後接受到決定可否看到發送表情包推送的tag，存入數據庫，這樣就每次登錄就會數據庫取這個tag決定可否展現發送表情包評論的控制檯，至關於咱們存入localStorage同樣。

以後，管理層須要回收這個功能，因而須要Push一次

服務器根據必定的規則，採用灰度回收，多是片區輪詢式推送，更新tag，讓客戶端喪失表情評論的選擇界面，這樣就失去了評論功能，可是仍是能夠看到以前的評論，由於源碼裏、數據庫的展現、數據存儲都還在。

這裏很簡單就把如何灰度發佈、灰度回收，講清楚了。既然講了圖片，那麼就講講客戶端的表情存儲

即時通信既是一個服務器，也是一個客戶端，那麼它就是也擁有文件io的能力，調用各類插件的能力。

咱們看到的表情包，例如在IOS上是300個上限，你點進去的時候能夠發現

咱們的gif圖表情包，是縮略圖，是不會動的，，取的第一幀，這裏就要吐槽下Node.js，看似什麼都能作，可是不少事情都作得不太好，壓縮圖片都不是很是完美，即使使用了C++插件，當你重度使用過Node.js，就應該考慮系統學一門真正的後臺語言，例如Golang，可是Node.js在某些地方用來作工具是很是棒的。

這些縮略圖都是存儲在客戶端，多是在某個表的字段裏，存儲着你個人小祕密的數組集合，而後出來遍歷展現一波？

想要在哪裏使用這個組件，引入一波就行，例如在評論中引用，點擊表情向服務器推送，對應的數據type，表情包的src地址。服務器接受到message後，對當前這條朋友圈的相關人推送消息，更新朋友圈提示便可。

這個思路，就跟用戶在微博或者微信點贊同樣，默認是成功的，可是若是失敗了，那麼下次登錄或者刷新時候，會顯示沒有點贊～不止是前端，後端也須要異步，最近有對微服務架構的進行系統學習，感受真的是不少東西相通的，只是方式變了而已。底層的處理思惟邏輯其實都差很少，可是有一點要注意的是，學一個東西，最忌諱學一半而不精，三心二意，這樣很可怕。系統學習一個東西，真的很重要

例如webpack，網上一大堆文章教你怎麼配置，怎麼代碼分割，可是比較少人跟你說webpack的運行機制、熱更新原理、loader、plugin原理，babel插件怎麼寫，怎麼定製開發你的webpack-plugin，這些須要時間學習成本的東西才最重要，才最能提高你本身

若是感受寫得不錯，對你有一點提高，麻煩你點個在看，順便關注一下個人公衆號：前端巔峯

若是你對即時通信、跨平臺重型應用開發、全棧工程師技術棧感興趣，那麼，回覆：加羣  便可假如咱們交流羣～