使用的推Androidclient相对来说，使用比较简单，它提供sdk Demo，根据该文档，并Demo配置相关的代码可以。下面是一个示意图推
client须要区分通知和透传的使用，依据需求告诉服务端选择不同的模板
服务端注意的东西相对来说比較多：
个推每天的消息推送量数以亿计，统计分析日志时，常常能够从日志规律发现调用方的一些使用误区。今天提几点开发人员在使用个推api时易出现的几个误区。
误区一
推送选错接口 个推服务端adk提供给开发人员三个推送接口：pushMessageToSingle/ pushMessageToList/ pushMessageToApp。从命名来看也easy区分。各自是推送单个用户，一批用户，一个应用的所实用户。对于每一个接口。个推服务端的处理逻辑不尽同样，在性能上也有区别。
一般来说推送性能是pushMessageToApp > pushMessageToList > pushMessageToSingle。
当中ToList和ToSingle的使用频率最高。有些开发人员在ToList的场景里选用ToSingle接口，这样就会明显影响推送效率。ToSingle是适合单推特定用户的场景。假设推送内容同样，将推送的对象集合起来，调用ToList接口。能够明显提升性能。
可是对于适合单推的场景使用ToList又会明显减少性能。由于假设每次推送内容不同。
调用ToList之前都须要调用getContentId上传消息体。这样至少从http请求次数来说，已经不合算了。
误区二
推ToList接口列表太大 ToList的性能更高在某个方面来说是由于其一次上传了很多其它的clientId。可是我们不建议一批列表里放太多的clientId，把鸡蛋放在一个篮子里是有风险的。
并且从还有一方面来说。过于巨大的消息体可能会在各个层面出现意料之外的异常。眼下我们建议一批列表里放置不超过100个clientId。这样100万的用户，你须要调用一万次toList接口。
误区三
频繁调用getContentId 在调用ToList之前，须要先调用getContentId上传推送消息体到个推server并获取一个contentId。兴许调用toList仅仅须要上传这个contentId和clientId列表即可。这意味着。假设你须要给100万的用户推送同样内容的消息。每次调用ToList发送100个。那就须要循环调用1万次ToList接口。而这中间，无需再调用getContentId！仅仅须要复用同一个contentId！
由于他们的推送消息体是一样的。
这里常常会有开发人员没有注意，每次都调用一次getContentId再去调用toList接口。这样对推送性能会造成巨大损失。由于你不仅double了http请求次数，并且getContentId相对来说在个推server上也是一个耗时操作。因此，假设你如今正不小心这样错误使用着个推的服务端api。请赶快调整，飞一样的性能提大号肯定会让你眼在明亮的。
版权声明：本文博主原创文章。博客，未经同意不得转载。