⑴ 友盟推送服务如何统计App卸载
首先需要澄清一点的是，友盟统计分析服务不会统计，也不能统计设备上App卸载的信息的，友盟统计分析服务只会针对集成友盟统计分析SDK的App提供类似新增、日活、留存等基本指标，或者是开发者自定义的一些统计信息，如自定义事件等。
统计卸载信息其实是在友盟推送SDK里面做的，并且当前统计到的卸载信息也已经部分应用在了消息推送服务里面。接下来就提问者感兴趣的如何统计卸载设备，以及我们目前如何使用这部分卸载信息简单给大家讲一讲，太细节的东东就不便透露了。当然，我们的卸载只是针对android平台来做的，iOS上由于苹果的限制，卸载统计从技术上是很难实现的。
先来说说友盟推送是如何统计卸载:
如果一个设备上有多个集成友盟推送SDK的App的话（注意，必须是集成了友盟推送SDK的App），我们把这些个App称为一个群组或者联盟，同一个群组内的App在推送的通道上是做了很多互保和优化工作的，比如长连接通道就是在这多个App之间共享的。
同一个群组里面的App，如果有某个App发生卸载行为的话，那么这个卸载事件就可以被群组里其它没有卸载的App所知晓，该卸载事件就可以上报给服务器端，服务器端就可以知道哪台设备上哪个App被卸载了。同一个群组内的App之间互相检测卸载是一种常用的手段，但是这个要依赖于设备上集成友盟推送SDK的App有很多个，形成一个群组，如果只有1个App集成了友盟推送的话，那么这种手段是无法捕获到卸载的。 群组内的App越多，卸载统计收集的效果越好。
写到这里，肯定有一部分开发者要问，如果设备上只有1个集成友盟推送SDK的App的话，那么如何统计到这个App是否被卸载了呢？ 这种情况下，我们只能判断到一部分卸载的情况，外加一些其它的辅助判断信息。
那么哪部分可以统计到呢？ 其实还是要依赖于App群组了，假设之前这个设备上只有App A集成了友盟推送，并且A被卸载了，假设后续又安装了集成友盟推送SDK的App B，那么如果给App A发消息，消息送达设备后(因为App B在，所以消息走的是B建立长连通道), 会尝试投递给App A，因为A已经被卸载了，所以投递是不成功的，App B就能感知到这一事件，因此也可以把该卸载信息上报回友盟服务器，服务器也就知道该设备上A App已经被卸载了，其实还是要依赖于设备上的App群组功能。
如果该台设备上后续一直没能有集成友盟推送SDK的App被安装，那么我们只能通过粗糙的看多少天不活跃，比如180天不活跃的App，我们认为这台设备上App已经被卸载了（有一定的偏差，比如某些工具类App，有可能打开频率就非常低），这个不一定准确，但是根据活跃度做用户分层多少也能看出来App的健康度。
接下来再谈谈为什么推送服务要收集设备上App的卸载信息的:
这个其实是和推送的一个硬指标“送达率”戚戚相关的，对于卸载的App，消息肯定是下发不了的，所以在评估送达率的时候，得把这部分卸载的量踢掉，否则在评估和计算送达率的时候，会导致送达率的下降或者不准确。
举个简单地例子，假设某个App有100W的装机量，过了一段时间有20W的卸载（根据我们的观察，20%的卸载率就算平均水平了），那么一次发送任务加入送达了40W的App，那么最终的送达率应该是 40W/(100W-20W) = 50%, 而不是 40W/100W = 40%。 卸载设备的统计越准确，对于最终送达率的评估效果越好。
最后我们来说说卸载统计在友盟推送服务中的应用:
首先在每次推送任务的时候，对于提交过来的device-token，我们会做一次清理，把卸载设备清理掉，所以有时候App开发者或者App运营人员会发现，他们提交的发送总数和友盟后台显示的当次发送数对不上，那就是因为友盟后台已经剔除掉了当次发送任务中的卸载设备了。
其次，当前的卸载统计我们还在进一步的分析和评估中，如果我们收集到的卸载设备数量足够准确，足够全面的时候，我们会把这个功能开放出来，放到统计分析系统里面供App开发者和运营人员来做参考。
⑵ 友盟推送android java端的代码怎么使用
最好的方法，研读官方提供的Demo，这里说的Java端应该是前端，即Android App端，在应用程序启动的时候，开启推送功能，同时在清单文件移植Demo提供的一些内容，测试几遍就差不多了。。。
⑶ 友盟-推送-Andorid-消息推送-打开通知消息进入特定Activity操作
要获取参数的话 只能通过自定义打开行为，重写dealWithCustomAction
在消息推送SDK里，有一个类UmengNotificationClickHandler，负责处理消息的点击事件。 该类主要有四个成员方法：
public void launchApp(Context context, UMessage msg);
public void openUrl(Context context, UMessage msg);
public void openActivity(Context context, UMessage msg);
public void dealWithCustomAction(Context context, UMessage msg);
这四个方法，分别对应于四种打开方式。其中，launchApp、openUrl、openActivity这三个方法已经由消息推送SDK完成，而dealWithCustomAction则只是一个空的方法。 若开发者需要处理自定义行为，则可以重写方法dealWithCustomAction();其中自定义行为的内容，存放在UMessage.custom中。下面是处理自定义行为的代码：
/**
* 该Handler是在BroadcastReceiver中被调用，故
* 如果需启动Activity，需添加Intent.FLAG_ACTIVITY_NEW_TASK
* */
UmengNotificationClickHandler notificationClickHandler = new UmengNotificationClickHandler(){
@Override
public void dealWithCustomAction(Context context, UMessage msg) {
Toast.makeText(context, msg.custom, Toast.LENGTH_LONG).show();
}
};
mPushAgent.setNotificationClickHandler(notificationClickHandler);
注意
以上代码需在 Application 的onCreate() 中调用使用以下接口，而不是在Activity 中调用。如果在Activity中调用此接口，若应用进程关闭， 则设置的接口会无效。 请参考demo 应用代码。
该Handler是在BroadcastReceiver中被调用。因此若需启动Activity，需为Intent添加Flag：Intent.FLAG_ACTIVITY_NEW_TASK，否则无法启动Activity。
若开发者想自己处理打开网页、打开APP、打开Activity，可重写相应的函数来实现。
⑷ Android友盟推送集成
友盟官方文档： https://developer.umeng.com/docs/67966/detail/153908
第一次认真集成推送，碰到了一些问题，记录一下。
首先讲一下实现原理，我们用的是友盟。Android比iOS要麻烦很多。
友盟集成是需要后端配合的，具体就是后端调用友盟的接口，向友盟推送一条消息，然后友盟再向在他们平台注册过的app发送一条消息，我们要做的就是把接收到的消息展示出来。
需求：用户要能在各个时候都能收到我们APP的推送，并且能对应打开不同的界面
解决方法：集成友盟，但是Android只简单集成友盟是不行的，在APP被杀死以后，就接收不到通知了，所以需要额外集成厂商通道。另一个和iOS不一样的就是，iOS在打开当前APP的时候，可以收到横幅推送，但是Android需要自己做。
什么是厂商通道：
由于国内手机厂商过多地使用应用保活方案实现消息推送功能，因此导致手机耗电加快、卡顿。国内部分手机厂商发现了这一问题，自己推出了消息推送服务。这些手机厂商通过进程管理，杀死后台进程，并提供消息推送能力，让消息通过手机厂商官方推送通道下发到应用程序中。这类典型的手机厂商有小米、华为等。
大致分为两部分：
正常推送集成。
五大厂商通道集成。
详见友盟官方文档： https://developer.umeng.com/docs/67966/detail/153908
点击推送信息以后的处理，收到推送的时候的回调
UmengNotificationClickHandler notificationClickHandler =new UmengNotificationClickHandler() {
@Override
public void dealWithCustomAction(Context context, UMessage msg) {
//点击推送通知以后的处理
Log.i(TAG,"notificationClickHandler "+msg);
}
};
UmengMessageHandler messageHandler =new UmengMessageHandler() {
@Override
public void dealWithCustomMessage(final Context context, final UMessage msg) {
Log.i(TAG,"message "+msg);
}
@Override
public NotificationgetNotification(Context context, UMessage uMessage) {
//手机收到推送的时候的回调
Log.i(TAG,"message ");
//返回默认构造
return super.getNotification(context, uMessage);
}
};
mPushAgent.setNotificationClickHandler(notificationClickHandler);
mPushAgent.setMessageHandler(messageHandler);
设置最多能看到的推送条数
mPushAgent.setDisplayNotificationNumber(3);
如果需求中需要打开APP中某个界面，责需要观察 "after_open"字段，默认是 "go_app",需要服务端同学配合
{
"msg_id": "uu481201399440513912",
"display_type": "notification",
"alias": "",
"random_min": 0,
"body": {
"title": "测试自定义参数",
"ticker": "测试自定义参数",
"text": "无",
"after_open": "go_app",
"url": "",
"activity": "",
"custom": "",
"play_vibrate": "true",
"play_sound": "true",
"play_lights": "true"
},
"extra": {
"key1": "value1",
"key2": "value2"
}
}
成功以后可以看log
主要看after_open，默认是打开app
友盟官方常见问题： https://developer.umeng.com/docs/67966/cate/66637
1.集成以后收不到推送
(1) mPushAgent.register（）要放在application中调用，放在别的地方不起作用
(2) 检查so文件有没有放错地方
(3) 打开日志提示，仔细看提示:UMConfigure.setLogEnabled(true)
2.java.lang.ClassNotFoundException: com.ut.mini.UTAnalytics
尽量更新到最新版本的引用，友盟开发说这个只是提示，不用太在意....
3.杀死进程以后收不到推送
解决方法：集成各个厂商通道
iOS的小伙伴集成以后，就算杀死APP也可以收到推送，为啥Android不可以，伤感，看了文档才知道，我们要集成厂商通道，
4.集成以后收不到推送，显示送达却没有弹出通知
manifest里面的package最好与build.gradle中的applicationId不一 致， 因为我们项目有两个applicationId，所以会出现这种情况
需调用setResourcePackageName设置资源文件包名
⑸ 友盟-推送-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一些技术干货。
⑹ 友盟-推送-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接口，是一个实时的接口，不管是在“测试模式”下，还是在“正式模式”下，都是实时生效的。不过在集成测试阶段，还是建议开发者把手头的设备添加到"测试模式"下的测试设备集合里面，关于“测试模式”的更多介绍，请参考友盟推送“测试模式”介绍。