php友盟推送

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

每分鍾發送次數,對於單播目前沒有限制。 對於已經上線的App，每天不超過3次，但是這個限制次數根據業務場景可以申請調大。 功能如下：
第一，支持多維度用戶分群，幫助開發者將不同用戶按照不同特徵分群，從而為不同分群的用戶推送最合適的內容，大幅度提升消息打開率和用戶滿意度。
第二，自由選擇發送內容。
第三，靈活接入。支持開發者通過Web 端操作或者 API接入，滿足不同場景下的推送需求。
第四，支持API接入方式：開發者可以通過 API對接友盟伺服器，自動化的推送消息。
從總體來說極光更適合我們的選擇。極光多種消息類型，開發者可以輕松地通過極光發送各個移動平台的系統通知，還可以在控制台編輯多種富文本展示模板； 極光還提供自定義消息的透傳，客戶端接到消息內容後根據自己的邏輯自由處理。

② php 友盟推送ios 哪個是內容

當應用在前端收到推送的時候，友盟會彈出alert。使用[UMessage setAutoAlert:NO];可以關閉該彈窗。但是，要注意這句代碼的位置。要寫在這里：
- (void)application:(UIApplication *)application didReceiveRemoteNotification:(NSDictionary *)userInfo
{
//當應用在前台的時候發送消息的提示彈窗
[UMessage setAutoAlert:NO];//要寫在下面那句代碼的上面，才不會自動彈出alertview
//友盟推送
[UMessage didReceiveRemoteNotification:userInfo];
}

③ 友盟推送位元組數限制

暫時沒有限制。
最終選擇友盟推送的原因，參考官網1、多平台一鍵下發，聚合廠商通道。目前已覆蓋華為、小米、魅族，支持系統級下發通道，提高消息到達率。同時避免app自己集成多廠商sdk的繁瑣2、消息無痕撤回、個性化推送方案。3、目前友盟官網貼出的客戶較多，不乏淘寶、迅雷、頭條等app，這樣可最大程度借用「看護功能」。且友盟推送是免費的。

④ php通過第三方推送消息給你APP要怎樣寫

0.477248911誰有小白資源網李風老師錄制的安卓入門視頻教程？2016年最新0.477248911((～ o ～)~zZ)

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

消息推送API對於一下兩個方面來看：
1、廣播：對於沒有上線的App(集成個數小於200)，沒有限制。 對於已經上線的App，每天不超過3次，但是這個限制次數根據業務場景可以申請調大。
2、每分鍾發送次數，對於單播目前沒有限制。 對於任務(非單播)，每分鍾不能超過5次。
關於消息推送可以選擇第三方平台來幫助實現，比如極光，深圳市和訊華谷信息技術有限公司創立於2011年，其團隊核心成員來自騰訊、摩根士丹利、豆瓣、Teradata和中國移動等公司。公司總部位於深圳，在北京、上海、廣州、成都均設有辦公室。
極光是中國領先的開發者服務提供商，專注於為開發者提供穩定高效的消息推送、一鍵認證以及流量變現等服務，助力開發者的運營、增長與變現。同時，極光的行業應用已經拓展至市場洞察、金融風控與商業地理服務，助力各行各業優化決策、提升效率。

⑥ 友盟-推送-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介面，是一個實時的介面，不管是在「測試模式」下，還是在「正式模式」下，都是實時生效的。不過在集成測試階段，還是建議開發者把手頭的設備添加到"測試模式"下的測試設備集合裡面，關於「測試模式」的更多介紹，請參考友盟推送「測試模式」介紹。

⑦ 友盟推送, 怎樣 實現用戶查看消息後 打開 APP指定頁面

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

關於打開 APP指定頁面這個是需要後台設置或者入口調試的

⑧ 友盟推送的測試模式什麼

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


那既然測試模式這個設計如此有意義，該如何使用呢？很簡單，先獲取到設備的device
token(不知道怎麼獲取devicetoken?android，IOS)，之後在網站上添加測試設備（見圖1）。接下來就可以隨意來發測試消息了。當在測試模式下測試沒問題了，想把這條測試消息發到正式模式，但重新在「正式模式」下編輯一遍總歸還是有些麻煩，沒關系，我們很貼心的在測試模式下設計了「模式轉換」的功能（見圖2），會自動跳轉到正式模式下發送消息。根據我們後台的統計，90%以上的用戶在發送正式消息之前，會先選擇在測試模式下發消息，測試沒問題之後，再在正式模式下發送消息到線上用戶。
需要注意的是，對於Android平台來說，測試設備是正式設備的一個子集；而對於iOS平台而言，測試模式對應APNs的開發環境(sandbox),
正式模式對應APNs的生產環境(prod)，測試設備和正式設備完全隔離，所以在iOS平台下發送消息，一定要注意開發/生產證書的問題。下一次，我們會重點給大家介紹蘋果的開發和生產證書。

⑨ 在友盟推送中，單播和任務有什麼關系又有什麼區別

由於單播和列播只是最基本的推送功能，且發送數量有一定的限制，對於數量龐大的推送和多維度的精準推送顯然有些捉襟見肘。所以「任務」便應運而生了。 任務是除了單播和列播外的其它類型的播的類型的統稱。任務包括廣播、組播、文件播以及自定義播（必須是文件形式）。在功能上，與單播和列播相比，任務支持實現消息的查詢和撤銷；在推送策略上，任務還支持定時發送功能；在發送頻率上，每分鍾發送次數，對於單播目前沒有限制，對於任務，每分鍾不能超過3次。

⑩ 友盟-推送-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一些技術干貨。