前言

個推每天的訊息推送量數以億計，統計分析日誌時，經常可以從日誌規律發現呼叫方的一些使用誤區，今天提幾點開發者在使用個推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，請趕快調整，飛一樣的效能提升肯定會讓你眼前一亮的。