移动端推送服务：FCM、APNs 与厂商通道

# 移动端推送服务完全指南：FCM、APNs 与厂商通道

## 1. 移动推送基础

### 为什么需要推送服务？
移动推送是应用在后台或未启动时，向用户下发消息的核心能力。它能显著提升用户留存与活跃度，避免应用常驻后台带来的电量消耗。相比轮询，推送由服务端主动发起，实时且省电。

### 推送服务架构概览
典型的推送链路包含：
- **开发者服务器**：生成并下发推送请求。
- **推送服务商**：负责将消息路由至目标设备。
- **系统级长连接**：设备与推送服务保持的长时连接。
- **客户端 SDK**：接收并展示推送。

不同平台依赖的服务商不同：
- **Android**：Firebase Cloud Messaging（FCM）以及各手机厂商通道。
- **iOS**：Apple Push Notification service（APNs），唯一通道。

---

## 2. Firebase Cloud Messaging（FCM）

### FCM 是什么？
FCM 是 Google 提供的免费跨平台消息解决方案，继承自 GCM。它支持 Android、iOS、Web 等平台，是 Android 生态最通用的推送服务。

### FCM 工作原理
1. 客户端通过 FCM SDK 注册，获得一个唯一的 **推送令牌**。
2. 客户端将令牌发送到开发者服务器存储。
3. 服务器使用 FCM 服务端 API，携带令牌和消息内容向 FCM 发起请求。
4. FCM 通过设备的长连接将消息送达客户端。
5. 客户端系统唤醒应用（或通过通知栏）展示内容。

FCM 支持两种消息类型：
- **通知消息**：由系统自动处理，直接显示在通知栏。
- **数据消息**：由客户端应用处理，可自定义行为。

### FCM 接入流程简介
1. 在 Firebase 控制台创建项目，获取 `google-services.json`。
2. 集成 FCM SDK 到应用中。
3. 在应用启动时请求推送权限（Android 13+需动态请求通知权限）。
4. 获取 FCM 令牌并上报至业务服务器。
5. 服务端使用 Firebase Admin SDK 或 HTTP API 发送推送。

### 优点与限制
**优点**：
- 完全免费，无推送量限制。
- Android 系统级支持，在原生 Android 设备及有 GMS 服务的机型上送达率高。
- 统一处理令牌刷新，开发便捷。

**限制**：
- 设备必须安装 Google Play 服务，国内大部分手机默认不带 GMS，导致 **FCM 不可用**。
- 即使有 GMS，在国内网络环境下连接可能不稳定，送达率大幅降低。

---

## 3. Apple Push Notification service（APNs）

### APNs 概述
APNs 是苹果为 iOS、macOS、watchOS 等设备提供的唯一官方远程推送服务。所有 iOS 应用的推送都必须经过 APNs，不允许使用第三方长连接。

### 基于 Token 和证书的认证
APNs 提供两种服务端认证方式：
- **基于 Token（推荐）**：使用 Apple 开发者账号生成的 P8 密钥，设置 `Key ID` 和 `Team ID`，服务器生成 JWT 进行请求。优势是不受证书过期影响，管理简单。
- **基于证书**：上传推送证书（.p12），每年需更新。

### 推送流程
1. App 启动后调用 `registerForRemoteNotifications` 注册。
2. 系统提示用户授权通知权限。若获取到 Device Token，回调 `didRegisterForRemoteNotificationsWithDeviceToken`。
3. 应用将 Device Token 发送至业务服务器。
4. 业务服务器通过 HTTP/2 接口将推送内容发至 `api.push.apple.com`。
5. APNs 将消息下发给指定设备。

### 注意事项
- 必须使用 HTTP/2 协议，TLS 1.2 以上。
- Device Token 可能会变化（系统重装、恢复备份等），需及时更新。
- APNs 对推送速率有限制，突发大量推送需要做并发控制。
- 通知样式完全由 iOS 系统决定，应用可通过 **通知服务扩展** 实现图片、视频等富媒体推送。

---

## 4. 安卓厂商通道

### 为什么需要厂商通道？
国内市场无 GMS 覆盖，FCM 基本失效。而国内主流手机厂商（华为、小米、OPPO、vivo 等）各自构建了系统级推送服务。这些服务预置在系统中，长连接由系统维护，**可在应用被杀死后仍收到推送**，是提升国内安卓送达率的关键。

### 主流厂商通道
| 厂商 | 推送服务名称 | 特点 |
|------|------------|------|
| 华为 | HUAWEI Push Kit | 覆盖华为/荣耀设备，支持基于 Token 的推送，服务端 API 稳定。 |
| 小米 | Mi Push | 小米/Redmi 系统级，需注册应用获取 AppId/AppKey。 |
| OPPO | OPPO PUSH | OPPO/OnePlus/realme 设备，支持私信和公信。 |
| vivo | vivo Push | 主要覆盖 vivo 设备，有严格的消息分级要求（系统消息/运营消息）。 |
| 魅族 | Meizu Push | 覆盖较少，一般接入主要平台即可。 |

### 厂商通道统一接入方案
逐一集成每个厂商 SDK 工作量巨大且维护困难。推荐采用以下方式之一：
- **使用统一推送平台**：如极光推送、个推、腾讯云推送、阿里云移动推送等。它们已封装多家厂商通道，只需对接一个 SDK 和一套服务端 API，自动完成通道选择和令牌管理。
- **自建聚合层**：在业务侧抽象推送通道，根据设备品牌分发对应厂商 SDK。通过配置下发策略，灵活切换。

### 使用厂商通道的最佳实践
- **按设备品牌分发**：在客户端启动时获取品牌信息，只注册本设备的厂商通道，避免无关初始化。
- **令牌统一管理**：所有通道获取的 Token 与设备 ID 绑定，上报到后台。后台根据目标设备的品牌选择相应通道下发。
- **处理权限与通知分类**：各厂商对自分类、通知渠道做了不同规范（如 vivo 的“运营消息”和“系统消息”）。务必遵守，否则消息可能被降级或不展示。
- **结合 FCM 作为补充**：在海外用户设备或特殊网络下，可保留 FCM 作为兜底通道。

---

## 5. 跨平台推送方案对比与选择

### Android 推送通道选择策略
理想的 Android 推送方案是**厂商通道 > FCM > 应用内长连接**。
- 国内优先厂商通道，根据设备品牌选择对应通道。
- 国外优先 FCM，同时也可接入厂商通道覆盖少量品牌。
- 非主流品牌或系统无厂商通道时，尝试 FCM；若 FCM 也不通，可降级为应用自建长连接（高频轮询需谨慎，耗电且可能被系统限制）。

### iOS 推送唯一性
iOS 仅 APNs 一条通道，不存在厂商变量。但可以通过 **VoIP 推送** 实现高优先级推送（需 CallKit 配合，审核严格）。富媒体使用 Notification Service Extension 实现。

### 统一推送平台（如极光、个推）
对中小企业，直接选用成熟第三方推送平台是最快方案。它们提供：
- 一套 SDK 覆盖 Android 各大厂商和 FCM、iOS APNs。
- 在线推送 API，支持标签、别名、分组等高级功能。
- 数据分析与 A/B 测试能力。

选择时关注厂商覆盖度、送达率 SLA、文档质量以及数据隐私合规（GDPR、个保法）。

---

## 6. 推送优化与常见问题

### 送达率、点击率优化
- **精准分组与个性化**：按用户兴趣、地理位置发送相关推送，避免全体广播。
- **消息时效性**：设置合理的过期时间（TTL），过期消息不再下发，减少骚扰。
- **频率控制**：允许用户自定义接收类型和时段，避免夜间推送。
- **富媒体与交互**：使用图片、视频、快捷回复按钮提升点击欲望。
- **点击后落地页**：确保推送直达应用内具体内容，提升体验一致性。

### 避免滥用推送
滥用推送导致用户关闭权限甚至卸载。遵循以下准则：
- **提供明确的价值**：通知对用户有帮助，如状态更新、重要提醒。
- **可预期的频率**：不要突增推送量，提供偏好设置。
- **静默推送（数据推送）**：用于静默触发后台任务，不打扰用户。

### 隐私权限与合规
- Android 13 引入 `POST_NOTIFICATIONS` 运行时权限，需动态申请。
- iOS 首次启动即弹授权框，建议先解释再申请。
- 遵守《个人信息保护法》，收集与使用推送令牌需显式告知用户，不得用于追踪。
- 存储用户推送令牌的服务器必须做好安全防护，避免泄露。

---

## 结语
移动端推送是连接用户与服务的桥梁，但平台差异显著。理解 FCM、APNs 的技术原理和厂商通道的投入必要性，才能设计出高可达、低骚扰的推送体系。建议初学者从统一推送平台入手，快速验证业务，再根据数据与成本逐步优化自建策略。优质推送的本质是“在对的时间，用对的方式，告诉用户对的事”。