推送是可能和用户建设无效的连贯，传播有价值的信息和提供好用的性能，让用户第一工夫获取信息，因而对于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等参数传到Dcloud后盾，当然每个厂商配置的参数不同，具体情况具体看。

个推通道的音讯类型：抉择透传音讯类型，即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;endcomponent=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如果离线，那么推送的音讯会暂存个推离线库，只有客户端在这个无效离线工夫内从新登入就能够再次收到推送，超过无效离线工夫便无奈收到。