看過很多產品設計的文章，很少有對消息系統這個模塊的設計講得比較清晰的，最近搜集了一些資料，結合實際例子梳理了消息系統的設計原則，供參考。

一、消息系統定義

消息系統，顧名思義即信息的傳達處理系統。目的是為了讓用戶獲得需要得到的消息及提醒并進行處理。

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

• 用戶彼此互動觸發的信息流(留言、評論或者回復、私信等)
• 應用希望用戶了解關注的信息(系統公告等)

消息系統設計的原則可簡單的歸納為：

• 消息傳播效率最高(獲取、處理、信息傳達、用戶反饋等效率)
• 避免產生騷擾(噪音、頻繁提示)

二、消息分類

不用的平臺和產品本身由于對業務的需求不一樣，種類也是有區別的。大致可分為以下幾種：

三、消息系統邏輯實現機制

消息系統的邏輯精簡后如下：

現對這幾個環節分開說明：

1.消息合并

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

合并周期

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

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

當然一般都組合著用：合并24小時內未處理消息

分類合并

• 同種類進行合并(如n條留言合并為1條)
• 同一發起人合并(如張三給你發來的n條私信)
• 同一時間周期合并(如24小時共收到n條評論)

下面我們來看一下簡書關于消息的實現是怎么樣的。

簡書的消息系統分得比較細，包括評論、簡信、投稿請求、喜歡和贊、關注、打賞、其它提醒等。

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

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

• 3dbe1bd90774 關注了你
• magicdawn 喜歡了你的文章 《單點登錄的三種實現方式》
• 無良程序 喜歡了你的文章 《基于RESTful API 怎么設計用戶權限控制？》
• alexcc4 喜歡了你的文章 《在Nodejs中貫徹單元測試》
• 你在《基于RESTful API 怎么設計用戶權限控制？》中收到一條 cnlinjie 的評論
• 你的文章《Session原理》已被加入專題 《ios開發》

分析句子結構，提醒的內容無非就是

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

「someone do something in someone’s something」

• someone = 提醒的觸發者，或者發送者，標記為senderdo
• something = 提醒的動作，評論、喜歡、關注都屬于一個動作，標記為action
• something = 提醒的動作作用對象，這就具體到是哪一篇文章，標記為target
• someone’s = 提醒的動作作用對象的所有者，標記為targetOwner

這就清楚了，sender和targetOwner就是應用的用戶，而target是具體到哪一篇文章，如果提醒的對象不僅僅局限于文章，還有其他的話，就需要增加一項targetType，來標記目標是文章還是其他的什么。而action，則是固定的，整個應用會觸發提醒的動作可能就只有那幾樣：評論、喜歡、關注…..（或者其他業務需要提醒的動作）

2.消息分發

消息按照規則匯總完成后，系統將其通過消息管道推送到用戶，以便用戶處理。

分發方式

主要是Push和Pull。

第一種是客戶端使用Pull（拉）的方式，隔一段時間就去服務器上獲取信息，看是否有更新的信息出現。

第二種就是服務器使用Push（推送）的方式，當服務器端有新信息了，則把最新的信息Push到客戶端上。

Pull方式更費客戶端的網絡流量，更主要的是費電量，還需要我們的程序不停地去監測服務端的變化。

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

以知乎為例

推的比較常見，需要針對某一個問題維護著一張關注者的列表，每當觸發這個問題推送的條件時（例如有人回答問題），就把這個通知發送給每個關注者。

拉的相對麻煩一點，就是推的反向，例如每個用戶都有一張關注問題的列表，每當用戶上線的時候，對每個問題進行輪詢，當問題的事件列表出現了比我原本時間戳大的信息就進行拉取。

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

通告和提醒，適合使用拉取的方式，消息產生之后，會存在消息表中，用戶在某一特定的時間根據自己關注問題的表進行消息的拉取，然后添加到自己的消息隊列中，

私信，適合使用推的方式，在發送者建立一條信息之后，同時指定接收者，把消息添加到接收者的消息隊列中。

目前大部分消息優先推送未處理消息合并后的總數，已提醒用戶已有新消息需要處理。用戶點擊數字后再去服務端請求具體的消息內容。此種方式綜合考慮了成本、壓力和體驗。當然，某些極端情況下需要進行優化處理：如未讀消息超過1000，用戶請求時先推送前50條或者放入cache中等。技術童鞋會有各種手段，這里不做詳述。

分發頻率(時間)

分發時間主要根據消息的優先級來做區隔：

分發管道

分發管道即消息通知的具體推送渠道，根據業務類型可以分為：App、短信等。

3.用戶處理

根據前文提到的分發方式，對于通知的處理在邏輯上可以分為兩層：通知狀態的處理和通知內容的處理。

狀態的處理狹義的理解即為是否已讀(已處理).

通常初始數字即為系統推送過來的未讀總量，用戶點擊數字進入相關功能列表查閱后讀取的動作完成，未讀數字相應減少。

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

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

某些產品會將點擊等同于已讀。即用戶只要點擊無論是否打開列表查看均認為已讀。

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

某些重要級別較高的消息已處理狀態可以定義為用戶進行相關操作后才為已處理，而非查閱。

如用戶進行評論、回復、點擊忽略或點擊刪除等動作時才認為已處理。

內容的處理狹義的理解即為用戶是否操作

根據不同消息的種類和業務的需要，操作可分為：

• 處理：用戶必須點擊功能鏈接進行處理。如：你的密碼過于簡單，點此進行修改;
• 回復：如回復私信，對評論進行回復;
• 確認：對消息做出確認的反饋，如某些系統提示可設置”我已知道，不再提示”的選項;
• 忽略：用戶進行忽略操作或不進行任何操作;
• 刪除：用戶刪除本消息。
• 消息處理后的狀態需要統一

消息需要標記是否已處理的狀態，且狀態在不同的終端是打通的。

如：用戶在客戶端對消息進行了查看，在web站點本消息應自動標記為已讀狀態。

4.消息回收

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

• 在部分產品中，還需要考慮功能的優先級。如解除好友關系或加入黑名單后自動將刪除雙方的私信記錄。
• 系統觸發的消息一般設置一定的回收刪除時間。如系統提醒、通知、公告等。過期后自動在產品里刪除。物理上可以設置是否備份。
• 過期但用戶未處理消息(用戶長時間未登錄但收到他人的回復)可以根據業務需求來處理。如未讀的私信/評論/回復永久保留等。重要未讀消息可嘗試二次推送或使用其他途徑(郵箱、APP、短信等)通知。
  

  四、iOS和安卓的消息提醒設計

  1.IOS版本的APP消息提醒設計

iOS對于消息通知的提示也有自己的一套設計規范，而且分為本地通知和推送通知。 推送通知或推送消息是服務器執行。

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

Badge Notification

指出現在應用程序圖標右上角的紅色圓形數字提醒，用于提醒一些無需即時處理的消息，比如程序更新數、未讀郵件數等。Badge Notification只有在Home Screen的對應屏上才能看到，因此不適合用于提醒一些重要性高或需要及時處理的通知。而且Badge Notification的形狀顏色大小等都是默認且無法改變的。

Alert Notification

非常直接地以對話窗口的形式出現在屏幕上，用于重要或需要及時處理的通知。不過Alert Notification常常粗暴地打斷正在進行中的任務，強迫用戶馬上做出選擇，且無法匯總查看所有通知，當有多條通知時，無法選擇性處理，只能按提供提供的順序一個個處理。

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

橫幅（Banner）

橫幅通知會顯示程序的小圖標（低分屏下顯示29×29的圖標，高分屏顯示58×58的圖標），程序的名字和通知的內容。（只要不是鎖屏狀態，都可以從屏幕頂部向下滑打開通知中心。 ）

提醒（Alert）

提醒通知不會自動消失，需要用戶與之交互才能關閉。設計師需要設計通知的具體內容，有時還要為action button（后面會談到）設計title。

APP設計師值得注意的是：一條提醒可能會包含一到兩個按鈕。對于有兩個按鈕的提醒，需要把關閉提醒的按鈕放在左邊，把action button放在右邊。 如果只有一個按鈕，這個按鈕應該是一個確定按鈕。

標記（Badge）

標記通知是顯示在程序圖標的右上角的紅色橢圓形標記，里面顯示的數字表示需要用戶處理的通知的數量。

這種方式都是很常見的。而且也很醒目。切記，標記圖標的設計尺寸。

聲音（Sound）

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

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

2.Android 版本的APP消息提醒設計

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

更加人性化，android也有一樣的消息提醒設計：

• Alert：強打斷型提醒，提醒內容與當前應用有聯系時可以接受；
• 標記：一種不緊急的提醒方式，增量很難記住，部分用戶有強迫清零的習慣；
• Toast：純告知，不需要處理；針對正在操作的反饋；
• 預覽：可輔助用戶判斷是否需要查看該信息詳情，但要注意結合“標記為已讀”機制；
• 通知欄：是一種被普遍接受的通知方式，優點是“集中處理”；

我們在設計APP消息提醒或通知的時候，還應該考慮我們所設計的APP針對的人群，從而選擇合適的消息推送方式或是消息提醒方案。

作者：Jason ? ?個人微信號：jason-pong