個推的使用在Android客戶端相對來說使用比較簡單，已經提供了sdk Demo，按照文檔和Demo配置相關代碼就可以。下圖爲推送的示意圖
客戶端需要區分通知和透傳的使用，根據需求告訴服務端選擇不同的模板
服務端注意的東西相對來說比較多：
個推每天的消息推送量數以億計，統計分析日誌時，經常可以從日誌規律發現調用方的一些使用誤區，今天提幾點開發者在使用個推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，請趕快調整，飛一樣的性能提升肯定會讓你眼前一亮的。
