记一次app端消息推送方案确认
项目背景：现项目主要是做关于机器人的调度系统，涉及到web端、移动端、小程序及服务端和实体机器人端；
迭代背景：app端消息推送方案确认
记录方向：app端消息推送
记录时间：20210119
=========================================================
项目app端正在整备梳理消息推送的机制，正在确定推送方案，记录一下消息推送方案确定过程；
最初调查列出的方案只有极光、友盟、腾讯、阿里第三厂商的的相关方案，根据各个方案的客户数量、知名度、收费的价格、免费推送的条数限制、厂商通道、准确推送率等多维度去考量，最后结合自身业务的相关性
来筛选方案。
1、各个第三方的厂商的各个维度的对比，这块工作没有用表格进行罗列对比，只是口头上描述了一下；
2、确定项目组需要推送的业务模块，及推送的频率等；
3、预估现有项目的每月推送的业务数量，及未来可预期的业务增长量，结合第三方厂商的业务价格；
其实关于消息推送这块的方案确认还没有实际进行，只是先做了一下相关的调查。因为后期项目确定了推送方案后这块逻辑是需要进行测试的，以前也没有对推送的业务测试经验，所以先提前准备一下。
=============================================================
在搜索过程中发现了一篇关于消息推送介绍比较完善的文章，就借用过来了：转载自：https://zhuanlan.zhihu.com/p/77707904===================
=============以下是转载文章的主体部分===========================
摘要」本文主要讲解关于APP PUSH的流程、机制及相关经验：
- 方便大家可以针对APP迅速制定PUSH消息推送方案，实现0到1的推送功能搭建；
- 可以了解PUSH流程，对各个环节针对性地提高触达率。
一、APP PUSH定义与价值
APP PUSH定义为在手机终端锁屏状态下通知栏展示或在操作前台顶端弹出的消息通知，点击后可唤起对应的APP，并在APP内跳转到指定页面。
push消息是通知用户，引导用户参与活动、购买产品的重要手段，而且PUSH消息也可以引导用户查看消息，唤起APP提高日活，是一块重要的流量。
二、APP推送分类
从应用的功能来划分，应用主要分为三类：
- 第一类是IM类APP，如微信、QQ等；
- 第二类是新闻资讯类，如华尔街见闻等；
- 其余暂归为工具类，比如支付宝、美团等。
每种类型APP对PUSH的需求也不同，IM类APP追求实时、稳定的触达，此类APP一般通过自己的长连接进行消息推送，保证用户在收到消息的时候能够实时接收消息。另外，一些安卓厂商也会给予头部APP的进程一定保护，对相关的进程纳入白名单，在清理进程的时候予以忽略。新闻资讯类的APP与工具类APP的PUSH推送机制基本一致，仅在频率控制上有差异，新闻资讯类由于新闻资讯较多，需要将突发新闻及时推送给用户。由于目前工具类的APP占大多数，本文将主要讲解工具类APP的常见推送机制。
三、PUSH流程
PUSH消息在消息系统创建好后进入发送阶段，服务端需要根据用户终端信息进行路由，如果是IOS系统，那么会调用苹果自身的推送通知服务（APNs）,如果用户的手机是安卓系统，那么根据不同的厂商去调用不同的厂商SDK。对于不同的系统版本，支持的消息展示形式也不同。比如IOS10之后，当APP在前台时，是否通知栏展示；此样式可以根据产品需求来选择，有服务端传输相应通知方式的值即可。如果用的手机非五大厂商内的手机，可以通过自己搭建的长连接或者使用第三方服务进行推送。如果不是自己直接对接厂商通道，那么内部的服务端可能无需做过多复杂繁琐的开发工作，通过接入第三方消息推送平台来实现消息的推送，比如信鸽、个推等。多数的通道会将消息是否成功推送到客户端SDK的回执数据反馈给发送方，需要提供回调地址。
四、底层通道说明
1、推送方式
通道类型一般分为三类：厂商通道、第三方推送服务平台、长连接。
- 厂商通道是手机终端厂商推出的推送服务，通过接入厂商SDK，内部服务端可以将消息推送到手机系统的服务端，再下发至客户端内部的厂商SDK，由操作系统进行相应展示，点击后唤起相应APP，这样可以避免APP进程被杀死后消息无法触达用户，因此触达率较高。
- 第三方推送平台是推送服务公司搭建相关的消息服务。并且各个APP使用了同一个平台的推送服务时，客户端都是集成同一个第三方推送平台的SDK，因此形成了一个推送联盟，当联盟中的其中一个APP的消息进程没有被杀死的时候，其他的APP也可以利用进行通知用户，形成了相互唤起，提高触达率。经过一些场景的测试，相互唤起的成功率并不是很高，需谨慎结合自身场景评估。为了提高触达率，第三方推送平台也会集成各大厂商的SDK进行推送。
- 长连接就是建立手机与服务端的一条链路进行消息数据推送，通过长连接也可以进行APP状态监控，但完全由长连接推送且保证触达的稳定，需要投入的研发资源较多，且需尽量避免自己的长连接进程不要被操作系统杀死。
2、优劣势对比
APP push功能的搭建需要依据产品自身的情况和公司可投入的资源成本为主，在不同的阶段选择不同的方式。
五、下发推送
1、推送账号
推送时客户端的PUSH SDK均会根据用户的设备号生成一个对应关系的TOKEN。在SDK内部，如果使用的是第三方推送服务，则去第三方的SDK注册；如果是厂商，则去商城SDK注册；如果使用自己长连接，则去自己的SDK进行注册，作为后续推送的标识用户的唯一ID。2、消息路由消息路由见上述推送流程的讲解，此处主要讲解根据不同的业务场景，可能会定向推送给不同版本APP的用户。因此服务端在通道能力路由的时候，不仅需要能够区分通道，还要进一步能够针对用户的手机终端进行更加精细化的差异推送。此外，消息通道并不一定是100%稳定，如果下游通道出现问题，服务端需能够将由于通道问题导致的消息路由到备用通道去发送，以保证业务的稳定触达。
3、全量推送
一般来说，对于公司内部运营或公司的相关数据均是以产品的customer id为准，用户数据系统对接消息系统时也多为customer id，因此需建立customer id与推送TOKEN的关系，便于运营针对用户进行推送。但对于一些场景会需要针对未登录的用户也进行推送，即全量推送；比如突发重大新闻资讯、大促等活动，所以运营系统需要提供全量推送功能，针对所有TOKEN进行推送。
六、数据上报
上报数据包括触达点击关闭退出注册等数据：
- 对于所有方式的触达消息，都离不开触达与点击，触达的数据通过厂商的需要回调上报，点击数据可以由SDK上报服务端。对于push的关闭，也需要进行考量，评估push是否过度发送，打扰到了用户。
- 关闭数据有两部分，一部分为app内部的关闭，sdk直接上报给服务端即可；另一部分为用户在手机操作系统上关闭了对应app的push，需要APP在前台时，sdk调用手机终端相关方法获取该用户是否关闭了系统通知，然后上报至服务端。
- 注册数据即用户首次启动APP时，去相关sdk注册token。
一般来说，用户退出账号时，sdk需要上报服务端，解除token与customer id的绑定关系。
七、PUSH特点
1、强提醒不留痕
push由于是app自己的通知渠道，是运营的一个重要工具。如果用户未关闭PUSH通知的话，push可以从通知栏弹出进行消息显示，具有一定的强提醒性，但PUSH点击跳转后便消失，没有痕迹，因此针对于重点的通知消息，需要在APP内设置消息中心，在PUSH的同时留下通知记录。
2、消息样式
对于各家PUSH来说，一些营销消息会加入EMOJI表情来吸引用户点击，这也是一个吸引用户点击的一个小方法，只要服务支持传输约定好的EMOJI码就可以了。
目前安卓系统也支持富媒体推送，推送包含图片、语音等形式，对于资讯类的APP可以增加缩略图，吸引用户点击。目前来看，语音场景还有待挖掘。
3、 IOS和安卓
由于APP基于手机操作系统，因此对于IOS和安卓的推送的流程及功能基本相同，只不过细节和方法上略有不同，且国内安卓产商都在安卓系统上进行了一定改造，导致国内安卓厂商标准各不相同，需要开发同学仔细对接各个厂商。
八、触达率的提升
触达率提升需要从消息创建到实际通知再到用户来建立一个完整流程，细化每一个交互环节，发现影响触达率的主要瓶颈，并针对性地进行解决或优化方案。除此之外，未采用厂商通道的消息也可以采用自己的长连接和其他推送平台服务同时多条推送，在客户端的SDK内增加针对同一流水号的去重，这样可以也可以提高一部分消息的触达率。
