友盟推送证书

『壹』 友盟推送 任务状态出现筛选结果为空是什么情况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接口，是一个实时的接口，不管是在“测试模式”下，还是在“正式模式”下，都是实时生效的。不过在集成测试阶段，还是建议开发者把手头的设备添加到"测试模式"下的测试设备集合里面，关于“测试模式”的更多介绍，请参考友盟推送“测试模式”介绍。