关于app:App推送

推送是可能和用户建设无效的连贯，传播有价值的信息和提供好用的性能，让用户第一工夫获取信息，因而对于 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;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 如果离线，那么推送的音讯会暂存个推离线库，只有客户端在这个无效离线工夫内从新登入就能够再次收到推送，超过无效离线工夫便无奈收到。