App未启动时的推送，不是App自己联网收消息，而是操作系统代收后唤醒App

当 Android 和 iOS 手机上的 App 未启动（甚至被杀死） 时，仍能收到推送消息，其底层原理依赖于 操作系统提供的系统级推送服务，而非 App 自身维持的网络连接。以下是两者的精简对比与核心原理：

✅ 共同前提

  • 用户首次启动过 App（完成推送 Token 注册）
  • 用户未关闭该 App 的通知权限
  • App 已正确集成系统推送 SDK

📱 iOS 推送原理：Apple Push Notification service (APNs)

底层机制：

  1. 系统级长连接
    iOS 系统在设备激活后，自动与 Apple 服务器建立安全、持久的 TLS 长连接（由 apsd 守护进程维护），所有 App 共用此通道。

  2. Token 注册
    App 首次启动时调用 registerForRemoteNotifications() → 系统返回唯一 device token → App 上传该 token 到业务服务器（如 OpenIM 后端）。

  3. 离线推送流程

    • 业务服务器 → 将消息 + device token 发给 APNs
    • APNs → 通过系统长连接将推送下发到设备
    • iOS 系统 → 直接显示通知（即使 App 未启动）
    • 用户点击通知 → 系统拉起 App

✅ 特点：

  • 高度可靠：Apple 强制统一通道，无厂商碎片化问题
  • 无需 App 保活：完全由系统接管
  • 全球一致：无论设备在哪，都走 APNs

🤖 Android 推送原理：分两类（海外 vs 国内）

1. 海外（Google 设备）→ Firebase Cloud Messaging (FCM)

  • 类似 APNs：Google Play 服务维护全局长连接
  • App 注册 FCM token → 业务服务器通过 FCM API 推送
  • 系统收到后唤醒 App 或显示通知
  • 要求设备有 Google Play 服务（GMS）

2. 国内（无 GMS）→ 各手机厂商推送通道

由于国内 ROM 禁止后台自启和长连接，必须使用厂商专属推送服务：

厂商推送服务
华为 Huawei Push Kit
小米 MiPush
OPPO OPPO Push
vivo vivo Push
荣耀 Honor Push

工作流程：

  1. App 集成多个厂商 SDK（或使用聚合 SDK 如“个推”、“极光”）
  2. 首次启动时，检测当前手机品牌 → 注册对应厂商的 push token
  3. 业务服务器（如 OpenIM）根据用户设备类型，调用对应厂商的推送 API
  4. 厂商服务器 → 通过其系统级常驻服务下发消息 → 系统显示通知 → 拉起 App

⚠️ 国内 Android 限制：

  • 若 App 从未启动 → 无法注册 token → 收不到推送
  • 用户“强制停止”App → 部分厂商会暂停推送
  • 必须适配多家厂商 SDK，开发复杂度高

🔁 对比总结

维度iOS (APNs)Android 海外 (FCM)Android 国内（厂商通道）
推送通道 苹果统一 APNs Google FCM 华为/小米/OPPO/vivo 等
是否需 App 启动过 是 是 是
App 被杀死能否收 ✅ 能 ✅ 能 ✅ 能（依赖厂商）
开发复杂度 低（一套方案） 低 高（需多厂商适配）
可靠性 极高 高 中（各厂商品控不一）

💡 对 OpenIM 开发者的建议

  • iOS：只需集成 APNs，OpenIM 服务端支持对接 APNs
  • Android：
    • 海外：集成 FCM
    • 国内：必须集成主流厂商推送 SDK，并在 OpenIM 后端配置多通道路由
  • 纯自建 WebSocket 无法实现“App 未启动时推送”，必须依赖系统通道

✅ 核心结论：
App 未启动时的推送，不是 App 自己联网收消息，而是操作系统代收后唤醒 App。
这是 iOS 和 Android 实现“离线触达”的唯一可靠方式。

微信作为中国最主流的即时通讯应用，其推送方案是 高度定制化 + 多通道融合 的架构，既不完全依赖系统推送，也不仅靠自建连接。以下是其核心策略（基于公开技术分享与行业分析）：

✅ 微信的推送方案：“自建长连接为主 + 系统推送为辅”

1. 主通道：自建高可用长连接（核心）

  • 微信在 App 启动后，会与微信服务器建立 私有协议的 TCP 长连接（非 WebSocket）。
  • 该连接用于：
    • 实时收发消息
    • 同步联系人、群组状态
    • 心跳保活（极低功耗）
  • 优势：延迟极低（毫秒级）、可控性强、不依赖第三方。

2. 辅助通道：系统推送（兜底）

尽管微信有能力维持连接，但它仍然接入了系统推送作为保底：

  • iOS：接入 APNs
    • 当用户杀死微信、或长时间后台被系统挂起时，新消息通过 APNs 推送。
    • 用户点击通知 → 拉起微信 → 自动同步完整消息。
  • Android 国内：接入 华为、小米、OPPO、vivo 等厂商推送
    • 在极端省电模式、App 被强制停止等场景下，通过厂商通道触达用户。
    • 微信安装时会自动检测机型并注册对应厂商 Token。

📌 微信官方曾透露：90%+ 的消息通过自建连接送达，系统推送仅用于“极端离线”场景。

🔍 为什么微信敢用自建连接？（普通 App 难以复制）

原因说明
用户高频使用 微信日活超 10 亿，用户每天多次打开，系统难以彻底杀死其进程
系统白名单特权 华为、小米等厂商将微信加入 “后台冻结豁免名单”，允许其常驻
深度 ROM 合作 与主流手机厂商达成合作，获得更高后台优先级
极致功耗优化 自研心跳算法（如智能休眠、动态间隔），避免被系统判定为耗电

⚠️ 普通 App 若模仿微信仅用自建连接，在国内 Android 上极易被杀后台，导致消息严重延迟或丢失。

🆚 对比普通 App（如集成 OpenIM）

方案微信普通 App（如企业 IM）
主通道 ✅ 自建长连接（可靠） ⚠️ 自建连接（易被杀）
辅助通道 ✅ APNs + 全厂商推送 ✅ 必须依赖厂商推送兜底
后台存活率 >95% <60%（国内中低端机更低）
开发建议 可主推自建连接 必须以厂商推送为核心

💡 结论

微信 = 自建连接（主力） + 系统推送（保底）
但这是其产品地位 + 技术积累 + 厂商特权共同作用的结果。

对大多数开发者而言：不要学微信只做自建连接！
✅ 正确做法：

  • iOS：必须用 APNs
  • Android 国内：必须接入主流厂商推送，并将其作为主要离线通道
  • 自建连接仅用于 App 前台/活跃状态下的实时通信

简单说：微信有“特权”，你没有——所以请老老实实用系统推送兜底。

 

 

MQTT（Message Queuing Telemetry Transport）本身 不是推送通知系统，而是一种轻量级的发布/订阅消息传输协议。但它常被用于实现“类推送”功能，尤其在 IoT、IM 或需要低功耗长连接的场景中。

下面从底层原理讲清楚：MQTT 如何实现“推送”效果？它与 APNs/厂商推送有何区别？

✅ 一、MQTT 的“推送”本质：客户端维持长连接 + 服务端主动下发

底层工作流程：

  1. 客户端（App/设备）主动连接 MQTT Broker

    • 使用 TCP（或 WebSocket）建立持久连接。
    • 订阅一个或多个 Topic（如 /user/123/messages）。

  2. 服务端（业务系统）向 Broker 发布消息

    • 将消息发到指定 Topic（如 /user/123/messages）。

  3. Broker 立即转发给所有在线订阅者

    • 只要客户端连接在线，消息毫秒级送达，表现为“服务端推送”。

📌 这不是操作系统级推送，而是 应用层长连接的实时消息投递。

⚠️ 二、关键限制：App 必须保持 MQTT 连接在线

场景能否收到“推送”
App 在前台运行 ✅ 能（连接活跃）
App 在后台（未被杀） ⚠️ Android 可能断连（省电策略）
iOS 后台几秒后挂起
App 被用户杀死 / 未启动 ❌ 完全收不到（无连接）

🔥 核心问题：MQTT 依赖 App 自身维持连接，无法突破操作系统对后台进程的限制。

🔄 三、MQTT vs 系统推送（APNs / 厂商通道）

维度MQTT系统推送（APNs / 华为/小米 Push）
连接主体 App 自己维护 TCP 连接 操作系统维护全局长连接
App 未启动时能否收 ❌ 不能 ✅ 能
功耗 较高（需心跳保活） 极低（系统统一复用连接）
可靠性 依赖网络和 App 存活 高（系统级保障）
适用场景 在线实时通信（如聊天、IoT 控制） 离线消息触达（如新消息提醒）

💡 四、实际 IM 系统如何结合 MQTT？

成熟 IM 架构通常 MQTT + 系统推送 结合使用：

                ┌──────────────┐
                │ 业务服务器    │
                └──────┬───────┘
                       │
       ┌───────────────┴───────────────┐
       ▼                               ▼
┌─────┐               ┌─────────────────┐
│ MQTT Broker │               │ APNs / 厂商推送  │
└──────┬──────┘               └────────┬────────┘
       │                                │
       │ (App 在线时)                   │ (App 离线时)
       ▼                                ▼
   App 实时收消息                   系统通知栏提醒
  • App 在线 → 通过 MQTT 实时收消息（低延迟）
  • App 离线 → 服务端检测不到连接 → 调用 APNs/厂商推送 → 用户点击通知 → 拉起 App → 同步历史消息

✅ OpenIM、企业微信等均采用类似混合方案。

🛑 五、为什么国内 Android 不推荐纯 MQTT 推送？

  1. ROM 厂商限制后台：华为、小米等会杀死非白名单 App 的后台进程，MQTT 连接断开。
  2. 无统一保活机制：不像 iOS 有 VoIP/Background Modes，Android 后台管控极严。
  3. 耗电被用户投诉：自建长连接易被系统判定为“异常耗电”。

📌 国内 Android 必须依赖 厂商推送通道 实现离线触达，MQTT 仅用于在线场景。

🔚 总结

  • MQTT 的“推送” = 应用层长连接实时投递，不是操作系统级推送。
  • 优势：低延迟、双向通信、适合在线场景。
  • 致命缺陷：App 未启动或被杀后完全失效。
  • 正确用法：

    MQTT 负责“在线实时通信”，系统推送负责“离线唤醒” —— 两者互补，不可替代。

❌ 切勿用纯 MQTT 实现“消息必达”需求（如客服、订单通知），必须搭配 APNs/厂商推送！

 

 

 

极光推送（JPush）是国内主流的第三方推送服务平台，其底层原理是 “聚合多通道 + 智能路由” 的架构，核心目标是在 Android 碎片化环境 和 iOS 统一生态 下，实现高到达率的消息触达。

以下是其底层工作原理的精简解析（截至 2026 年）：

✅ 一、整体架构：客户端 SDK + 云端智能路由 + 厂商/系统通道

业务服务器
     │
     ▼
极光推送云平台（JPush Server）
     │
     ├─ iOS → 转发至 Apple APNs
     │
     └─ Android → 智能选择最优通道：
           ├─ 华为 Push Kit
           ├─ 小米 MiPush
           ├─ OPPO Push
           ├─ vivo Push
           ├─ 荣耀 Push
           └─ 自建通道（仅限在线设备）

📱 二、iOS 推送原理（简单统一）

  1. App 首次启动时，调用 JPush SDK → 请求 APNs Token
  2. JPush SDK 将 Token 上传至极光服务器
  3. 你的业务服务器调用 JPush API 发送推送
  4. 极光服务器 → 将消息转发给 Apple APNs
  5. APNs → 通过系统级长连接将通知推送到设备 → 显示通知栏

✅ 完全依赖 APNs，极光仅做代理和统计。可靠、低功耗、全球一致。

🤖 三、Android 推送原理（复杂，核心在“通道聚合”）

由于国内 Android 无 Google FCM，极光采用 “厂商通道优先 + 自建通道兜底” 策略：

步骤 1：注册阶段（App 首次启动）

  • JPush SDK 自动检测手机品牌（华为、小米等）
  • 调用对应厂商的 Push SDK（如华为 HMS Core）注册
  • 获取 厂商专属 Registration ID（RegID）
  • 同时生成极光自己的 Registration ID（用于自建通道）

步骤 2：推送阶段（业务服务器调用 JPush API）

极光服务器根据设备信息 智能选择通道：

设备状态使用通道到达率
华为手机 + HMS 可用 华为 Push Kit ⭐⭐⭐⭐⭐（>95%）
小米手机 MiPush ⭐⭐⭐⭐☆
其他品牌（如三星、荣耀） 对应厂商通道 ⭐⭐⭐⭐
无法使用厂商通道（如模拟器） 极光自建 TCP 长连接 ⭐⭐（仅 App 在线时有效）

🔑 关键点：极光为每个设备维护一个 映射表，知道该走哪家厂商通道。

步骤 3：消息下发

  • 若走厂商通道 → 极光调用厂商服务器 API → 厂商系统服务唤醒 App 或显示通知
  • 若走自建通道 → 仅当 App 后台存活且连接在线时才能收到（离线无效）

⚙️ 四、极光自建通道（Android 保活机制）

为提升在线消息体验，极光在 Android 上还维护一套 自建长连接：

  • 基于 TCP + 私有协议，支持心跳、重连、QoS
  • 通过 多进程守护 + JobScheduler + 前台服务 尽量保活
  • 但无法突破厂商后台限制（如华为“应用启动管理”禁止自启）

⚠️ 自建通道 仅用于 App 在线时的实时消息（如聊天），不能替代厂商通道用于离线推送。

📊 五、极光的核心优势

能力说明
多厂商一键集成 开发者只需集成 JPush SDK，无需单独对接华为/小米等
通道自动降级 厂商通道失败 → 自动尝试其他方式
到达率统计 提供各通道送达、点击数据
离线消息缓存 消息可缓存 72 小时，设备上线后补推（仅限自建通道）

⚠️ 六、局限性

  1. 依赖厂商通道权限：若用户关闭“自启动”或“通知权限”，推送失败
  2. 新机型适配延迟：新手机发布后，需等待极光更新 SDK 支持
  3. 自建通道不可靠：在国内中低端机上，后台极易被杀
  4. 隐私合规要求：需用户授权，部分 ROM 弹窗频繁影响体验

🔚 总结

极光推送 = APNs 代理（iOS） + 厂商通道聚合器（Android） + 自建连接兜底

  • iOS：稳定可靠，完全走 Apple 官方通道
  • Android：高到达率靠厂商通道，不是靠极光自己
  • 开发者价值：屏蔽碎片化，一套 API 接入全平台

✅ 正确理解：
极光不是“自己推送”，而是“帮你把消息交给 Apple 或华为/小米去推送”。

💡 对 IM 开发者建议：
在 OpenIM 等系统中集成极光，仅用于离线消息兜底，在线消息仍应走 WebSocket/MQTT。

posted @ 2026-01-06 19:24  jerry-mengjie  阅读(11)  评论(0)    收藏  举报