码迷,mamicode.com
首页 > 其他好文 > 详细

第三方推送-个推使用

时间:2014-06-01 10:37:56      阅读:247      评论:0      收藏:0      [点我收藏+]

标签:android   c   style   blog   a   http   

个推的使用在Android客户端相对来说使用比较简单,已经提供了sdk Demo,按照文档和Demo配置相关代码就可以。下图为推送的示意图

bubuko.com,布布扣

客户端需要区分通知和透传的使用,根据需求告诉服务端选择不同的模板

bubuko.com,布布扣



服务端注意的东西相对来说比较多

个推每天的消息推送量数以亿计,统计分析日志时,经常可以从日志规律发现调用方的一些使用误区,今天提几点开发者在使用个推api时易出现的几个误区。

误区一 

推送选错接口 个推服务端adk提供给开发者三个推送接口:pushMessageToSingle/ pushMessageToList/ pushMessageToApp。从命名来看也容易区分,分别是推送单个用户,一批用户,一个应用的全部用户。对于每个接口,个推服务端的处理逻辑不尽相同,在性能上也有差别。一般来说推送性能是pushMessageToApp > pushMessageToList > pushMessageToSingle。其中ToList和ToSingle的使用频率最高。有些开发者在ToList的场景里选用ToSingle接口,这样就会明显影响推送效率,ToSingle是适合单推特定用户的场景,如果推送内容相同,将推送的对象集合起来,调用ToList接口,可以明显提升性能。但是对于适合单推的场景使用ToList又会明显降低性能,因为如果每次推送内容不同。调用ToList之前都需要调用getContentId上传消息体,这样至少从http请求次数来说,已经不合算了。


误区二

 推ToList接口列表太大 ToList的性能更高在某个方面来说是因为其一次上传了更多的clientId。但是我们不建议一批列表里放太多的clientId,把鸡蛋放在一个篮子里是有风险的。而且从另一方面来说,过于巨大的消息体可能会在各个层面出现意料之外的异常。目前我们建议一批列表里放置不超过100个clientId。这样100万的用户,你需要调用一万次toList接口。


误区三

频繁调用getContentId 在调用ToList之前,需要先调用getContentId上传推送消息体到个推服务器并获取一个contentId。后续调用toList只需要上传这个contentId和clientId列表就行。这意味着,如果你需要给100万的用户推送相同内容的消息,每次调用ToList发送100个,那就需要循环调用1万次ToList接口。而这中间,无需再调用getContentId!只需要复用同一个contentId!因为他们的推送消息体是一样的。这里经常会有开发者没有注意,每次都调用一次getContentId再去调用toList接口。这样对推送性能会造成巨大损失,因为你不仅double了http请求次数,而且getContentId相对来说在个推服务器上也是一个耗时操作。因此,如果你现在正不小心这样错误使用着个推的服务端api,请赶快调整,飞一样的性能提升肯定会让你眼前一亮的。


第三方推送-个推使用,布布扣,bubuko.com

第三方推送-个推使用

标签:android   c   style   blog   a   http   

原文地址:http://blog.csdn.net/duanyu218/article/details/27700571

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!