客户端|如何从0-1重构建消息系统：客户端( 三 ) 龙珠|wi-fi|美团|王兴|大众点评

4. 消息推送的渠道（where）首先我们要先梳理，消息的推送渠道一共有哪些及这些渠道的特点：

电话；传统的电销模式下，电话提醒作为获客的主要手段，优势在于可以强提醒用户，并和用户做深度沟通，但是由于过度打扰用户，触发方式及渠道比较特殊，成本较高，所以这种提示方式需要甄别业务实施，不建议使用。
短信；作为及时触达用户的一种方案，用于把重要且信息量较少的消息内容及时传达给用户的有效方法，如验证码、基金申购通知等。
邮件；互联网2.0时代的重要的沟通方式，优势可以把信息量较大的消息准确地推送给用户。但是随着移动互联网的兴起，即时通讯APP大量的出现，邮箱作为主要的pc端工作交流的渠道，所以劣势就是无法及时提醒用户；如常见的消息业务员激活邮箱、验证码、银行账单等依旧在使用。
push推送；主要是配合应用的出现，iOS和安卓系统的推送方式不同，iOS可以运用自身系统的原生推送渠道，推送规则一致；安卓则因手机厂商的规则不一致，则应用无法单独满足，一般会使用第三方服务；需要用户及时处理的消息则使用push推送。
弹窗；主要作为用户前端操作反馈的及时通知，如订阅成功、直播预约成功等。
站内信；作为主要应用消息的推送方式，可以把消息有效且准确地推送给目标用户，并在消息中心储存；应用类所有业务皆可使用此渠道。

然后我们再去划分哪些业务的消息使用哪种渠道展示给用户；如直播业务中会涉及到的消息渠道：

直播创建后，运营在后台手动推送给目标用户，可以使用PUSH及站内信的方式展示给目标用户直播信息；
直播预约前，用户在直播模块的前端页面点击「预约直播」按钮，系统触发tost弹窗/站内消息提示用户预约成功；
直播开播前，系统在设置的时间节点自动发送给预约用户push消息，提示用户直播开始。

5. 消息推送的内容（how）消息的内容从功能设置上分为：只读与可操作。

只读，即当前消息用户在浏览后不需要做更多的操作，主要以了解为主；如申购基金成功提醒；
可操作反馈，即当前消息需要用户浏览，且在浏览后做相应的后续操作；如补仓提醒。

消息分类，需要和业务深度结合去进行消息分类的划分，目的是可以让用户用最短路径浏览到同类的信息，大概率可分为系统消息和业务相关消息，如果有社区，还会有互动消息之内的聚合。
四、客户端消息构建方案通过梳理，此次主要需要对APP的应用级的消息进行重构，我们先明确优化渠道：push推送、站内信。
并通过业务侧的调研，消息主要的问题是新业务不断叠加，因为没有进行系统的规划，造成了现有业务消息冗杂、消息分类不明确，所以我们需要通过对业务消息进行分类合并，重新梳理消息的类型的划分，并从前端展现形式上对消息类型作出明确的划分。
1. Push推送前端展示现方案Push的前端展示样式主要有：标题+摘要、标题两种展现形式；在不同的业务条件下，这两种展示都能够使用，所以要求我们设计后台的时候需要注意字段的扩展。

文章插图
我们要注意的是由于Android和iOS机制不同，此处区分两个平台讲解。
1）Android
国内Android系统均为定制过的ROM，需将APP与各大手机厂商均有合作添加产品白名单，或将APP加入手机自带的安全工具白名单，这样才能保证推送不会丢失，因为和各大手机厂商对接的成本太高，一般情况下我们会接入第三方服务商（如：极光），各厂商字符规则如下：