友盟推送里面的Alias怎么用？可以理解成账号吗？

Posted 2020-08-02 风与叶子

友盟推送里面的Alias怎么用？可以理解成账号吗？

我们的App有自己的账号体系的，想在每次用户登陆的时候，给用户发一个欢迎消息。 看了一下友盟推送，里面有一个概念叫做Alias(别名)，但是官方文档写着Alias是和设备绑定的，感觉Alias算不上是严格意义的账号。不知道其它集成过友盟推送的兄弟们是否有类似的需求，是否可以通过友盟推送提供的Alias功能来满足我们的需求？

 

 

作者：沙漠
链接：http://www.zhihu.com/question/31882775/answer/54254062
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

分两部分回答你的问题吧，第一部分是关于你问题中需求的理解；第二部分重点来讲讲友盟推送是如何设计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("[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绑定的设备都去推送消息。

 

http://www.zhihu.com/question/31882775