二、如何做好移動消息管理

針對上述統一消息中心建設的目標，在實施上個人覺得應當服務端、APP端并重，缺一不可。

?服務端：建立移動中臺化的統一的消息管理服務中心

?APP前端：消息管理方式——分類聚合、主次有序的獨立消息管理模塊

統一消息管理——邏輯結構

移動中臺化的統一消息管理中心應當對各業務系統提供統一的消息收集接口，并針對通知欄消息提供OEM廠商推送通道接口；在對接客戶端APP上，給客戶端提供非通知欄消息的拉取接口。如下圖：

這里在中臺化的消息管理中心做推送的好處在于避免了在多個業務系統去集成推送SDK的重復工作；另外對于業務系統來說，只需要關注于消息的生產而不用去關心何時將消息發到客戶端也不必關心消息以哪種途徑到達客戶端。

消息管理中心——推送管理

在這里可能會有疑惑的在于為什么要標注強調“OEM廠商推送”。目前手機陣營中蘋果手機推送是自家的APNS服務，穩定性、到達率都是有保障的的；反觀Android早期，因為國內不能使用Firebase Cloud Messaging服務，導致Android之前走第三方推送時到達率和穩定性上都相對較差，故而有了保活需求；而隨著Android SDK的升級，在對應用保活上的限制越來越嚴格，如下圖Google官方SDK版本的描述：

好在目前主流手機廠商都有了針對自家手機的系統級推送通道，在到達率、穩定性上也有保證。同時系統級通道也降低了因為多個APP維護推送鏈接、保活而對系統資源的占用。

APP前端消息管理的呈現

一手抓了統一消息中心的服務管理端，另一手就要放在APP客戶端上了。前面說到APP消息管理最好做成“分類聚合、主次有序”的獨立消息管理模塊。這里以常見的兩種方式、2個應用給大家對比進行說明。第一種管理呈現的設計是：分類而不聚合，一視同仁而無主次的消息管理界面，這種類型因為消息過于密集很難讓我直觀的抓住消息重點。

反觀支付寶的消息中心的呈現設計：主界面直達，內容直觀同時還提供了多個操作而非單純的點擊查看詳情。

APP前端消息獲取：推、拉并舉

剛才說的是消息的呈現設計，那在APP端消息的獲取方式上，除了前面說到的推送方式外，還有拉取方式，我們的設計其實應當推、拉并舉；仍以支付寶消息為例子：正常情況下螞蟻森林、莊園等消息并不是通知欄消息，這類消息則應當以拉取方式獲得。因為拉取消息涉及保活，在Android上這里推薦使用單次定時任務+廣播循環的方式（在某項目中測試過延遲時間約在3s）而不要去依賴Service保活。

?推送類消息用于激活、喚醒APP；吸引用戶切換至前臺

?不要單純依賴推送類型的消息來實現業務邏輯以及推廣、宣傳

?拉取消息建議采用單次定時任務而非Service保活