使用的推androidclient相對來說，使用比較簡單，它提供sdk demo，根據該文件，並demo配置相關的**可以。下面是乙個示意圖推
client須要區分通知和透傳的使用，依據需求告訴服務端選擇不同的模板
服務端注意的東西相對來說比較多：
個推每天的訊息推送量數以億計，統計分析日誌時，常常能夠從日誌規律發現呼叫方的一些使用誤區。今天提幾點開發人員在使用個推api時易出現的幾個誤區。
誤區一
當中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。請趕快調整，飛一樣的效能提大號肯定會讓你眼在明亮的。
Android第三方推送分析
最近，公司的乙個物聯網專案android端，由於要保證推送的到達率和穩定性，由於google 的原生推送 c2dm，現在的 gcm 不能正常使用，故只能退而求其次採用了整合多方推送的方案。目前國內的主流的手機廠商主要有 華為，小公尺，oppo,vivo,魅族等。華為，小公尺都有官方自己的推送服務，其...
第三方推送已死
2010 年左右，android 手機在國內迅速發展，google 的原生推送 c2dm，現在的 gcm 由於種種原因不能正常使用，當時的 android 開發者使用各種辦法來解決這個問題，其中就包括 android 手機廠商開發出自己的推送方案。這幾年經常有業內的朋友 推送能否送達的關鍵因素。其實...
rest呼叫第三方介面以及給第三方推送資料
1，rest呼叫第三方介面 第三方傳送post請求，json物件 如果有引數可以放進map裡 jsonobject body entity.getbody 2，rest呼叫第三方介面 第三方傳送get請求，json串 string url resttemplate resttemplate new ...