即时消息技术剖析与实战
袁武林
微博研发中心技术专家
立即订阅
6503 人已学习
课程目录
已完结 24 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 搞懂“实时交互”的IM技术,将会有什么新机遇?
免费
基础篇 (8讲)
01 | 架构与特性:一个完整的IM系统是怎样的?
02 | 消息收发架构:为你的App,加上实时通信功能
03 | 轮询与长连接:如何解决消息的实时到达问题?
04 | ACK机制:如何保证消息的可靠投递?
05 | 消息序号生成器:如何保证你的消息不会乱序?
06 | HttpDNS和TLS:你的消息聊天真的安全吗?
07 | 分布式锁和原子性:你看到的未读消息提醒是真的吗?
08 | 智能心跳机制:解决网络的不确定性
场景篇 (4讲)
09 | 分布式一致性:让你的消息支持多终端漫游
10 | 自动智能扩缩容:直播互动场景中峰值流量的应对
11 | 期中实战:动手写一个简易版的IM系统
12 | 服务高可用:保证核心链路稳定性的流控和熔断机制
进阶篇 (10讲)
13 | HTTP Tunnel:复杂网络下消息通道高可用设计的思考
14 | 分片上传:如何让你的图片、音视频消息发送得更快?
15 | CDN加速:如何让你的图片、视频、语音消息浏览播放不卡?
16 | APNs:聊一聊第三方系统级消息通道的事
17 | Cache:多级缓存架构在消息系统中的应用
18 | Docker容器化:说一说IM系统中模块水平扩展的实现
19 | 端到端Trace:消息收发链路的监控体系搭建
20 | 存储和并发:万人群聊系统设计中的几个难点
21 | 期末实战:为你的简约版IM系统,加上功能
22 | 答疑解惑:不同即时消息场景下架构实现上的异同
结束语 (1讲)
结束语 | 真正的高贵,不是优于别人,而是优于过去的自己
即时消息技术剖析与实战
登录|注册

16 | APNs:聊一聊第三方系统级消息通道的事

袁武林 2019-10-02
你好,我是袁武林。
前面几节课里,我讲到在即时消息场景下,我们会依赖服务端推送技术来提升消息到达的实时性,以及通过各种手段来保证消息收发通道的可用性,从而让消息能尽量实时、稳定地给到接收人。
但在实际情况中,出于各种原因,App 与服务端的长连接会经常断开。比如,用户彻底关闭了 App,或者 App 切换到后台一段时间后,手机操作系统为了节省资源,会杀掉进程或者禁止进程的网络功能。在这些情况下,消息接收方就没有办法通过 App 和 IM 服务端的长连接来进行消息接收了。
那有没有办法,能让消息在 App 被关闭或者网络功能被限制的情况下,也能发送到接收人的设备呢?答案是:有。
现在手机常用的 iOS 和 Android 系统,都提供了标准的系统级下发通道,这个通道是系统提供商维护的与设备的公共长连接,可以保证在 App 关闭的情况下,也能通过手机的通知栏来下发消息给对应的接收人设备。而且,当用户点击这些通知时,还能重新唤醒我们的 App,不仅能提升消息的到达率,还增加了用户的活跃度。

第三方系统下发通道

常见的第三方系统下发通道,有 iOS 端的 APNs,以及 Android 端的 GCM 和厂商系统通道。
iOS 端的 APNs(Apple Push Notification service,苹果推送通知服务),是独立于应用之外,依托系统常驻进程来维护和苹果服务器的公共长连接,负责全局的系统推送服务。
在 Android 端上,有 Google 的 GCM(Google Cloud Message,Google 云消息传递)。但 GCM 由于某些技术原因(如 NAT 超时太长、暴露的 5228 端口连通性差等)和某些非技术原因(需要和 Google 服务器建立连接),Android 端的 GCM 在国内被大部分手机厂商定制化后直接去掉,并替换成了各自的系统通道。目前国内 Android 的系统级下发通道基本都是厂商通道,目前已知的有 5 家:小米、华为、vivo、OPPO、魅族。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《即时消息技术剖析与实战》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(10)

  • 谢炳辉
    怎么理解
    因此在没有 WiFi 和移动网络的场景下,我们只要有手机信号就能推送
    不是有信号就有网络了吗

    作者回复: 这里说的是某些场景下手机没有网络信号,只有通信信号,也就是能打电话能收短信但是上不了网。

    2019-11-15
    1
  • GeekAmI
    “一般情况下,我们的 IM 服务端可以在每次启动 App 时,都去请求 APNs 服务器进行注册,来获取 DeviceToken。”
    老师,这句话不太理解,到底是App去APNs获取DeviceToken,还是IM服务端获取呢?

    作者回复: app去APNs获取devicetoken,如果发生了变化再由app上报给im服务器进行记录。

    2019-11-11
    1
  • clip
    “DeviceToken 是 APNs 用于区分识别不同 iOS 设备同一个 App 的唯一标识”
    是“不同 iOS 设备不同 App”吗?

    作者回复: devicetoken只是识别设备的哈,每台设备的devicetoken都不一样。

    2019-10-03
    3
    1
  • 老师,Apple除了静默推送,还有更可靠的Voip 推送哦

    作者回复: 👍

    2019-11-21
  • GeekAmI
    静默推送是不是可以这样搞?
    静默推送->唤起app->重新建立长连接通道->服务端通道长连接通道下达消息。

    作者回复: app在后台被静默推送唤醒后只有30s的后台运行时间,所以建立长连后可能也会很快再被掐断。可以考虑用来进行一些多媒体消息的后台预拉取。

    2019-11-11
  • 白泗小林
    apns 的消息去重一般怎么做的?

    作者回复: APNs本身并不保证消息不重不丢,所以实际上很难控制,应用层面能做的只是尽量避免业务层面重复发送给APNs导致重复下推的问题。

    2019-10-31
  • Michael
    每台iPhone设备的的deviceToken都不一样,IM服务器给APNs推送消息数据需要带上deviceToken,但是IM Server是如何获取到设备的deviceToken的呢?

    作者回复: 课程中有讲到哈:一般情况下,我们的 IM 服务端可以在每次启动 App 时,都去请求 APNs 服务器进行注册,来获取 DeviceToken。正常情况下,客户端每次获取到的 DeviceToken 都不会变,速度也比较快。客户端在首次获取到 DeviceToken 之后,会先缓存到本地,如果下次获取到 DeviceToken 后,它没有发生变化,那么就不需要我们再调用 IM 服务端进行更新了。这也算是个小技巧。

    2019-10-20
    1
  • Michael
    思考题:可以唤起app,重新建立长连接。

    作者回复: 嗯,这个是比较常见的用法。

    2019-10-04
  • 刘丹
    请问如果发送方使用小米的推送服务,那么非小米手机怎样接收到消息呢?竞争品牌可能不允许在手机里安装小米的拉取软件。

    作者回复: 一般这些推送服务是已sdk的方式集成到你自己的app里,推送不是独立存在的一个app。另外,这个得看下小米的推送服务是否有集成接收方手机的厂商sdk,如果有,那应该是没问题的,如果没有,估计厂商很难让第三方推送服务的长连接运行。

    2019-10-02
  • 小可
    app后台自动升级(如果设置自动更新升级)

    作者回复: 嗯,这个应该是可行的。

    2019-10-02
收起评论
10
返回
顶部