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一些技术干货。