友盟 有关设备离线和在线问题

本文详细解析了友盟推送中设备的各种状态,包括在线、离线、未注册及状态不存在的情况。介绍了如何判断设备是否在线,以及影响设备在线状态的因素,如网络环境、pushservice运行状态等。

本文转载自:有关设备离线和在线问题


有关设备离线,在线,设备未注册以及设备状态不存在等状态,请参考下文: Android查询设备状态,几种状态的解释说明
判断设备长连是否在线应该在在友盟推送后台--工具--设备状态查询里面查询,如下图:

       如果设备长连在线仍然没有收到:可以查询下,设备状态有个更新时间,如下图:

       统计设备长连在线时间(最后更新时间)有时是有一些延时的。有可能最后更新时间时设备在线,但当前设备已经是离线状态了。

       设备长连在线只和三个条件有关:1、网络环境稳定良好     2、pushservice运行3、push service连接上友盟服务器。

       判断pushservice是否运行,要在设定--应用程序管理--运行中进行查看进程,如下图:



       你也可以通过 adb shell ps | grep com.umeng.message.example 这个指令查询到友盟push的进程,如下图:



       说到pushservice,我们就要引入“宿主”的概念了。
       由于pushSDK在设计上采取了多路复用的技术方案,即设备上多个集成了友盟消息推送SDK的App会共用一条长连通道, push service会挂靠在某一个App上,此时长连service所挂靠的App称为“宿主”。
       综上,若自己的App不是宿主,而是挂在别的App上,我们会提示目前的宿主是用户设备中的哪款App,并附上当时设备的device_token,如下图:

(图为2015年圣诞前夕,友盟推送的节日特别页面)

       如上文所说,设备在线时,push service应该是运行的。但也有可能push service在用户设备上存在,却未连接到友盟推送的服务器,从而导致了设备离线。检查此种情况,你可以在logcat里面,查看push service的心跳信息,如下图:

       如果有心跳信息的话,说明用户设备到友盟推送服务器之间的长连接是畅通的,但是有可能消息已经推送到了设备上,却并没有被展示出来。此时,你可以再查询一下设备的消息历史,如下图所示 :


       这里我来解释下“已送达“这个状态的定义。”已送达“说明消息已经确实被下发。消息送达到设备后,设备返回给友盟推送服务器一个ack回执,告诉服务器端App已经收到消息,服务器才会把状态归档成 ”已送达”。
       此外,通过查看logcat里面的onMessage,也可以打印出来消息是否已经送到,如下图:

        
      
       当你通过上述两种方式确定消息已经下发到手机,但是并没有显示出来后,你需要检查以下情况:
1、 包名填错了,即包名与申请时所填的包名不一致;因此,消息无法路由到App头上。(详见STEP 3)
2、 在之前的代码里调用了PushAgent.setPushIntentServiceClass(MyPushIntentService.class);
后来又将该代码注释了。但是由于,SDK使用的SharedPreference存储该IntentService变量名,故虽然代码被注释了,但仍然可以从SharedPreference里读取到相应的IntentService,从而导致错误。
遇到此种情况,你只需把app清理数据或者重新安装便可解决。
3、 有可能是个别机型或者个别设备的适配问题所导致的,可以尝试换个其他型号的设备再进行测试。

在 iOS 平台上,集成腾讯云 IM 的离线推送功能时,可能会导致友盟推送无法正常接收消息。这种问题通常出现在多个推送服务同时使用的情况下,尤其是在系统级推送通道的抢占处理上存在冲突。 iOS 系统对远程推送(Remote Notification)有严格的限制机制,同一时间只能有一个推送服务可以成功唤醒 App,并触发对应的回调方法。当腾讯云 IM 的离线推送通过 Apple Push Notification 服务(APNs)送达时,系统会优先唤醒腾讯云 IM 的推送处理逻辑,而友盟推送的消息可能被忽略或未能正确触发应用层的回调函数[^3]。 ### 推荐解决方案如下: #### 1. 统一推送证书与设备 Token 管理 确保所有推送服务(包括腾讯云 IM 友盟)都使用相同的推送证书(开发/生产环境一致),并统一管理设备 Token 的上报流程。若两个 SDK 分别注册了各自的 Device Token 到各自的服务器,则可能导致推送路由混乱[^4]。 ```swift // 示例 - 在 AppDelegate 中统一处理 Device Token 上报 func application(_ application: UIApplication, didRegisterForRemoteNotificationsWithDeviceToken deviceToken: Data) { // 腾讯云 IM 处理 TIMManager.sharedInstance().handleDeviceToken(deviceToken) // 友盟推送处理 UMSocialManager.default().application(application, didRegisterForRemoteNotificationsWithDeviceToken: deviceToken) } ``` #### 2. 消息格式标准化 建议将推送消息的 payload 格式进行统一规范,例如在 APNs 的 `userInfo` 字段中设置特定标识符来区分消息来源,并由主 App 逻辑统一调度处理。 ```json { "aps": { "alert": "你有一条新消息", "badge": 1, "sound": "default" }, "source": "tencent_im" } ``` 在 `AppDelegate` 的 `didReceiveRemoteNotification` 方法中根据 `source` 字段决定将消息转发给哪个 SDK 进行进一步处理[^3]。 #### 3. 使用通知扩展(Notification Service Extension) iOS 提供了通知扩展机制,可以在推送到达时对原始 payload 进行修改或合并。利用此特性,可以实现多个推送服务的消息合并处理,避免因系统只唤醒一个服务而导致另一方丢失消息。 创建一个新的 Notification Service Extension Target,并在其中判断是否为腾讯云 IM 或友盟的消息,进行相应的自定义逻辑处理。 #### 4. 设置后台任务唤醒机制 如果确实需要两个推送服务同时运行,可考虑在收到任一推送后主动拉取其他服务的消息状态,确保遗漏重要通知。例如,在收到腾讯云 IM 推送后,主动向友盟服务查询是否有待处理的消息。 ```swift func application(_ application: UIApplication, didReceiveRemoteNotification userInfo: [AnyHashable : Any], fetchCompletionHandler completionHandler: @escaping (UIBackgroundFetchResult) -> Void) { if let source = userInfo["source"] as? String { if source == "tencent_im" { // 处理腾讯云 IM 消息 } else if source == "umeng" { // 处理友盟消息 } // 主动拉取其他服务消息 checkOtherPushServices() } completionHandler(.newData) } ``` ###
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值