貼連線：
一、客戶端
1、推送種類
2、clientid
1）clientid有什麼用：如果你想給某個使用者發訊息，那你需要clientid，它就是用來區分不同使用者的。
2）clientid從哪來：初始化sdk後，個推伺服器會給裝置返回乙個clientid。
3）clientid特性：對每個裝置來說，clientid應該是固定的，但有可能會變。
4）用法：說下我的處理方式：在sharepreference中儲存clientid，當得到clientid後與儲存的clientid作比較；由於clientid是每個裝置乙個，所有當更換使用者後，也需要更改該使用者對應的clientid：儲存乙個使用者的標記，當使用者發生變更時，判斷標記是否變(更好的處理方式是每次從自己的伺服器獲取使用者對應的clientid，然後和從個推得到的clientid作比較。)。
3、標籤tag
如果你想給某一群使用者發訊息，那麼你需要用到標籤(當然你也可以採用迴圈的方式給clientid來發訊息)。
如果某個使用者有3個標籤，分別是"aaa"、"bbb"、"cc"，而你只給"aaa"、"bbb"標籤發訊息，那麼這個使用者是不會收到訊息的。
設定標籤**：
private pushmanager pm;
pm=pushmanager.getinstance();
tag tag1=new tag();
tag1.setname("aaa");
tag tag2=new tag();
tag2.setname("bbb");
tag tags=new tag[2];
tags[0]=tag1;
tags[1]=tag2;
int i=pm.settag(mainservice.this, tags);
二、服務端常見誤區
誤區一：推送選錯介面
誤區二：推tolist介面列表太大
tolist的效能更高在某個方面來說是因為其一次上傳了更多的clientid。但是我們不建議一批列表裡放太多的clientid，把雞蛋放在乙個籃子裡是有風險的。而且從另一方面來說，過於巨大的訊息體可能會在各個層面出現意料之外的異常。目前我們建議一批列表裡放置不超過100個clientid。這樣100萬的使用者，你需要呼叫一萬次tolist介面。
誤區三：頻繁呼叫getcontenid
在呼叫tolist之前，需要先呼叫getcontentid上傳推送訊息體到個推伺服器並獲取乙個contentid。後續呼叫tolist只需要上傳這個contentid和clientid列表就行。這意味著，如果你需要給100萬的使用者推送相同內容的訊息，每次呼叫tolist傳送100個，那就需要迴圈呼叫1萬次tolist介面。而這中間，無需再呼叫getcontentid！只需要復用同乙個contentid！因為他們的推送訊息體是一樣的。這裡經常會有開發者沒有注意，每次都呼叫一次getcontentid再去呼叫tolist介面。這樣對推送效能會造成巨大損失，因為你不僅double了http請求次數，而且getcontentid相對來說在個推伺服器上也是乙個耗時操作。因此，如果你現在正不小心這樣錯誤使用著個推的服務端api，請趕快調整，飛一樣的效能提公升肯定會讓你眼前一亮的。
個推PC端推送訊息至App
開發準備見官方文件 類使用簡圖 個推管理類 個推管理類 public class getuipushmanager catch exception ex 建立個推伺服器連線 public bool connect catch exception ex return ret 關閉與個推伺服器建立的連線...
魔推mpush 實現精準智慧型訊息推送的五個關鍵
前言 因為工作性質的關係，筆者會接觸到很多非常資深的移動開發商。大部分技術工程師出身的ceo 對技術本身的智財權非常敏感。kk的預言 一文中提出乙個觀點 當擁有智財權不在能夠保證盈利，擁有精準只能的資訊推送能力是今後 開發公司盈利的保證 魔推mpush 是一款訊息推送類 sdk外掛程式，它專門為開發...
魔推mpush 當訊息推送service被殺以後
開發者在開發訊息推送模組時經常會遇到service被殺死的情況。而這個時候，大家採用的方法也很簡單 重啟service。那麼魔推mpush經過多次版本更新，是如何看待並解決這個問題的呢？請看下文。問題是怎麼造成的？採用alarmmanager的方式重啟 魔推mpush在開發初期經常會遇到程式啟動，而...