android集成友盟推送

Ⅰ 友盟推送服務如何統計App卸載

首先需要澄清一點的是，友盟統計分析服務不會統計，也不能統計設備上App卸載的信息的，友盟統計分析服務只會針對集成友盟統計分析SDK的App提供類似新增、日活、留存等基本指標，或者是開發者自定義的一些統計信息，如自定義事件等。

統計卸載信息其實是在友盟推送SDK裡面做的，並且當前統計到的卸載信息也已經部分應用在了消息推送服務裡面。接下來就提問者感興趣的如何統計卸載設備，以及我們目前如何使用這部分卸載信息簡單給大家講一講，太細節的東東就不便透露了。當然，我們的卸載只是針對android平台來做的，iOS上由於蘋果的限制，卸載統計從技術上是很難實現的。

先來說說友盟推送是如何統計卸載:

如果一個設備上有多個集成友盟推送SDK的App的話（注意，必須是集成了友盟推送SDK的App），我們把這些個App稱為一個群組或者聯盟，同一個群組內的App在推送的通道上是做了很多互保和優化工作的，比如長連接通道就是在這多個App之間共享的。
同一個群組裡面的App，如果有某個App發生卸載行為的話，那麼這個卸載事件就可以被群組里其它沒有卸載的App所知曉，該卸載事件就可以上報給伺服器端，伺服器端就可以知道哪台設備上哪個App被卸載了。同一個群組內的App之間互相檢測卸載是一種常用的手段，但是這個要依賴於設備上集成友盟推送SDK的App有很多個，形成一個群組，如果只有1個App集成了友盟推送的話，那麼這種手段是無法捕獲到卸載的。 群組內的App越多，卸載統計收集的效果越好。
寫到這里，肯定有一部分開發者要問，如果設備上只有1個集成友盟推送SDK的App的話，那麼如何統計到這個App是否被卸載了呢？ 這種情況下，我們只能判斷到一部分卸載的情況，外加一些其它的輔助判斷信息。

那麼哪部分可以統計到呢？ 其實還是要依賴於App群組了，假設之前這個設備上只有App A集成了友盟推送，並且A被卸載了，假設後續又安裝了集成友盟推送SDK的App B，那麼如果給App A發消息，消息送達設備後(因為App B在，所以消息走的是B建立長連通道), 會嘗試投遞給App A，因為A已經被卸載了，所以投遞是不成功的，App B就能感知到這一事件，因此也可以把該卸載信息上報回友盟伺服器，伺服器也就知道該設備上A App已經被卸載了，其實還是要依賴於設備上的App群組功能。
如果該台設備上後續一直沒能有集成友盟推送SDK的App被安裝，那麼我們只能通過粗糙的看多少天不活躍，比如180天不活躍的App，我們認為這台設備上App已經被卸載了（有一定的偏差，比如某些工具類App，有可能打開頻率就非常低），這個不一定準確，但是根據活躍度做用戶分層多少也能看出來App的健康度。

接下來再談談為什麼推送服務要收集設備上App的卸載信息的:

這個其實是和推送的一個硬指標「送達率」戚戚相關的，對於卸載的App，消息肯定是下發不了的，所以在評估送達率的時候，得把這部分卸載的量踢掉，否則在評估和計算送達率的時候，會導致送達率的下降或者不準確。
舉個簡單地例子，假設某個App有100W的裝機量，過了一段時間有20W的卸載（根據我們的觀察，20%的卸載率就算平均水平了），那麼一次發送任務加入送達了40W的App，那麼最終的送達率應該是 40W/(100W-20W) = 50%, 而不是 40W/100W = 40%。 卸載設備的統計越准確，對於最終送達率的評估效果越好。

最後我們來說說卸載統計在友盟推送服務中的應用:

首先在每次推送任務的時候，對於提交過來的device-token，我們會做一次清理，把卸載設備清理掉，所以有時候App開發者或者App運營人員會發現，他們提交的發送總數和友盟後台顯示的當次發送數對不上，那就是因為友盟後台已經剔除掉了當次發送任務中的卸載設備了。
其次，當前的卸載統計我們還在進一步的分析和評估中，如果我們收集到的卸載設備數量足夠准確，足夠全面的時候，我們會把這個功能開放出來，放到統計分析系統裡面供App開發者和運營人員來做參考。

Ⅱ 友盟推送 android 收到了消息，何為沒有展示到通知欄

第一，支持多維度用戶分群，幫助開發者將不同用戶按照不同特徵分群，從而為不同分群的用戶推送最合適的內容，大幅度提升消息打開率和用戶滿意度。
第二，自由選擇發送內容。開發者可以選擇發送通知或者自定義消息，自主決定發送內容是否被展示給用戶。開發者可以自由配置用戶查看消息後的操作，支持打開 APP指定頁面、打開指定網頁以及其它自定義行為。
第三，靈活接入。支持開發者通過Web 端操作或者 API接入，滿足不同場景下的推送需求。Web端後台操作：開發者可以在 Web後台人工操作，按多個維度篩選用戶並群發消息。
第四，支持API接入方式：開發者可以通過 API對接友盟伺服器，自動化的推送消息。
最後，提下產品的優勢：1）優質的服務質量。實現了同一設備多 APP共享一個長連接、智能心跳等優化方案。消息發送速度快，長連接穩定，設備能耗低。2）提供多種個性化功能，確保用戶體驗最優。最關鍵的是，目前一切，並且沒有任何收費的計劃！

Ⅲ 友盟推送android java端的代碼怎麼使用

最好的方法，研讀官方提供的Demo，這里說的Java端應該是前端，即Android App端，在應用程序啟動的時候，開啟推送功能，同時在清單文件移植Demo提供的一些內容，測試幾遍就差不多了。。。

Ⅳ android 友盟推送為什麼卸載重裝還是能收到推送

appdelegate里有個方法,-(void)application:(UIApplication*):(NSDictionary*)userInfo收到推送消息後就會調用,你在這里讀取消息,再以通知的形式發送到你要處理的指定頁面即可

Ⅳ android 友盟消息推送 如何保活

Ⅵ 友盟-推送-Andorid-「標簽(tag)」是什麼，如何使用自定義標簽

友盟推送支持的篩選維度有「版本」、「渠道」、「地域」、「用戶活躍度」等，還有一個叫做「標簽」，「標簽」是什麼含義呢？該如何使用呢？ 今天我們和大家聊聊這個話題。

先解釋下什麼是「標簽」:

提問者問到的「標簽」其實指的是App開發者結合自有的業務邏輯對該App的終端用戶打的「標簽」，我們也稱tag，這些「標簽」是App自己的標簽（舉個簡單的例子，App根據終端用戶是否注冊，可以給用戶打上「注冊賬號」和「未注冊賬號」的標簽），第三方開發平台是無法直接提供這樣的標簽的(但是可以開放打標簽介面，讓App開發者把標簽數據回傳到第三方伺服器上)，因為具體的業務邏輯是在App這邊的。 第三方開放平台能提供的維度也僅是在用戶協議范圍內可以收集的欄位，比如「版本」、「渠道」、「機型」、「操作系統」等信息，這些維度可以認為是靜態的維度，其實App開發者自己也可以收集這些欄位，只不過交給第三方平台來做數據收集、存儲和計算更為方便，有興趣的讀者可以了解一下友盟推送收集的用戶協議欄位: 友盟 | 隱私政策。

下面我們給大家提供一些有代表性的垂直領域App結合自有業務邏輯給終端用戶打標簽的思路，希望對大家有幫助:
體育類App可以根據終端用戶看過的節目類型，給終端用戶打上「足球」、「籃球」等類目標簽。
兒童類App可以根據兒童的年齡分布，給終端用戶打上「0~1歲」、「1~3」歲、「3~5」歲之類的年齡結構標簽。
電商類App可以根據用戶的購買習慣推算出用戶性別，給終端用戶打上「男」、「女」標簽。
餐飲類App可以根據用戶的下單記錄以及點評，給終端用戶打上「川菜」、「粵菜」、「韓國料理」等標簽。
……

App自有的標簽體系對精細化運營來說是必需的，App運營人員可以根據這些用戶標簽來做精準推送、廣告定向投放、活動邀請等運營活動。既然標簽這么有用，接下來我們和大家聊聊如何在友盟推送中使用「標簽」維度，順帶也回答了提問者的第二個問題。

再來談談如何在友盟推送中使用「標簽」:

上文提到過雖然第三方開放平台無法直接給App開發者提供「標簽」維度，但是可以開放打標簽的介面，讓開發者把標簽數據回傳到第三方伺服器上。下面給大家講講友盟推送開放介面的形式，以及開發者如何使用開放的介面來把標簽數據回傳到友盟伺服器端:

圖中，黃色部分表示友盟推送提供的模塊兒，綠色部分部分表示App開發者自己的模塊兒。

方式1(推薦方式): App端直接調用友盟推送SDK提供的tag介面，由SDK負責把標簽數據回傳到友盟後端伺服器。 後期tag(標簽)的存儲、計算等邏輯都由友盟後端伺服器來負責。這種方式是推薦的方式，絕大部分開發者都採用這種打tag的方式。SDK端提供的調用介面有如下幾個:

mPushAgent.getTagManager().
添加標簽
public Result add(String... tags)
刪除標簽
public Result delete(String... tags)
清除所有標簽
public void reset()
獲取伺服器端的所有標簽
public List<String> list()

具體用法請參照我們的集成文檔: 友盟消息推送Android文檔

方式2: 開發者在自己的伺服器上通過調用友盟伺服器端提供的開放介面將該標簽數據回傳到友盟後端伺服器，效果和方式1一樣。 有這種需求的開發者不是太多，所以我們的文檔上沒有把這個介面列出來，有需求的開發者可以聯系msg-support at umeng dot com來獲取這個介面的文檔。

通過方式1或者方式2，開發者就把和自己App業務相關的標簽屬性維度放在友盟平台上了，這樣友盟推送間接的提供了「標簽」維度，和其它靜態維度一樣，「標簽」可以和這些維度一塊兒來使用(App自身業務邏輯結合友盟數據屬性)，也可以單獨來使用(純App自身業務邏輯)，開發者可以利用這些綜合維度來做更精準的推送，從而獲得更好的推送效果了。關於「精準推送」，感興趣的讀者可以參考我之前寫過的一篇文章: 友盟陳漠沙：「精準推送」是怎樣煉成的？ - 友盟專欄 - 知乎專欄

開發者在使用標簽的過程中，可能會碰到這樣的問題，就是明明在SDK端已經調用了標簽介面，但是在友盟推送後台網站上並沒有顯示出剛剛打的標簽。這里需要和大家解釋一下為什麼「標簽」不能及時展現在我們的網站上，其實還是要區分一下「正式模式」和「測試模式」兩種case的，在「測試模式」下，測試設備的標簽是及時出現在網站後台的；在「正式模式下」，大概會有5~10分鍾的延遲。這是因為數據量規模決定的，測試設備數量少，所以我們能做到實時處理，線上真實設備數據量龐大，計算節點在計算的時候，會有一定的延遲。 所以開發者在集成測試階段，如果要測試tag功能的話，建議先把測試的設備在「測試模式」下添加為測試設備。關於「測試模式」的更多介紹，請參考友盟推送「測試模式」介紹。

最後，歡迎大家關注友盟消息推送的官方微博賬號"友盟推送"，我們的官微會定期和大家share一些技術干貨。

Ⅶ android 友盟推送 未讀消息怎麼做

JPush SDK 收到推送，通過廣播的方式，轉發給開發者App，這樣開發者就可以靈活地進行處理。 這個動作不是必須的。用戶有需要才定義 Receiver 類來處理 SDK過來的廣播。 如果不做這個動作，即不寫自定義 Receiver，也不在 AndroidManifest.xml 里配置這個 Receiver，則默認的行為是： 接收到推送的自定義消息，則沒有被處理 可以正常收到通知，用戶點擊打開應用主界面 接受廣播 如果全部類型的廣播都接收，則需要在 AndroidManifest.xml 里添加如下的配置信息： <receiver android:name="Your Receiver" android:enabled="true"> <intent-filter> <action android:name="cn.jpush.android.intent.REGISTRATION" /> <action android:name="cn.jpush.android.intent.MESSAGE_RECEIVED" /> <action android:name="cn.jpush.android.intent.NOTIFICATION_RECEIVED" /> <action android:name="cn.jpush.android.intent.NOTIFICATION_OPENED" /> <category android:name="You package Name" /> </intent-filter> </receiver> 每個 Receiver action 詳細解釋如下。 Action - cn.jpush.android.intent.REGISTRATION SDK 向 JPush Server 注冊所得到的注冊 ID 。 一般來說，可不處理此廣播信息。 要深入地集成極光推送，開發者想要自己保存App用戶與JPush 用戶關系時，則接受此廣播，取得 Registration ID 並保存與App uid 的關繫到開發者自己的應用伺服器上。 使用極光推送提供的別名與標簽功能，是更加簡單輕便的綁定App用戶與JPush用戶的方式，請參考文檔：別名與標簽使用教程。 Intent 參數 JPushInterface.EXTRA_REGISTRATION_ID SDK 向 JPush Server 注冊所得到的注冊 全局唯一的 ID ，可以通過此 ID 向對應的客戶端發送消息和通知。 Bundle bundle = intent.getExtras(); String title = bundle.getString(JPushInterface.EXTRA_REGISTRATION_ID); Action - cn.jpush.android.intent.MESSAGE_RECEIVED 收到了自定義消息 Push 。 SDK 對自定義消息，只是傳遞，不會有任何界面上的展示。 如果開發者想推送自定義消息 Push，則需要在 AndroidManifest.xml 里配置此 Receiver action，並且在自己寫的 BroadcastReceiver 里接收處理。 Intent 參數 JPushInterface.EXTRA_TITLE 保存伺服器推送下來的消息的標題。 對應 API 消息內容的 title 欄位。 對應 Portal 推送消息界面上的「標題」欄位（可選）. Bundle bundle = intent.getExtras(); String title = bundle.getString(JPushInterface.EXTRA_TITLE); JPushInterface.EXTRA_MESSAGE 保存伺服器推送下來的消息內容。 對應 API 消息內容的 message 欄位。 對應 Portal 推送消息界面上的"消息內容」欄位。 Bundle bundle = intent.getExtras(); String message = bundle.getString(JPushInterface.EXTRA_MESSAGE); JPushInterface.EXTRA_EXTRA 保存伺服器推送下來的附加欄位。這是個 JSON 字元串。 對應 API 消息內容的 extras 欄位。 對應 Portal 推送消息界面上的「自定義內容」。 Bundle bundle = intent.getExtras(); String extras = bundle.getString(JPushInterface.EXTRA_EXTRA); JPushInterface.EXTRA_CONTENT_TYPE 保存伺服器推送下來的內容類型。 對應 API 消息內容的 content_type 欄位。 Bundle bundle = intent.getExtras(); String type = bundle.getString(JPushInterface.EXTRA_CONTENT_TYPE); JPushInterface.EXTRA_RICHPUSH_FILE_PATH SDK 1.4.0 以上版本支持。 富媒體通消息推送下載後的文件路徑和文件名。 Bundle bundle = intent.getExtras(); String file = bundle.getString(JPushInterface.EXTRA_RICHPUSH_FILE_PATH); JPushInterface.EXTRA_MSG_ID SDK 1.6.1 以上版本支持。 唯一標識消息的 ID, 可用於上報統計等。 Bundle bundle = intent.getExtras(); String file = bundle.getString(JPushInterface.EXTRA_MSG_ID); Action - cn.jpush.android.intent.NOTIFICATION_RECEIVED 收到了通知 Push。 如果通知的內容為空，則在通知欄上不會展示通知。但是，這個廣播 Intent 還是會有。開發者可以取到通知內容外的其他信息。 Intent 參數 JPushInterface.EXTRA_NOTIFICATION_TITLE 保存伺服器推送下來的通知的標題。 對應 API 通知內容的 n_title 欄位。 對應 Portal 推送通知界面上的「通知標題」欄位。 Bundle bundle = intent.getExtras(); String title = bundle.getString(JPushInterface.EXTRA_NOTIFICATION_TITLE); JPushInterface.EXTRA_ALERT 保存伺服器推送下來的通知內容。 對應 API 通知內容的 n_content 欄位。 對應 Portal 推送通知界面上的「通知內容」欄位。 Bundle bundle = intent.getExtras(); String content = bundle.getString(JPushInterface.EXTRA_ALERT); JPushInterface.EXTRA_EXTRA SDK 1.2.9 以上版本支持。 保存伺服器推送下來的附加欄位。這是個 JSON 字元串。 對應 API 通知內容的 n_extras 欄位。 對應 Portal 推送通知界面上的「自定義內容」欄位。 Bundle bundle = intent.getExtras(); String extras = bundle.getString(JPushInterface.EXTRA_EXTRA); JPushInterface.EXTRA_NOTIFICATION_ID SDK 1.3.5 以上版本支持。 通知欄的Notification ID，可以用於清除Notification Bundle bundle = intent.getExtras(); int notificationId = bundle.getInt(JPushInterface.EXTRA_NOTIFICATION_ID); JPushInterface.EXTRA_CONTENT_TYPE 保存伺服器推送下來的內容類型。 對應 API 消息內容的 content_type 欄位。 Portal 上暫時未提供輸入欄位。 Bundle bundle = intent.getExtras(); String type = bundle.getString(JPushInterface.EXTRA_CONTENT_TYPE); JPushInterface.EXTRA_RICHPUSH_HTML_PATH SDK 1.4.0 以上版本支持。 富媒體通知推送下載的HTML的文件路徑,用於展現WebView。 Bundle bundle = intent.getExtras(); String fileHtml = bundle.getString(JPushInterface.EXTRA_RICHPUSH_HTML_PATH); JPushInterface.EXTRA_RICHPUSH_HTML_RES SDK 1.4.0 以上版本支持。 富媒體通知推送下載的圖片資源的文件名,多個文件名用 「，」 分開。 與 「JPushInterface.EXTRA_RICHPUSH_HTML_PATH」 位於同一個路徑。 Bundle bundle = intent.getExtras(); String fileStr = bundle.getString(JPushInterface.EXTRA_RICHPUSH_HTML_RES); String[] fileNames = fileStr.spilt(","); JPushInterface.EXTRA_MSG_ID SDK 1.6.1 以上版本支持。 唯一標識通知消息的 ID, 可用於上報統計等。 Bundle bundle = intent.getExtras(); String file = bundle.getString(JPushInterface.EXTRA_MSG_ID); Action - cn.jpush.android.intent.NOTIFICATION_OPENED 用戶點擊了通知。 一般情況下，用戶不需要配置此 receiver action。 如果開發者在 AndroidManifest.xml 里未配置此 receiver action，那麼，SDK 會默認打開應用程序的主 Activity，相當於用戶點擊桌面圖標的效果。 如果開發者在 AndroidManifest.xml 里配置了此 receiver action，那麼，當用戶點擊通知時，SDK 不會做動作。開發者應該在自己寫的 BroadcastReceiver 類里處理，比如打開某 Activity 。 Intent 參數 JPushInterface.EXTRA_NOTIFICATION_TITLE 保存伺服器推送下來的通知的標題。 對應 API 通知內容的 n_title 欄位。 對應 Portal 推送通知界面上的「通知標題」欄位。 Bundle bundle = intent.getExtras(); String title = bundle.getString(JPushInterface.EXTRA_NOTIFICATION_TITLE); JPushInterface.EXTRA_ALERT 保存伺服器推送下來的通知內容。 對應 API 通知內容的n_content欄位。 對應 Portal 推送通知界面上的「通知內容」欄位。 Bundle bundle = intent.getExtras(); String content = bundle.getString(JPushInterface.EXTRA_ALERT); JPushInterface.EXTRA_EXTRA SDK 1.2.9 以上版本支持。 保存伺服器推送下來的附加欄位。這是個 JSON 字元串。 對應 API 消息內容的 n_extras 欄位。 對應 Portal 推送通知界面上的「自定義內容」欄位。 Bundle bundle = intent.getExtras(); String type = bundle.getString(JPushInterface.EXTRA_EXTRA); JPushInterface.EXTRA_NOTIFICATION_ID SDK 1.3.5 以上版本支持。 通知欄的Notification ID，可以用於清除Notification Bundle bundle = intent.getExtras(); int notificationId = bundle.getInt(JPushInterface.EXTRA_NOTIFICATION_ID JPushInterface.EXTRA_MSG_ID SDK 1.6.1 以上版本支持。 唯一標識調整消息的 ID, 可用於上報統計等。 Bundle bundle = intent.getExtras(); String file = bundle.getString(JPushInterface.EXTRA_MSG_ID); 代碼示例 public void onReceive(Context context, Intent intent) { Bundle bundle = intent.getExtras(); Log.d(TAG, "onReceive - " + intent.getAction()); if (JPushInterface.ACTION_REGISTRATION_ID.equals(intent.getAction())) { } else if (JPushInterface.ACTION_MESSAGE_RECEIVED.equals(intent.getAction())) { System.out.println("收到了自定義消息。消息內容是：" + bundle.getString(JPushInterface.EXTRA_MESSAGE)); // 自定義消息不會展示在通知欄，完全要開發者寫代碼去處理 } else if (JPushInterface.ACTION_NOTIFICATION_RECEIVED.equals(intent.getAction())) { System.out.println("收到了通知"); // 在這里可以做些統計，或者做些其他工作 } else if (JPushInterface.ACTION_NOTIFICATION_OPENED.equals(intent.getAction())) { System.out.println("用戶點擊打開了通知"); // 在這里可以自己寫代碼去定義用戶點擊後的行為 Intent i = new Intent(context, TestActivity.class); //自定義打開的界面 i.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK); context.startActivity(i); } else { Log.d(TAG, "Unhandled intent - " + intent.getAction()); } }

Ⅷ AndroidStudio 怎麼集成友盟的分享

直接上友盟的網站, 有詳細集成步驟, 還有Demo

Ⅸ 友盟-推送-Andorid-「Alias」是什麼, 該如何使用

不少開發者在使用友盟推送的時候，對Alias的用法和使用場景不是太理解，這篇文章給大家普及一下Alias相關的內容:

我們先從產品層面上對Alias的設計思想說起，這樣能幫助大家更好的理解和使用Alias。在我們官方文檔裡面，Alias的定義是: "設備別名，將別名與設備做綁定，便於部分App開發者使用自有賬號或者第三方賬號體系來做消息推送"。定義裡面涉及到幾個重要的點:
首先，Alias是和設備綁定的，友盟推送對設備的標識是device-token，也就是說，Alias與友盟device-token是綁定對應的。從這個層面來講，Alias可以是開發者的賬號系統(包括第三方賬號體系)，也可以是開發者自己對設備的標識體系(如安卓設備上的imei+mac)，或者是其它的開發者能保證唯一性的ID體系，這些都是由開發者自己決定的。提問中問到是否可以把Alias理解為賬號系統，狹義上講可以這么理解，實際上，友盟推送賦予了Alias更多的靈活性。
其次，結合到越來越多的App提供第三方社交平台賬號登陸的特點，我們在Alias的設計上也充分考慮到了賬號的需求，所以在官方文檔中，我們提到在使用Alias的時候，必須要關聯一個alias_type, 如果是開發者自定義的alias(包括自有賬號系統)，這個alias_type是可以隨便定義的；如果是用了第三方賬號系統，我們預提供了20多種主流的開放平台的賬號類型，如新浪微博(SINA_WEIBO), 微信(WEIXIN)等。填寫alias_type的作用是，友盟推送會和友盟社會化分享服務做數據上的打通，更好的從數據層面發揮價值，為開發者服務。說到這里，我們再次精確一下Alias的概念，即別名(Alias)+別名類型(alias_type)與設備的綁定。
最後，我們來聊聊Alias的用法，這個也是開發者們非常關心的。我們Alias的綁定操作是在SDK端提供的，開發者只需要在SDK端調用mPushAgent.addAlias(alias, alias_type)這個介面，友盟推送SDK就負責把alias+alias_type與友盟的device-token做綁定，將綁定關系回傳到友盟後端伺服器。之後開發者就可以根據自有業務邏輯，調用友盟伺服器端介面，根據Alias來做個性化推送了。由此來看，Alias的作用是能讓開發者結合自有的賬號(此處需要理解成廣義的賬號)體系，來做更個性化、精細化的推送。下圖是一個簡化的Alias架構，幫助大家理解Alias的用法:

關於Alias的相關介面，我們的友盟消息推送Android文檔提供了非常豐富的介面供開發者調用:
[Java] 純文本查看 復制代碼
?
1
2
3
4
5
添加Alias
mPushAgent.addAlias("[email protected]", ALIAS_TYPE.SINA_WEIBO);

移除Alias
mPushAgent.removeAlias("[email protected]", ALIAS_TYPE.SINA_WEIBO);

注意，在App伺服器端調用友盟伺服器端介面做推送的時候，一定不要忘了傳入alias_type的參數。

關於Alias基本的話題差不多解釋清楚了，最後再和大家深入聊聊Alias用作賬號系統涉及到多賬號多設備登陸的問題，這個時候，alias_type就派上用場了，相信看過這個章節後，大家會對我們Alias的設計機制有更深入的理解:
1. 多個賬號登陸同一台設備，具體還要細分為兩種case:
如果是同一個alias_type，那麼以最後綁定的alias為准。舉個例子: (alias_A, alias_type_A)先做了綁定，之後(alias_B, alias_type_A)後做了綁定，那麼，如果這個時候給alias_A發消息，設備是不會收到消息的，因為在友盟推送後台device-token是和最後登陸的alias_B做綁定的。這個在實際業務場景中也成立，最後一個登錄的賬號才是這台設備當前真實的用戶。
如果不是同一個alias_type, 那麼前後兩個綁定的alias均生效。舉個例子: (alias_A, alias_type_A)先做了綁定，之後是(alias_B, alias_type_B)做了綁定，那麼不管是給alias_A發消息，還是給alias_B發消息，設備均能收到消息。因為alias_type變化之後，友盟推送後台確定不了這是同一個用戶(eg: 同一個用戶使用不同平台的賬號登錄)，還是不同的用戶(不同的用戶，使用不同的賬號登錄)，友盟只能簡單的判定這兩個不同alias_type的賬號是兩個不同的賬號。這種場景是需要特別注意的，建議開發者在實際的集成過程中盡量避免這種使用場景。
2. 同一個賬號登錄多台設備:
這種情況處理起來就比較簡單了，即一個alias和多個device-token做綁定。如果給這個alias發消息，我們會給所有和這個alias綁定的設備都去推送消息。

開發者在具體使用過程中，可能會想到Alias做了綁定(addAlias)或者解除(removeAlias)之後,多長時間能在後端生效。 Alias介面，是一個實時的介面，不管是在「測試模式」下，還是在「正式模式」下，都是實時生效的。不過在集成測試階段，還是建議開發者把手頭的設備添加到"測試模式"下的測試設備集合裡面，關於「測試模式」的更多介紹，請參考友盟推送「測試模式」介紹。

Ⅹ android 極光推送與友盟推送哪個比較好

個人感覺極光比較好，因為極光畢竟開始就是主要做推送這塊的。