友盟推送證書

『壹』 友盟推送 任務狀態出現篩選結果為空是什麼情況iOS

篩選結果為空先區分下是開發環境還是生產環境的，如果是開發環境的，先檢專查下能否正確的獲取屬到device token，單播是否成功，如果單播不成功，請檢查下證書是否生成正確，如果單播成功，請檢查下後台添加測試設備的部分，設備描述是紅色嗎，友盟官方有設備描述是紅色的解決方法：http://bbs.umeng.com/thread-7788-1-1.html。如果是生產環境下，單播成功，廣播篩選結果為空，有可能是當時設備信息沒有返回伺服器，您可以刪除後重新安裝，或者稍微等待。

『貳』 ios 友盟推送用生產證書可以嗎

如果你是測試的話，就用開發證書和開發環境，要上架的話，就要生產證書和生產環境

『叄』 友盟推送 出現這個的錯誤 已經做了混淆處理還是不行

Android混淆，又稱Android代碼混淆，是伴隨著Android系統的流行而產生的一種AndroidAPP保護技術，用於回保護APP不被破解和逆向答分析。友盟（Umeng），2010年4月在北京成立，是中國最專業、最有數據凝聚力的移動開發者服務平台。友盟提供iOS、Android和WindowsPhone等多平台服務。友盟消息推送，指向指定終端用戶(單播)、所有終端用戶(廣播)或滿足特定條件的終端用戶群(組播)，發送通知或消息。此外，還支持開發者使用自有的賬號系統(alias)來發送消息給指定的賬號或者賬號群。混淆時排除友盟推送的Jar包，只需要在proguard.cfg文件中加入如下配置即可：-dontwarncom.umeng.**-keepclasscom.umeng*.**{*;}

『肆』 友盟推送的測試模式什麼

友盟消息推送提供了「測試模式」和「正式模式」兩種推送方式。「正式模式」，顧名思義，在該模式下消息會發送給線上真實用戶；而」測試模式」是為便於開發者測試，允許開發者向測試庫中添加測試設備，消息只會發送給測試庫中的設備，以免影響線上用戶。試想一種場景，如果你的App已經上線了，開發人員在測試的時候隨便編輯了一條test消息，一不小心發給了線上真實用戶（小編相信大家的手機上一定收到過類似的莫名其妙的通知消息),作為用戶，不知道這條消息到底意味著什麼，對這個App的認可度可能會下降，更嚴重的是用戶會直接卸載app。這個時候就體現出了測試模式的價值了，只有添加到測試庫中的設備才會收到測試消息。

那既然測試模式這個設計如此有意義，該如何使用呢？很簡單，先獲取到設備的device token(不知道怎麼獲取devicetoken?android，IOS)，之後在網站上添加測試設備（見圖1）。接下來就可以隨意來發測試消息了。當在測試模式下測試沒問題了，想把這條測試消息發到正式模式，但重新在「正式模式」下編輯一遍總歸還是有些麻煩，沒關系，我們很貼心的在測試模式下設計了「模式轉換」的功能（見圖2），會自動跳轉到正式模式下發送消息。根據我們後台的統計，90%以上的用戶在發送正式消息之前，會先選擇在測試模式下發消息，測試沒問題之後，再在正式模式下發送消息到線上用戶。

需要注意的是，對於Android平台來說，測試設備是正式設備的一個子集；而對於iOS平台而言，測試模式對應APNs的開發環境(sandbox), 正式模式對應APNs的生產環境(prod)，測試設備和正式設備完全隔離，所以在iOS平台下發送消息，一定要注意開發/生產證書的問題。下一次，我們會重點給大家介紹蘋果的開發和生產證書。

『伍』 友盟-推送-IOS-IOS如何獲取設備的 DeviceToken

方法1：在 中添加如下語句

NSLog(@"%@",[[[[deviceToken description] : @"<" withString: @""] : @">" withString: @""] : @" " withString: @""]);

方法2：在 didFinishLaunchingWithOptions：NSDictionary *)launchOptions中 開啟UMessage的Log，然版後尋找deviceToken的欄位
//for log
[UMessage setLogEnabled:YES];
以上任一權方式都可在控制台獲取一個長度為64的測試設備的DeviceToken串

『陸』 友盟-推送-API-友盟消息推送API調用有什麼頻率或者次數的限制

第一，支持多維度用戶分群，幫助開發者將不同用戶按照不同特徵分群版，從而為不同分群的用戶推送權最合適的內容，大幅度提升消息打開率和用戶滿意度。 第二，自由選擇發送內容。開發者可以選擇發送通知或者自定義消息，自主決定發送內容是否被展示給...

『柒』 友盟 推送已經做了混淆處理，還是不行，還是如圖的提示

Android混淆，又稱Android代碼混淆，是伴隨著Android系統的流行而產生的一種AndroidAPP保護技術，用於保護APP不被破解和逆向分析。
友盟（Umeng），2010年4月在北京成立，是中國最專業、最有數據凝聚力的移動開發者服務平台。友盟提供iOS、Androi。

『捌』 友盟推送 device token 什麼時候失效

帶著前眷念世世相伴誓言尋輾轉塵世間飄渺紅塵已改變我昔容顏我用盡間卻版等現錯已錯我今夙願…哪怕瞬間權告訴我依守住句誓言奈何橋等百…
實測：demo客戶端從apns獲取了一個device token，這個device token被我們寫死在伺服器的測試程序中。手機重啟不影響push notification的接收（註：手機重啟後，沒有啟動客戶端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介面，是一個實時的介面，不管是在「測試模式」下，還是在「正式模式」下，都是實時生效的。不過在集成測試階段，還是建議開發者把手頭的設備添加到"測試模式"下的測試設備集合裡面，關於「測試模式」的更多介紹，請參考友盟推送「測試模式」介紹。