友盟-推送-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端调用mPushAgentaddAlias(alias, alias_type)这个接口，友盟推送SDK就负责把alias+alias_type与友盟的device-token做绑定，将绑定关系回传到友盟后端服务器。之后开发者就可以根据自有业务逻辑，调用友盟服务器端接口，根据Alias来做个性化推送了。由此来看，Alias的作用是能让开发者结合自有的账号(此处需要理解成广义的账号)体系，来做更个性化、精细化的推送。下图是一个简化的Alias架构，帮助大家理解Alias的用法:
关于Alias的相关接口，我们的友盟消息推送Android文档提供了非常丰富的接口供开发者调用:
[Java] 纯文本查看 复制代码

1
2
3
4
5
添加Alias
mPushAgentaddAlias("zhangsan@sinacom", ALIAS_TYPESINA_WEIBO);

移除Alias
mPushAgentremoveAlias("zhangsan@sinacom", ALIAS_TYPESINA_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接口，是一个实时的接口，不管是在“测试模式”下，还是在“正式模式”下，都是实时生效的。不过在集成测试阶段，还是建议开发者把手头的设备添加到"测试模式"下的测试设备集合里面，关于“测试模式”的更多介绍，请参考友盟推送“测试模式”介绍。

先简单介绍下push的机制
客户端通过
(void)registerForRemoteNotificationTypes:(UIRemoteNotificationType)types
这个函数向APNs（Apple Push Service）注册push，types可标明接收的push的类型，声音，数字等。
(void)application:(UIApplication )application didRegisterForRemoteNotificationsWithDeviceToken:(NSData )deviceToken;
当app成功注册通知后，会调用这个函数，并把deviceToken返回给应用。
然后我们的程序就会把返回的这个deviceToken以及设备的udid及软件版本（淘宝 for iPhone还是淘宝 for iPad）及系统版本，用户名等发送到我们的服务器（下图中的provider）上，然后存储在数据库里。整个获取device token的过程可参见下图所示：
APNs可以根据与APNs建立连接的Provider所使用的证书判断是要哪个app请求发送的notification，继而把这个notification发送到的设备上。
下图为一个简单的从Provider到Device发送push的过程：
对于APS来说，token是设备的标识符。device token不同于UIDevice的uniqueIdentifier（即UDID），因为出于安全和隐私原因，当设备被擦除后，token必须变化。
所以也就是说，一般情况下，token是不变的，但是在设备被擦除后，token会变的。
今天无心说在我们的服务器上的数据库里，存在同一个UDID对应有多个token的情况，之前是没有考虑到设备擦除的情况，所以就怀疑是不是同一个 设备上同时装了taobao4iphone和taobao4ipad，而token是与app关联的，所以产生的这种情况，于是就找了杨匡的ipad来做 测试，结果发现taobao4iphone和taobao4ipad收到的token是相同的，所以token应该是与app无关的，而是针对设备的（文 档上也是如此描述的），是设备的标识，那除了设备被擦除的情况外，设备的device token 应该是相同的，可是杨匡说之前崇厚给他查出来的他的iPad的token和我log出来的device token是不同的，后来就想到了，push是有两套的，development和product，即调试和release，在这两种情况下，服务端使用 的push证书是不一样的，而程序使用的证书也不一样，那同一个设备在development和distribution情况下收到的device token是否一样呢，于是就做了实验，实际结果如下
实验设备：iPad 1
<img size-full="" wp-image-39"="" src=">首先请确定您的证书是否导入正确：
确认App首次运行有没有d出打开通知的对话框
如果没有的话，请确定：
首先确认App是第一次安装运行没有d出（系统只提示一次）
可以把App删除后，再重新build运行一次
如果确实是第一次安装运行且没有d出，请仔细按照证书配置的要求重新生成一遍Provisioning Profiles。
如果有的话，请确定获取device token的方法是正确的。
方法1：在 didRegisterForRemoteNotificationsWithDeviceToken 中添加如下语句
NSLog(@"%@",[[[[deviceToken description] stringByReplacingOccurrencesOfString: @"<" withString: @""]
stringByReplacingOccurrencesOfString: @">" withString: @""]
stringByReplacingOccurrencesOfString: @" " withString: @""]);
方法2：在 didFinishLaunchingWithOptions:(NSDictionary )launchOptions中 开启UMessage的Log，然后寻找deviceToken的字段
//for log
[UMessage setLogEnabled:YES];
以上任一方式都可在控制台获取一个长度为64的测试设备的DeviceToken串

筛选结果为空先区分下是开发环境还是生产环境的，如果是开发环境的，先检查下能否正确的获取到device token，单播是否成功，如果单播不成功，请检查下证书是否生成正确，如果单播成功，请检查下后台添加测试设备的部分，设备描述是红色吗，友盟官方有设备描述是红色的解决方法：>