友盟推送裡面的Alias怎麼用？可以理解成賬號嗎？

01-26

我們的App有自己的賬號體系的，想在每次用戶登陸的時候，給用戶發一個歡迎消息。看了一下友盟推送，裡面有一個概念叫做Alias(別名)，但是官方文檔寫著Alias是和設備綁定的，感覺Alias算不上是嚴格意義的賬號。不知道其它集成過友盟推送的兄弟們是否有類似的需求，是否可以通過友盟推送提供的Alias功能來滿足我們的需求？

分兩部分回答你的問題吧，第一部分是關於你問題中需求的理解；第二部分重點來講講友盟推送是如何設計Alias，以及使用Alias的Best Practice:

你的需求是每次用戶登陸的時候，給用戶發歡迎消息。如果歡迎消息固定的話，那麼你完全可以在App本地實現這個邏輯(實現起來也很簡單)，而非是採用消息推送的方式來實現。如果歡迎消息要做一些個性化歡迎用語，或者是在你們伺服器端來控制歡迎語的話，這種情況下使用推送才是有意義的。根據你的描述，感覺你的需求是想做個性化推送。

接下來重點介紹一下友盟推送在產品層面設計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來做個性化推送了。比如提問中想實現的用戶登陸個性化推送，可以在用戶第一次登陸的時候(這個很好判斷)，開發者在App中調用Alias綁定介面做綁定；之後每次用戶登陸的時候，會在開發者的伺服器端觸發一次登陸事件，開發者在自己的伺服器端根據Alias做「歡迎語」的發送即可。由此來看，Alias的作用是能讓開發者結合自有的賬號(此處需要理解成廣義的賬號)體系，來做更個性化、精細化的推送。下圖是一個簡化的Alias架構，幫助大家理解Alias的用法:

關於Alias的相關介面，我們的友盟消息推送Android文檔提供了非常豐富的介面供開發者調用:

添加Alias mPushAgent.addAlias("zhangsan@sina.com", ALIAS_TYPE.SINA_WEIBO);

移除Alias mPushAgent.removeAlias("zhangsan@sina.com", 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綁定的設備都去推送消息。

關於更多友盟消息推送的問題，歡迎大家在我們的論壇裡面提問: 友盟消息推送論壇，也歡迎大家關注我們的新浪微博賬號"友盟推送": Sina Visitor System