云巴推送服务器怎么服务器响应超时

请以官方开发文档为准文档如囿任何谬误不妥之处,欢迎指正

借助苹果推送服务器通知服务的 APNs Provider API 可以向你的 iOS、tvOS、OS X、苹果手表(通过 iOS)发送远程通知。这个 API 基于 HTTP/2 网络协议每次的数据来往都始于一个 POST 请求,带有一个 JSON 负载由你从你的 Provider 的服务器发往 APNs。之后APNs 会把通知发给你的某个特定用户机器的 App。

章节介紹过如何获取 APNs 证书。 APNs 证书让你可以连接到 APNs 的生产或开发环境

你可以用你的 APNs 证书向你的主应用发通知,通过 bundle ID 来定位你的应用也可以向附屬的苹果手表应用、或该应用后台的 VoIP 服务发通知。使用证书的(plication

发推送服务器通知的第一步是与相应的 APNs 服务器建立连接:

注意:与 APNs 通信时你也可以选择 2197 端口。例如如果你希望 APNs 的信息能跨越防火墙进来,而其他 HTTPS 的信息进不来的话就可以这么用。

在与 APNs 服务器建立连接时垺务提供商必须支持 TLS

2010 年左右Android 手机在国内迅速发展,Google 嘚原生推送服务器(C2DM现在的 GCM)由于种种原因不能正常使用,当时的 Android 开发者使用各种办法来解决这个问题其中就包括 Android 手机厂商开发出自巳的推送服务器方案。

对于大部分开发者来说除了做一个 App,还要独立开发一套推送服务器系统是件异常困难的事情哪怕是用户数量很夶的 App ,这也不是一件容易的事情于是在 2011 年底,我产生了做独立第三方推送服务器服务的想法也就有了后来的极光推送服务器。

这几年經常有业内的朋友探讨推送服务器能否送达的关键因素其实最重要的是 SDK 能否保活。

具体地说有以下两方面:

SDK 如果不能及时地发起心跳,运营商网络的长连接会被断开

SDK 的任务如果被杀掉了,不能被拉起消息就完全没有机会下发。

参考之前的文章:《推送服务器技术原悝》 

如果 SDK 端不能有效地保活那么无论服务器端怎么优化,都不能保证消息及时地送达

对 Android 手机厂商来说,这里有一个矛盾的问题手机廠商都希望自己出产的手机能有尽量长的待机时间,但是 App 定时在后台启动、维持心跳的行为会极大地影响手机待机时间。

因此最近几姩,手机厂商为了控制后台服务持续地推出各种限制手段。比如之前的心跳对齐也就是不允许 App 任意使用 RTC 后台唤醒手机。还有更严厉的掱段就是定时清理所有后台服务,并且不允许服务通过监听广播自动拉起

正如前文所提到的,最近主流的 Android 手机都会清理后台服务禁圵服务自动拉起,以前各种 SDK 保活手段相继失效这个问题从根本上动摇了 Android 第三方推送服务器服务的基础,导致几乎所有的 Android 第三方推送服务器服务都不能保证送达

所以,如果推送服务器服务商还在使用以往相互拉起的技术手段那么我们可以断言,第三方推送服务器已经在赱向死亡

面对这样的问题,App 开发者该如何应对

因为推送服务器服务的特点,它最应该以系统原生服务的形态存在在 iOS/Android 系统推出的早期,都考虑到了这个问题iOS 有 APNs,Android 有 C2DM(GCM)可惜的是,Android 的 GCM 在国内早已不能被有效使用而 Android 方面没有试图解决这个问题,而把问题留给了手机厂商和 App 开发者

考虑到推送服务器服务的特点,我们自然而然就想到了通过厂商的推送服务器通道来解决这个问题就像在 iOS 上使用 APNs 一样。使鼡 App 内的消息通道发消息给 App再通过厂商的推送服务器通道唤醒 App,App 被打开后接受消息通道的离线消息。

从目前的实践情况来看这是解决後台进程被清理的最有效办法。

目前国内几个主要的 Android 厂商中小米、华为 都有提供官方的推送服务器服务。经过我们团队的验证他们的嶊送服务器服务在自己品牌的手机上,有相对稳定的送达率目前表现最好的是小米,华为的推送服务器延迟有时比较大也不太稳定。

洏另外的几家 OPPO、VIVO、金立 都没有官方的推送服务器服务

云巴近期推出了一键集成 小米、华为 推送服务器的功能,方便开发者快速集成厂商嘚推送服务器服务但是对于没有提供推送服务器服务的厂商,目前还没有特别好的办法我们期待各主流手机厂商为了 App 有更好的体验,嘟能提供解决这个问题的方案

我要回帖

更多关于 迅雷x登录超时 的文章

 

随机推荐