转载本文需注明出处：微信公众号EAWorld，违者必究。
引言： 在不断强调缩减APP数量的今天，企业的APP内容越来越“内聚化”—— 一个APP已经不再是单个服务或者服务于单个业务线，而是成为多条业务线内容的集装箱。那在这单个APP内容不断扩充的背景下，如何做好消息的集中管理似乎也成为了一个不可忽视问题，本文就让我们一起来探讨这个问题。 目录： 一、移动端统一消息管理的必要性 二、如何做好移动端消息管理 三、如何通过消息更好抓住移动用户
常见消息分类
在移动开发中说到消息，可能大家第一反应就是通知栏消息和及时通讯的对话消息；在个人看来消息的内容涵盖面其实挺广：除了通知栏消息、对话消息外，还有像营销推广类的消息，新闻资讯相关的点赞、评论都是消息的一个体现。 特殊类“消息”—— 个性化推荐 甚至常见的个性化推荐我觉得也可以理解是消息的一种表达——或基于个人画像的消息定投或基于节假日活动的推广宣传，稍有区别的是其以或文字或图文的形式呈现，没有了通知栏的翻转，不存历史、“阅后即焚”。 消息管理方式——分而治之 那消息种类的多样加上单个APP的模块越来越多（超级APP），如果仍然采用“分而治之”的消息处理、呈现方式，在APP前端对于用户来说有如下问题： 消息查阅的平均路径深 没有统一的编辑、处理界面，容易让人觉得APP只是简单模块的堆积而没有整体性 一些模块的重要信息容易被忽略 “分而治之”在后端管理上：每个业务系统除了要生产消息、管理不同类型消息的外，还需要承接对客户端推、拉消息请求的处理。这里举例一种情况：如果推送消息接口发生变更、SDK需要更新，则各业务系统都需要做对应的调整，如下图： 所以分而治之在后端上同样存在问题： 安全性：每个应用系统都直接对接客户端APP 复杂度：每个系统都要提供针对客户端的消息管理、输出接口 SDK冗余：如每个业务系统都要集成多个厂商推送SDK（华为、小米等） APP前端目标——分类聚合、主次有序的独立消息管理模块 在这些问题背景下，我们建立移动统一的消息管理中心：在APP前端建议形成“分类聚合、主次有序”的独立消息管理模块进行消息的获取、呈现；后台管理端则应配合建立移动中台化的统一消息收集、输出、管理中心，类似于如下： 针对上述统一消息中心建设的目标，在实施上个人觉得应当服务端、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保活 最后一部分的内容也是因为前些时间处理推送问题时注意到的，做了整理，个人觉得对于配合消息抓住用户会有些许帮助，这里做一下个人理解的分享： 可用方式： 1、分渠道定向推送：精细划分消息类别，让用户可选择性打开通知而非全部关闭 2、多端用户结合：微信端、短信渠道（10086长这么做） 3、优秀的文案设计 消息或者推广内容吸引用户的除了贴合用户需求、好的文案设计外，个人还应当做好精细划分，分类别（标签）定向推送，再结合互联网APP（像微信）做一个多端用户的画像绑定来进行用户运营。 不知道大家是否跟我一样，使用Android手机的时候都是一棍子打死的关闭APP推送通知（Android通知被烂用的太严重），这样有时又会因为推送错过一些重要消息，毕竟通知栏消息是APP切换到后台之后几乎唯一能吸引用户关注并进行交互的途径了；所以这里的建议大家可以参考如下图： 将APP消息进行多类别划分，这样让用户可以有选择性的订阅通知，可以尽量避免因为完全关闭推送通知而导致对APP失去关注。 最后就是结合微信公众号、小程序与自家APP进行用户的绑定，多通道的下发消息，提升用户对APP的关注度。 精选提问： 问1：请问对现在很少提及Android保活怎么理解？ 答：对于Android来说，因为应用切到后台长时间是会被系统kill掉的，而当应用切换到后台之后非主动情况下几乎只有通过消息通知一种途径能吸引用户的关注并与APP交互（点击通知栏切换到前台），而早前手机厂商没有统一的系统级推送通道加上国内无法使用Firebase，故而有了保活的要求，尤其是像微信这样及时通讯类的APP。但是这带来的问题就是保活对系统资源的高消耗，所以sdk上不断加强了对后台任务、广播的执行限制。而现在手机厂商几乎都有了自己的系统推送通道足以保证消息的到达和实时性，因此在我看来现在除非对消息的时效性要求特别高，否则以单次定时任务配合厂商系统级别推送足以达到消息时效性的要求；所以保活谈的相对以前较少了。 问2：现在Android保活还有哪些可用的措施？ 答：按分类有灰色保活、白色保活；在8.0及之后版本SDK中除白色保活（前台Service）外都已经不是行之有效的途径。回到问题，在使用系统级通道的同时不需要保证UI存活也难以保证，可以考虑通过新的定时任务接口设置允许“瞌睡模式”+receiver循环+异步线程执行非UI任务，如获取消息；定时任务不建议repeat模式，因为在系统闲或者瞌睡模式下，执行效率远不如预期；使用单次（exactt）循环调用receiver会更好（Android说明中有提到保证定时任务单次调用时间的精确性，测试过约3s误差）。
关于作者：黄家伟，普元移动团队高级软件工程师，毕业于上海工程技术大学，在移动安卓开发、微信开发、IDE开发领域有比较深的见解。持续参与移动平台产品版本维护、升级与研发。
关于EAWorld：微服务，DevOps，数据治理，移动架构原创技术分享。
