友盟推送ios 友盟怎么接收推送消息推送

友盟推送服务如何统计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开发者和运营人员来做参考。

友盟-推送-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，可重写相应的函数来实现。

ios 友盟怎么接收推送消息推送

接收到通知时有两种进入的方式： 1.当app未运行时 (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions；launchOptions不会为空，就可以根据launchOptions是否为空来判断是否有推送消息，当launchOptions不为空时，你就可以发一个通知，可以再rootViewController中接收通知执行响应的操作。

2.当app在后台运行时 激活APP时会走 -(void)eActive:(UIApplication *)application；这个方法，在这里面里可以对推送消息做响应的处理