推送是能够和用户建立有效的连接，传达有价值的信息和提供好用的功能，让用户第一时间获取信息，因此对于APP开发者而言，不言而喻，基础且重要。但实际上，Android市场的推送是各自为主，开发者在开发时需要将每个官方的SDK都要开发一遍，工作量，维护程度可想而知！尽管市场上存在一些第三方推送服务商，但有时手机的设置可能会导致push进程被关闭，无法推送。
所以，接下来介绍的这种推送服务，开发者只需要开发一次，系统会自动选择最可靠的推送通道发送消息，在线通过个推推送，离线通过厂商通道推送，不仅送达率高，还降低了开发成本，最主要还免费！
一、UniPush介绍
贴一句官方的介绍：UniPush是DCloud联合个推公司推出的集成型统一推送服务，内建了苹果、华为、小米、OPPO、VIVO、魅族、谷歌FCM等手机厂商的系统级推送和个推等第三方推送。所以想要使用unipush这种推送方案，需要在Dcloud上申请开通unipush服务. 这张图看下unipush的推送的原理：
我们只需要关注的是开发者服务器和客户端接收通知的处理以及要清楚的一点是，消息推送走的渠道是厂商通道和个推通道；大致了解UNIPUSh推送之后，便可进入开发流程了。
二、开发
开发前还是要说明下，客户端接收到通知栏消息时，点击之后需要进行相应的业务处理，障碍在于通知栏已经展示了，但客户端在处理通知栏时会出现很多情况。所以unipush的推送要求开发者要了解前端unipush相关文档以及后端使用的个推文档api，这样才不会踩太多坑。由于unipush是前端所应用的，所以应该要以前端为主，这就要求，前端开发者也要了解个推的api，以便要求后端选择合适的消息类型做推送，这样避免出现后端的消息推送确实送到了，但前端接收消息时，会出现很多情况，我本人在最初开发时，试图找出不同消息类型过来的规律，但常常颠覆认知，所以要全面了解前后的文档，并结合起来，才能会比较顺利。这里说的主要是android的推送，ios推送证书的配置以及推送处理以后再说。
1 后端开发
由于本人主要是做前端的，所以在这块不会去说太多后端的东西，只是说下，后端做推送时，参数的选择，当然个推文档的api很详细，但为了让整个项目流畅的推进，让前端更清楚，方便的处理数据，几个关键参数的选择是极其重要的；
项目中选择的下发策略是在线走个推通道，离线走厂商通道，当然厂商通道需要在各个厂商后台去配置，并将相应的AppID,AppKey,AppSecret等参数传到Dclud后台，当然每个厂商配置的参数不同，具体情况具体看。
个推通道的消息类型：选择透传消息类型，即push_message 里选择transmission，原因是，安卓，iOS都支持，如果通知消息的话，iOS不支持；重点来了，透传消息内容，个推文档上给的很简单就是个字符串，但实际上，字符串里的内容一定要用unipush规定的数据格式，即{"title": "xxx","content": "xxx","payload": "xxx"}，里面的key不能改动，payload是传递的数据参数，然后用字符串包裹起来，这样客户端就会展示通知栏，点击之后，客户端只会触发click事件，但如果不按照这种方式传递的话，客户端不会出现通知栏，消息送达后，会触发receive事件，客户端需要自建通知栏，然后再点击通知栏，触发click事件，这样就比较麻烦了，甚至可能还会出现再次触发receive事件。当然ios端不论怎样，还是会触发receive事件的，此时可以通过aps来做判断，因为ios端自建通知栏还会触发receive事件，所以要做aps的判断，避免发生死循环。
厂商通道的消息类型：选择通知消息类型，原因各个机型都支持，且第三方厂商的通知到达率高于第三方透传的到达率；即push_channel =》android=》ups=》notification，关键的来了，notification的click_type要选择什么?里面可选的参数有intent，url，payload，startapp，其实最能够兼容不同业务类型的方案只有payload，intent这两种，因为可以自定义数据，但是payload，华为和OPPO又不支持，所以只能选择intent，但是大坑又来了，如果你真的只是按照个推文档上给的intent的格式去传递的话，那么客户端会出现很多意想不到的情况，有兴趣的可以去试试看都有什么情况，所以intent的格式也要按照unipush规定的格式去传递，这样，客户端就只会触发click事件.
intent格式：
intent:#Intent;action=android.intent.action.oppopush;launchFlags=0x14000000;component=io.dcloud.HBuilder/io.dcloud.PandoraEntry;S.UP-OL-SU=true;S.title=测试标题;S.content=测试内容;S.payload=test;end
component=io.dcloud.HBuilder/io.dcloud.PandoraEntry 其中io.dcloud.HBuilder为APP包名，需要替换为自己APP的包名；
S.title=的值为推送消息标题，对应5+ API中PushMessage对象的title属性值；
S.content=的值为推送消息内容，对应5+ API中PushMessage对象的content属性值；
S.payload=的值为推送消息的数据，对应5+ API中PushMessage对象的payload属性值；
payload为自定义的数据；title,content,payload,这三个参数是不能改变的，否则客户端接收的数据会有问题；
launchFlags=0x14000000字段，解决接收多条通知后点击可能无法触发click事件的问题；
ios端也是建议用这种格式。
服务端的关键性参数已经说完了，至于其他参数，按照个推文档传，就没啥问题，一定要注意，以上所说的参数不能完全按照个推文档说的格式，不然即便客户端收到了通知，客户端处理起来，会情况百出，这样扯皮事件就有可能发生了！！！
当然，UNIPUSh规定的数据格式或者参数，可能不能设置更多通知栏的样式，比如加些大图或者自定义的图标，角标的设置等，但这样的方式是最兼容，客户端接收数据最便利，最优的方案！
2 前端开发
客户端只有两个事件去处理，click和receive事件，click是点击通知栏触发的事件，receive是监听到透传消息后，触发的事件，通常receive事件监听到后，是需要客户端自建通知栏展示的。
plus.push.addEventListener('click', function(message) {
// click触发后的接收到服务端过来的数据,从而，处理不同的业务需求
})
plus.push.addEventListener('receive', function(message) {
// receive接收到服务端过来的数据,需要自建通知栏展示，
})
如果服务端是按照上述所说的数据类型，格式推送消息的，客户端其实是不会触发到receive事件的，这样就减轻了客户端的工作量，当然ios另当别论。
3 总结
整个推送大致就是这样，当然更多的细节只要按照个推文档给的参数以及参考案例去开发，应该都问题不大。最主要是前后端至少有一个要全部了解才行，否则开发起来会很费力。
Tip
1 通知栏消息:
unipush定义好推送的样式、后续动作的推送方式，客户端接收到后显示在系统通知栏;
2 透传消息:
即自定义消息，unipush推送服务只负责消息传递，不做任何处理，客户端在接受到透传消息后需要自己去处理消息的展示方式或后续动作；发送后不会在系统通知栏展现，SDK将消息传给第三方应用后需要开发者写展现代码才能看到,但如果使用unipush规定好的数据格式，则会出现通知栏，也不会触发receive事件。
3 离线有效时间是指，推送消息的时候，客户端CID如果离线，那么推送的消息会暂存个推离线库，只要客户端在这个有效离线时间内重新登入就可以再次收到推送，超过有效离线时间便无法收到。
