定義
通知系統，顧名思義即通知信息的傳達處理系統。目的是為了讓用戶獲得需要得到的訊息及提醒並進行處理。 這裡的“需要得到”有兩層意思
1、用戶彼此互動觸發的信息流（留言、評論或者回復、私信等）
2、網站希望用戶了解關注的信息（系統公告等）
通知系統設計的原則可簡單的歸納為：
1、訊息傳播效率最高（獲取、處理、信息傳達、用戶反饋等效率）
2、避免產生騷擾（噪音、頻繁提示）
分類
不用的平台和產品本身由於對業務的需求不一樣，種類也是有區別的。 大致可分為以下幾種：
| 編號 | 業務類型 | 觸發對象 | 備註 |
| 1 | 評論 | 用戶對用戶 | 互動類的信息流提示 |
| 2 | 回復 | ||
| 3 | 留言 | ||
| 4 | 私信 | ||
| 5 | 請求 | 如：添加好友（雙向確認） | |
| 6 | 提醒 | 系統對用戶 | 如：新增用戶或@ |
| 7 | 套用通知 | 如：開放平台的第三方套用，本質上是系統通知 | |
| 8 | 系統通知 | 如：系統公告、升級提示等 |
邏輯實現機制
通知的邏輯精簡後如下：
通知系統現對這幾個環節分開說明：
通知合併
通知在推送之前需要進行匯總合併，目的在於提高訊息傳播處理效率；減少騷擾，降低噪音；平衡伺服器壓力。
1）合併周期：
1.固定時間內的訊息全部匯總（24小時內/30天等）；
2.無固定時間（只要未處理/未讀即匯總）
當然一般都組合著用：合併24小時內未處理訊息
2）分類合併
1.同種類進行合併（如n條留言合併為1條）
2.同一發起人合併（如張三給你發來的n條私信）
3.同一時間周期合併（如24小時共收到n條評論）
通知分發
通知按照規則匯總完成後，系統將其通過通知管道推送到用戶，以便用戶處理。
1）分發方式
分發方式與Feed系統類似，多採用Push方式，即在指定時間內主動推送給用戶。部分特定類型需要用戶請求（Pull）拉取未讀訊息。 目前大部分通知優先推送未處理通知合併後的總數，已提醒用戶已有新訊息需要處理。用戶點擊數字後再去服務端請求具體的訊息內容。此種方式綜合考慮了成本、壓力和體驗。當然，某些極端情況下需要進行最佳化處理：如未讀訊息超過1000，用戶請求時先推送前50條或者放入cache中等。技術童鞋會有各種手段，這裡不做詳述。
2）分發頻率（時間）
分發時間主要根據訊息的優先權來做區隔：
| 編號 | 優先權 | 分發時間 | 備註 |
| 1 | 高 | 實時 | 需要用戶立即知曉或處理 |
| 2 | 中 | 小時/天/周 | 不需要用戶立即處理，匯總後發出 |
| 3 | 低 | 固定周期 | 提醒類或符合條件時觸發 |
| 備註：優先權會根據本身業務需求來確定，優先權的確定需要考慮防打擾。 | |||
3）分發管道
分發管道即訊息通知的具體推送渠道，根據業務類型可以分為：Web、App、簡訊、郵件等
用戶處理
根據前文提到的分發方式，對於通知的處理在邏輯上可以分為兩層：通知狀態的處理和通知內容的處理。
1）狀態的處理狹義的理解即為是否已讀（已處理）。
通常初始數字即為系統推送過來的未讀總量，用戶點擊數字進入相關功能列表查閱後，讀取的動作完成，未讀數字相應減少。
有幾種情況需要變通處理：
1.若用戶未讀信息較多（m=100），但第一頁列表只能顯示（n=10）條的話，那未讀數字即為m-n=90；
2.某些產品會將點擊等同於已讀。即用戶只要點擊無論是否打開列表查看均認為已讀。 這樣的處理一般用於重要級別較低的訊息。點擊即已讀可有效降低騷擾。
3.某些重要級別較高的訊息已處理狀態可以定義為用戶進行相關操作後才為已處理，而非查閱。 如用戶進行評論、回復、點擊忽略或點擊刪除等動作時才認為已處理。
2）內容的處理狹義的理解即為用戶是否操作。
根據不同訊息的種類和業務的需要，操作可分為：
1.處理：用戶必須點擊功能連結進行處理。如：你的密碼過於簡單，點此進行修改；
2.回覆：如回復私信，對評論進行回復；
3.確認：對訊息做出確認的反饋，如某些系統提示可設定”我已知道，不再提示”的選項；
4.忽略：用戶進行忽略操作或不進行任何操作；
5.刪除：用戶刪除本訊息。
3）訊息處理後的狀態需要統一。
訊息需要標記是否已處理的狀態，且狀態在不同的終端是打通的。 如：用戶在客戶端對訊息進行了查看，在web站點本訊息應自動標記為已讀狀態。
通知回收
回收主要針對用戶已處理訊息的操作。
1.用戶之間觸發的訊息一般需要留檔保存。 如評論/回復/留言/私信等。產品可提供選項詢問用戶是否超過一定周期自動清理。
2.在部分產品中，還需要考慮功能的優先權。 如解除好友關係或加入黑名單後自動將刪除雙方的私信記錄。
3.系統觸發的訊息一般設定一定的回收刪除時間。 如系統提醒、通知、公告等。過期後自動在產品里刪除。物理上可以設定是否備份。
4.過期但用戶未處理訊息（用戶長時間未登錄但收到他人的回覆）可以根據業務需求來處理。 如未讀的私信/評論/回復永久保留等。重要未讀訊息可嘗試二次推送或使用其他途徑（信箱、APP、簡訊等）通知。
通知處理互動
註：具體的互動需要考慮本身業務特點和目標需求。特定業務可能需要強調，某些業務又需要考慮騷擾，故拋開具體情境本身談互動是無恥的。 這裡只針對一般的社區網站，描述一下個人所喜歡的互動方式。
1)、新訊息到達時提醒互動
當新訊息到達時，可以使用以下提醒方式
1.標題閃動
通知系統
通知系統2.聲音提醒 新訊息到達後自動觸發聲音
3.氣泡+數字
通知系統4.新訊息浮層
通知系統5.彈窗提示
通知系統2)、通知處理
目前訊息多採用當前觸發、即時處理類似“所見即所得”的互動方式。 
採用此方式的需要考慮：
1.訊息通知位於全局導航，訪問任何頻道時都可保證及時收到新訊息；
2.訊息在浮層中處理完畢後，用戶可繼續進行之前的操作，不至於造成打擾；
3.因導航面積有限，需對訊息種類進行統一整理和規劃；（Facebook的分類為好友請求、私信、通知。）
4.提供歷史記錄（更多、全部訊息）的入口（二級頁面）
5.標記已讀未讀狀態，處理好訊息提醒數字的關係 
防騷擾
因訊息本身業務性質，過多無用通知勢必會造成噪音，打擾到用戶。因此合理設定訊息的通知頻率和渠道，以防早上體驗和效率上的損失。
1)、提供通知頻率和渠道的管理功能
通知系統如常見的郵件退訂管理，訊息通知類型管理。 
通知系統Facebook通知設定

2)、增加禁止功能
訊息禁止功能在業務上應該屬於第一條中通知類型管理，當業務模組較多且之前關聯分散時，或者開放平台功能接入的第三方套用通知時，可使用禁止功能。
通知系統
通知系統facebook套用訊息管理
3)、結合許可權體系
①、功能隱私設定
使用隱私設定界定具體的接收許可權、範圍等
微博私信設定
通知系統②、結合黑名單功能
使用黑名單可禁止指定用戶或關鍵字的具體訊息通知。
用戶拉回
當用戶長時間不登入或對訊息不處理時，可使用其他渠道推送通知，已達到拉回的目的。 這個要與網站整體的拉回策略相結合。
通知系統iOS通知系統
iOS中提供了2種推送通知
•本地推送通知（Local Notification） [2]
•遠程推送通知（Remote Notification）
推送通知的作用
•可以讓不在前台運行的app，告知用戶app內部發生了什麼事情
•推送通知的呈現效果總結
•用戶接收的推送通知，都會展示在“通知中心”
•從螢幕頂部往下滑，就能調出“通知中心”
•顯示橫幅還是UIAlertView，取決於用戶的設定
不同的呈現效果
•在螢幕頂部顯示一塊橫幅（用來顯示具體內容）
•在螢幕中間彈出一個UIAlertView（用來顯示具體內容）
•在鎖屏界面顯示一塊橫幅（鎖屏狀態下，顯示具體內容）
•更新app圖示的數字（說明新內容的數量）
•播放音效（提醒作用）
使用的幾個細節
•發出推送通知時，如果當前程式正運行在前台，那么推送通知就不會被呈現出來
•點擊推送通知後，默認會自動打開發出推送通知的app
•不管app打開還是關閉，推送通知都能如期發出
詳細設計
設計
企業內部通常都有通知需要上傳下達，有時是臨時通知，比如通知“下午2點開會”，如果是每個部門電話通知比較煩瑣，而僅是通過電子郵件傳送，則往往有部分人沒有及時地查看而導致錯過會議;有時是某個精神需要傳達，是一些文本文檔;另外一些時候則可能是部門之間交流的內部檔案。為了防止員工工作時間閒聊和內部資料外泄，企業外網不開放，公共的即時聊天工具不適合這種場合的使用。而有些情況下，比如非工作時間，企業外網是開放的、允許員工使用的，員工在眾多的聊天工具中選擇幾種是很常見的情況。
桌面通知系統是以企業內部區域網路為基礎進行設計的。它的目標是在企業內部建立即時通訊平台，方便通知的上傳下達，同時對幾種常用的公共聊天軟體進行集成，使它們有統一的外觀、配置，可以減少人們在不同聊天工具之間的切換，並限制公共聊天軟體的使用時間段。
桌面通知系統結構主要功能模組
UI模組
桌面通知系統客戶端，隨機器開機而自動起動;它的Ul(用戶界面)仿照QQ聊天程式，不使用時，放置於系統托盤位置;若有企業內部訊息時，訊息視窗自動彈出，並將其設定為最前端視窗，強迫用戶閱讀並確認後才能夠關閉，防止訊息沒有被及時閱讀。
對於伺服器端，界面很簡單，主要顯示出客戶端傳送訊息內容，以及檔案傳送的時間、位置等信息。
在Eclipse RCP中，所有的一切都是通過擴展點機制實現的，開發RCP的主要過程也就是向套用添加視圖、編輯器、透視圖、選單、工具列、上下文選單等等的擴展的過程。其中注意遵循模組化原則，按照功能、職責、以及模型和UI分離的原則將系統劃分成不同的模組，同時要充分利用Eclipse提供的很多可重用的外掛程式、擴展點、內置的Action、視圖、編輯器、首選項等。
訊息管理模組
訊息分為兩類，一是指企業內部傳送的訊息，二是指集成聊天軟體的訊息。
企業內部傳送的訊息，由系統本身進行管理。客戶端用戶名是部門名，由系統維護部門規定，整個部門的用戶名均相同，防止個人利用桌面通知系統聊天。傳送訊息給某個部門時，該部門所有線上客戶端均接收訊息。利用Java提供的計時器類，桌面通知系統客戶端訊息視窗的新內容，每隔10分鐘自動存儲，減少意外斷電的損失。
由於公用即時通訊工具通訊協定各異，軟體升級更新周期短，桌面通知系統對於公用即時通訊工具，只是採用了簡單的調用方式集成，並未對其內容進行限制和管理，這樣可以簡化桌面通知系統的實現過程。因此，桌面通知系統中集成的即時通訊工具訊息傳送，使用聊天軟體原有的管理方式，系統並不對其干預，只是對其使用時段進行限制和管理。
檔案管理模組
為了減少伺服器的負擔，加快傳輸速度，與訊息傳送不同，客戶端的檔案傳送採用點對點傳輸。源客戶端從伺服器獲取目的客戶端的IP位址，然後啟動新檔案傳送執行緒傳送檔案。由於採用了執行緒方式，檔案傳送操作不影響客戶端針對桌面通知系統的其它操作。
時間管理模組
時間管理模組，主要針對集成的聊天軟體上線時間進行管理。在系統維護部門規定工作時間內，除桌面通知系統外其它的即時通訊軟體均為灰色，即:不可用狀態。
數據管理模組
本系統在伺服器端建立了資料庫服務。伺服器端資料庫包括部門信息、管理員許可權信息、設定時間段信息、日誌管理等方面的內容。由於MySQL5.0免費版亦具有良好穩定的性能，並且安裝簡單、系統開銷少，桌面通知系統利用它完成數據信息管理工作。
安全管理模組
由於桌面通知系統主要針對企業區域網路使用，所以其安全性相對於公用即時通訊工具具有天然的優勢。該系統主要採用客戶端許可權等級制來實現安全管理，即為不同的客戶端設定不同的許可權，限制客戶端訪問訊息和檔案的許可權，以達到保障內部資料安全的目的。
