建设移动统一消息管理中心

转载本文需注明出处：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，数据治理，移动架构原创技术分享。长按二维码关注！