建設移動統一消息管理中心

轉載本文需註明出處：EAWorld，違者必究。

引言：

在不斷強調縮減APP數量的今天，企業的APP內容愈來愈「內聚化」—— 一個APP已經再也不是單個服務或者服務於單個業務線，而是成爲多條業務線內容的集裝箱。那在這單個APP內容不斷擴充的背景下，如何作好消息的集中管理彷佛也成爲了一個不可忽視問題，本文就讓咱們一塊兒來探討這個問題。

目錄：

1、移動端統一消息管理的必要性 
2、如何作好移動端消息管理 
3、如何經過消息更好抓住移動用戶

1、移動端統一消息管理的必要性 
 

• 常見消息分類

在移動開發中說到消息，可能你們第一反應就是通知欄消息和及時通信的對話消息；在我的看來消息的內容涵蓋面其實挺廣：除了通知欄消息、對話消息外，還有像營銷推廣類的消息，新聞資訊相關的點贊、評論都是消息的一個體現。
 

• 特殊類「消息」—— 個性化推薦

甚至常見的個性化推薦我以爲也能夠理解是消息的一種表達——或基於我的畫像的消息定投或基於節假日活動的推廣宣傳，稍有區別的是其以或文字或圖文的形式呈現，沒有了通知欄的翻轉，不存歷史、「閱後即焚」。
 

• 消息管理方式——分而治之

那消息種類的多樣加上單個APP的模塊愈來愈多（超級APP），若是仍然採用「分而治之」的消息處理、呈現方式，在APP前端對於用戶來講有以下問題：

消息查閱的平均路徑深
沒有統一的編輯、處理界面，容易讓人以爲APP只是簡單模塊的堆積而沒有總體性
一些模塊的重要信息容易被忽略

「分而治之」在後端管理上：每一個業務系統除了要生產消息、管理不一樣類型消息的外，還須要承接對客戶端推、拉消息請求的處理。這裏舉例一種狀況：若是推送消息接口發生變動、SDK須要更新，則各業務系統都須要作對應的調整，以下圖：



因此分而治之在後端上一樣存在問題：

安全性：每一個應用系統都直接對接客戶端APP
複雜度：每一個系統都要提供針對客戶端的消息管理、輸出接口
SDK冗餘：如每一個業務系統都要集成多個廠商推送SDK（華爲、小米等）
 

• APP前端目標——分類聚合、主次有序的獨立消息管理模塊

在這些問題背景下，咱們創建移動統一的消息管理中心：在APP前端建議造成「分類聚合、主次有序」的獨立消息管理模塊進行消息的獲取、呈現；後臺管理端則應配合創建移動中臺化的統一消息收集、輸出、管理中心，相似於以下：




2、如何作好移動消息管理

針對上述統一消息中心建設的目標，在實施上我的以爲應當服務端、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保活


3、如何經過消息更好抓住用戶

最後一部分的內容也是由於前些時間處理推送問題時注意到的，作了整理，我的以爲對於配合消息抓住用戶會有些許幫助，這裏作一下我的理解的分享：

可用方式：

一、分渠道定向推送：精細劃分消息類別，讓用戶可選擇性打開通知而非所有關閉
二、多端用戶結合：微信端、短信渠道（10086長這麼作）
三、優秀的文案設計

消息或者推廣內容吸引用戶的除了貼合用戶需求、好的文案設計外，我的還應當作好精細劃分，分類別（標籤）定向推送，再結合互聯網APP（像微信）作一個多端用戶的畫像綁定來進行用戶運營。

不知道你們是否跟我同樣，使用Android手機的時候都是一棍子打死的關閉APP推送通知（Android通知被爛用的太嚴重），這樣有時又會由於推送錯過一些重要消息，畢竟通知欄消息是APP切換到後臺以後幾乎惟一能吸引用戶關注並進行交互的途徑了；因此這裏的建議你們能夠參考以下圖：



將APP消息進行多類別劃分，這樣讓用戶能夠有選擇性的訂閱通知，能夠儘可能避免由於徹底關閉推送通知而致使對APP失去關注。

最後就是結合微信公衆號、小程序與自家APP進行用戶的綁定，多通道的下發消息，提高用戶對APP的關注度。


關於做者：黃家偉，普元移動團隊高級軟件工程師，畢業於上海工程技術大學，在移動安卓開發、微信開發、IDE開發領域有比較深的看法。持續參與移動平臺產品版本維護、升級與研發。


關於EAWorld：微服務，DevOps，數據治理，移動架構原創技術分享。長按二維碼關注！