看過很多產(chǎn)品設(shè)計的文章潮剪，很少有對消息系統(tǒng)這個模塊的設(shè)計講得比較清晰的，最近搜集了一些資料袁稽，結(jié)合實際例子梳理了消息系統(tǒng)的設(shè)計原則柠硕，供參考。

一运提、消息系統(tǒng)定義

消息系統(tǒng)蝗柔，顧名思義即信息的傳達(dá)處理系統(tǒng)。目的是為了讓用戶獲得需要得到的消息及提醒并進(jìn)行處理民泵。

這里的“需要得到”有兩層意思：

1.用戶彼此互動觸發(fā)的信息流(留言癣丧、評論或者回復(fù)、私信等)

2.應(yīng)用希望用戶了解關(guān)注的信息(系統(tǒng)公告等)

消息系統(tǒng)設(shè)計的原則可簡單的歸納為：

1.消息傳播效率最高(獲取栈妆、處理胁编、信息傳達(dá)、用戶反饋等效率)

2.避免產(chǎn)生騷擾(噪音鳞尔、頻繁提示)

二嬉橙、消息分類

不用的平臺和產(chǎn)品本身由于對業(yè)務(wù)的需求不一樣，種類也是有區(qū)別的寥假。大致可分為以下幾種：

三市框、消息系統(tǒng)邏輯實現(xiàn)機(jī)制

消息系統(tǒng)的邏輯精簡后如下：

現(xiàn)對這幾個環(huán)節(jié)分開說明：

1.消息合并

消息在推送之前需要進(jìn)行匯總合并，目的在于提高消息傳播處理效率;減少騷擾糕韧，降低噪音;平衡服務(wù)器壓力枫振。

01.合并周期

固定時間內(nèi)的消息全部匯總(24小時內(nèi)/30天等);

無固定時間(只要未處理/未讀即匯總)

當(dāng)然一般都組合著用：合并24小時內(nèi)未處理消息

02.分類合并

同種類進(jìn)行合并(如n條留言合并為1條)

同一發(fā)起人合并(如張三給你發(fā)來的n條私信)

同一時間周期合并(如24小時共收到n條評論)

03.下面我們來看一下簡書關(guān)于消息的實現(xiàn)是怎么樣的。

簡書的消息系統(tǒng)分得比較細(xì)萤彩，包括評論粪滤、簡信、投稿請求雀扶、喜歡和贊杖小、關(guān)注、打賞、其它提醒等予权。

評論县踢、簡信、喜歡和贊伟件、關(guān)注、打賞等议经，是用戶發(fā)送給用戶的一則消息斧账，有具體的信息內(nèi)容。而提醒煞肾，則是系統(tǒng)發(fā)送的一則消息咧织，其文案格式是固定的，并且對特殊對象一般擁有超鏈接籍救。

04.提醒的語言分析（摘自簡書作者jc-huang）

我們從簡書取一組提醒樣本：

● 3dbe1bd90774 關(guān)注了你

● magicdawn 喜歡了你的文章 《單點登錄的三種實現(xiàn)方式》

● 無良程序 喜歡了你的文章 《基于RESTful API 怎么設(shè)計用戶權(quán)限控制习绢？》

● alexcc4 喜歡了你的文章 《在Nodejs中貫徹單元測試》

● 你在《基于RESTful API 怎么設(shè)計用戶權(quán)限控制？》中收到一條 cnlinjie 的評論

● 你的文章《Session原理》已被加入專題 《ios開發(fā)》

分析句子結(jié)構(gòu)蝙昙，提醒的內(nèi)容無非就是

「誰對一樣屬于誰的事物做了什么操作」

「someone do something in someone’s something」

someone = 提醒的觸發(fā)者闪萄，或者發(fā)送者，標(biāo)記為senderdo

something = 提醒的動作奇颠，評論败去、喜歡、關(guān)注都屬于一個動作烈拒，標(biāo)記為action

something = 提醒的動作作用對象圆裕，這就具體到是哪一篇文章，標(biāo)記為target

someone’s = 提醒的動作作用對象的所有者荆几，標(biāo)記為targetOwner

這就清楚了吓妆，sender和targetOwner就是應(yīng)用的用戶，而target是具體到哪一篇文章吨铸，如果提醒的對象不僅僅局限于文章行拢，還有其他的話，就需要增加一項targetType诞吱，來標(biāo)記目標(biāo)是文章還是其他的什么剂陡。而action，則是固定的狐胎，整個應(yīng)用會觸發(fā)提醒的動作可能就只有那幾樣：評論鸭栖、喜歡、關(guān)注…..（或者其他業(yè)務(wù)需要提醒的動作）

2.消息分發(fā)

消息按照規(guī)則匯總完成后握巢，系統(tǒng)將其通過消息管道推送到用戶晕鹊，以便用戶處理。

01.分發(fā)方式

主要是Push和Pull。

第一種是客戶端使用Pull（拉）的方式溅话，隔一段時間就去服務(wù)器上獲取信息赞赖，看是否有更新的信息出現(xiàn)幸缕。

第二種就是服務(wù)器使用Push（推送）的方式，當(dāng)服務(wù)器端有新信息了，則把最新的信息Push到客戶端上漏峰。

Pull方式更費客戶端的網(wǎng)絡(luò)流量，更主要的是費電量桐腌，還需要我們的程序不停地去監(jiān)測服務(wù)端的變化疾层。

Push可以針對消息的時效性做出及時的通知。

以知乎為例

推的比較常見卵史，需要針對某一個問題維護(hù)著一張關(guān)注者的列表战转，每當(dāng)觸發(fā)這個問題推送的條件時（例如有人回答問題），就把這個通知發(fā)送給每個關(guān)注者以躯。

拉的相對麻煩一點槐秧，就是推的反向，例如每個用戶都有一張關(guān)注問題的列表忧设，每當(dāng)用戶上線的時候刁标，對每個問題進(jìn)行輪詢，當(dāng)問題的事件列表出現(xiàn)了比我原本時間戳大的信息就進(jìn)行拉取址晕。

而我們則根據(jù)消息的不同分類采用不同的獲取方式：

通告和提醒命雀，適合使用拉取的方式，消息產(chǎn)生之后斩箫，會存在消息表中吏砂，用戶在某一特定的時間根據(jù)自己關(guān)注問題的表進(jìn)行消息的拉取，然后添加到自己的消息隊列中乘客，

私信狐血，適合使用推的方式，在發(fā)送者建立一條信息之后易核，同時指定接收者匈织，把消息添加到接收者的消息隊列中。

目前大部分消息優(yōu)先推送未處理消息合并后的總數(shù)牡直，已提醒用戶已有新消息需要處理缀匕。用戶點擊數(shù)字后再去服務(wù)端請求具體的消息內(nèi)容。此種方式綜合考慮了成本碰逸、壓力和體驗乡小。當(dāng)然，某些極端情況下需要進(jìn)行優(yōu)化處理：如未讀消息超過1000饵史，用戶請求時先推送前50條或者放入cache中等满钟。技術(shù)童鞋會有各種手段胜榔，這里不做詳述。

02.分發(fā)頻率(時間)

分發(fā)時間主要根據(jù)消息的優(yōu)先級來做區(qū)隔：

03.分發(fā)管道

分發(fā)管道即消息通知的具體推送渠道湃番，根據(jù)業(yè)務(wù)類型可以分為：App夭织、短信等。

3.用戶處理

根據(jù)前文提到的分發(fā)方式吠撮，對于通知的處理在邏輯上可以分為兩層：通知狀態(tài)的處理和通知內(nèi)容的處理尊惰。

狀態(tài)的處理狹義的理解即為是否已讀(已處理)。

通常初始數(shù)字即為系統(tǒng)推送過來的未讀總量泥兰，用戶點擊數(shù)字進(jìn)入相關(guān)功能列表查閱后讀取的動作完成弄屡，未讀數(shù)字相應(yīng)減少。

有幾種情況需要變通處理：

若用戶未讀信息較多(m=100)逾条，但第一頁列表只能顯示(n=10)條的話，那未讀數(shù)字即為m-n=90;

某些產(chǎn)品會將點擊等同于已讀投剥。即用戶只要點擊無論是否打開列表查看均認(rèn)為已讀师脂。

這樣的處理一般用于重要級別較低的消息。點擊即已讀可有效降低騷擾江锨。

某些重要級別較高的消息已處理狀態(tài)可以定義為用戶進(jìn)行相關(guān)操作后才為已處理吃警，而非查閱。

如用戶進(jìn)行評論啄育、回復(fù)酌心、點擊忽略或點擊刪除等動作時才認(rèn)為已處理。

內(nèi)容的處理狹義的理解即為用戶是否操作

根據(jù)不同消息的種類和業(yè)務(wù)的需要挑豌，操作可分為：

處理：用戶必須點擊功能鏈接進(jìn)行處理安券。如：你的密碼過于簡單，點此進(jìn)行修改;

回復(fù)：如回復(fù)私信氓英，對評論進(jìn)行回復(fù);

確認(rèn)：對消息做出確認(rèn)的反饋侯勉，如某些系統(tǒng)提示可設(shè)置”我已知道，不再提示”的選項;

忽略：用戶進(jìn)行忽略操作或不進(jìn)行任何操作;

刪除：用戶刪除本消息铝阐。

消息處理后的狀態(tài)需要統(tǒng)一

消息需要標(biāo)記是否已處理的狀態(tài)址貌，且狀態(tài)在不同的終端是打通的。

如：用戶在客戶端對消息進(jìn)行了查看徘键，在web站點本消息應(yīng)自動標(biāo)記為已讀狀態(tài)练对。

4.通知回收

回收主要針對用戶已處理消息的操作，用戶之間觸發(fā)的消息一般需要留檔保存吹害。如評論/回復(fù)/留言/私信等螟凭。產(chǎn)品可提供選項詢問用戶是否超過一定周期自動清理。

在部分產(chǎn)品中它呀，還需要考慮功能的優(yōu)先級赂摆。如解除好友關(guān)系或加入黑名單后自動將刪除雙方的私信記錄挟憔。

系統(tǒng)觸發(fā)的消息一般設(shè)置一定的回收刪除時間。如系統(tǒng)提醒烟号、通知绊谭、公告等。過期后自動在產(chǎn)品里刪除汪拥。物理上可以設(shè)置是否備份达传。

過期但用戶未處理消息(用戶長時間未登錄但收到他人的回復(fù))可以根據(jù)業(yè)務(wù)需求來處理。如未讀的私信/評論/回復(fù)永久保留等迫筑。重要未讀消息可嘗試二次推送或使用其他途徑(郵箱宪赶、APP、短信等)通知脯燃。

四搂妻、iOS和安卓的消息提醒設(shè)計

1.IOS版本的APP消息提醒設(shè)計

iOS對于消息通知的提示也有自己的一套設(shè)計規(guī)范，而且分為本地通知和推送通知辕棚。 推送通知或推送消息是服務(wù)器執(zhí)行欲主。

iOS的消息通知有兩種形式，Badge Notification和Alert Notification逝嚎。

Badge Notification

指出現(xiàn)在應(yīng)用程序圖標(biāo)右上角的紅色圓形數(shù)字提醒扁瓢，用于提醒一些無需即時處理的消息，比如程序更新數(shù)补君、未讀郵件數(shù)等引几。Badge Notification只有在Home Screen的對應(yīng)屏上才能看到，因此不適合用于提醒一些重要性高或需要及時處理的通知挽铁。而且Badge Notification的形狀顏色大小等都是默認(rèn)且無法改變的伟桅。

Alert Notification

非常直接地以對話窗口的形式出現(xiàn)在屏幕上，用于重要或需要及時處理的通知叽掘。不過Alert Notification常常粗暴地打斷正在進(jìn)行中的任務(wù)贿讹，強(qiáng)迫用戶馬上做出選擇，且無法匯總查看所有通知够掠，當(dāng)有多條通知時民褂，無法選擇性處理，只能按提供提供的順序一個個處理疯潭。

下面是介紹ios的四種消息通知類型

橫幅（Banner）

橫幅通知會顯示程序的小圖標(biāo)（低分屏下顯示29×29的圖標(biāo)赊堪，高分屏顯示58×58的圖標(biāo)），程序的名字和通知的內(nèi)容竖哩。（只要不是鎖屏狀態(tài)哭廉，都可以從屏幕頂部向下滑打開通知中心。 ）

提醒（Alert） ?

提醒通知不會自動消失相叁，需要用戶與之交互才能關(guān)閉遵绰。設(shè)計師需要設(shè)計通知的具體內(nèi)容辽幌，有時還要為action button（后面會談到）設(shè)計title。

APP設(shè)計師值得注意的是：一條提醒可能會包含一到兩個按鈕椿访。對于有兩個按鈕的提醒乌企，需要把關(guān)閉提醒的按鈕放在左邊，把a(bǔ)ction button放在右邊成玫。 如果只有一個按鈕加酵，這個按鈕應(yīng)該是一個確定按鈕。

標(biāo)記（Badge）

標(biāo)記通知是顯示在程序圖標(biāo)的右上角的紅色橢圓形標(biāo)記哭当，里面顯示的數(shù)字表示需要用戶處理的通知的數(shù)量猪腕。

這種方式都是很常見的。而且也很醒目钦勘。切記陋葡，標(biāo)記圖標(biāo)的設(shè)計尺寸。

聲音（Sound）

聲音提示也是iOS的一種通知方式彻采，支持自定義腐缤，可以與前面三種通知類型搭配使用。

這樣的方式是非常人性化的提醒用戶不要遺忘重要的信息颊亮。比如會議時間等等柴梆。

2.Android 版本的APP消息提醒設(shè)計

最新的Android的通知欄的設(shè)計和功能與前幾代Android系統(tǒng)基本一樣陨溅，也是從屏幕頂部向下拉出终惑，唯一不同的地方就是用戶可以將某條通知按住向左拖動移除該通知。

?

更加人性化门扇，android也有一樣的消息提醒設(shè)計：

通知欄：是一種被普遍接受的通知方式，優(yōu)點是“集中處理”炼邀；

?

我們在設(shè)計APP消息提醒或通知的時候魄揉，還應(yīng)該考慮我們所設(shè)計的APP針對的人群，從而選擇合適的消息推送方式或是消息提醒方案拭宁，下一篇講講消息推送洛退。