二、如何做好移动消息管理
针对上述统一消息中心建设的目标，在实施上个人觉得应当服务端、端并重，缺一不可。
•服务端：建立移动中台化的统一的消息管理服务中心
•前端：消息管理方式——分类聚合、主次有序的独立消息管理模块
统一消息管理——逻辑结构
移动中台化的统一消息管理中心应当对各业务系统提供统一的消息收集接口，并针对通知栏消息提供厂商推送通道接口；在对接客户端上，给客户端提供非通知栏消息的拉取接口。如下图：
这里在中台化的消息管理中心做推送的好处在于避免了在多个业务系统去集成推送的重复工作；另外对于业务系统来说，只需要关注于消息的生产而不用去关心何时将消息发到客户端也不必关心消息以哪种途径到达客户端。
消息管理中心——推送管理
在这里可能会有疑惑的在于为什么要标注强调“厂商推送”。目前手机阵营中苹果手机推送是自家的服务，稳定性、到达率都是有保障的的；反观早期，因为国内不能使用 服务，导致之前走第三方推送时到达率和稳定性上都相对较差，故而有了保活需求；而随着 的升级，在对应用保活上的限制越来越严格，如下图官方版本的描述：
好在目前主流手机厂商都有了针对自家手机的系统级推送通道，在到达率、稳定性上也有保证。同时系统级通道也降低了因为多个维护推送链接、保活而对系统资源的占用。
前端消息管理的呈现
一手抓了统一消息中心的服务管理端，另一手就要放在客户端上了。前面说到消息管理最好做成“分类聚合、主次有序”的独立消息管理模块。这里以常见的两种方式、个应用给大家对比进行说明。第一种管理呈现的设计是：分类而不聚合，一视同仁而无主次的消息管理界面，这种类型因为消息过于密集很难让我直观的抓住消息重点。
反观支付宝的消息中心的呈现设计：主界面直达，内容直观同时还提供了多个操作而非单纯的点击查看详情。
前端消息获取：推、拉并举
刚才说的是消息的呈现设计，那在端消息的获取方式上，除了前面说到的推送方式外，还有拉取方式，我们的设计其实应当推、拉并举；仍以支付宝消息为例子：正常情况下蚂蚁森林、庄园等消息并不是通知栏消息，这类消息则应当以拉取方式获得。因为拉取消息涉及保活，在上这里推荐使用单次定时任务+广播循环的方式（在某项目中测试过延迟时间约在）而不要去依赖保活。
•推送类消息用于激活、唤醒；吸引用户切换至前台
•不要单纯依赖推送类型的消息来实现业务逻辑以及推广、宣传
•拉取消息建议采用单次定时任务而非保活
