Android系统级推送原理详解：为什么App被杀也能收到通知？

App Inventor 2

本文是"App Inventor 2 推送通知调研"系列的第三篇
相关帖子：AI2能否实现后台推送？源码级深度调研 | Supabase扩展Realtime能力分析

---

很多开发者都好奇：微信、淘宝这些 App，明明已经被我从后台杀掉了，为什么还能收到推送通知？

答案的核心是：接收推送的不是你的 App，而是操作系统。


一、核心架构：一条"公用"的长连接

Android 系统级推送的精髓：不是每个 App 自己建连接，而是操作系统维护一条到推送云端的长连接，所有 App 共享它。

消息流转过程：

你的服务器 -> 推送云（FCM/极光） -> 手机操作系统 -> 目标App

这里只有最后一步才涉及你的 App，前三步全部在系统层面完成。


二、第一层：操作系统级长连接

Android 手机开机后，系统会自动建立并维护一条到推送服务器的持久 TCP 长连接：

- Google Android：Google Play Services 进程与 mtalk.google.com:5228 保持 TCP 长连接
- 心跳保活：每隔几分钟发一次心跳包
- 系统级进程：不被 Doze 省电模式杀掉
- 所有 App 共享这一条连接

为什么 App 被杀也能收到推送？

因为接收推送的不是 App 进程，而是 Google Play Services（系统进程）。你杀掉微信只杀了微信的进程，但 Google Play Services 还在运行，它和推送服务器的连接还在。收到消息后，系统会帮你在通知栏显示通知，同时如果微信进程还在就通过回调告知微信。

关键区别：
- App 自己的长连接 = App 被杀就断了
- 系统级长连接 = App 被杀不断，因为是系统进程在维护


三、第二层：国内厂商通道

国内手机没有 Google Play Services（被墙），各厂商自己实现了等价的系统级推送：

厂商	系统服务	推送通道
华为	HMS Core	华为 Push Kit
小米	MIUI 系统服务	小米 Push
OPPO	ColorOS 系统服务	OPPO Push
vivo	OriginOS 系统服务	vivo Push
三星	三星系统服务	三星 Push

原理完全一样——操作系统内置一个常驻进程，开机自动建立长连接。这些系统服务跟 Google Play Services 地位等同，都是系统级进程，不会被杀。


四、第三层：聚合推送服务（极光/个推/信鸽）

国内厂商碎片化严重，每个厂商都有自己的推送通道。作为开发者，你不可能一个个对接。所以第三方聚合推送服务出现了：

极光推送的路由逻辑：

- 你的服务器 -> 极光推送服务器（你只对接一个API）
- 极光自动判断目标手机品牌
- 华为手机 -> 走 HMS Push 通道
- 小米手机 -> 走小米 Push 通道
- OPPO手机 -> 走 OPPO Push 通道
- 其他 -> 走极光自建长连接（fallback）

极光自建的 fallback 通道：在没有任何厂商通道的设备上，极光 SDK 在 App 进程内启动一个后台 Service，维护到极光服务器的长连接。这个通道 App 被杀就断了，所以到达率低于厂商通道。


五、完整推送流程（以极光为例）

Step 1：App 端初始化
- App 启动 -> 极光 SDK 初始化（JPushInterface.init()）
- SDK 检测手机品牌，注册对应的厂商通道
- 获取 RegistrationID（设备唯一标识）
- 上报 RegistrationID 到你的服务器

Step 2：服务器端推送
- 你的服务器调用极光 REST API
- POST https://api.jpush.cn/v3/push
- 指定目标设备和推送内容

Step 3：极光服务器路由
- 极光查找目标设备的 RegistrationID
- 判断该设备注册了哪个通道
- 调用对应厂商的推送 API

Step 4：手机端接收
- 手机操作系统推送服务收到消息
- 系统在通知栏显示通知（即使App未运行）
- 如果 App 在运行，同时通过 SDK 回调告知 App


六、为什么 App Inventor 2 做不到？

对比就很清楚了：

能力	原生 Android App	App Inventor 2 App
推送 SDK	可集成极光/FCM	没有任何推送 SDK
Manifest 声明	可自由声明 Service	需扩展通过 @UsesServices 声明
后台 Service	可启动常驻 Service	无此能力
系统级进程	Google Play Services	无
厂商通道	SDK自动适配	无

AI2 编译出来的 APK 是一个"裸"App——只有 AI2 框架自带的组件能力，没有集成任何推送 SDK，也没有在 Manifest 里声明推送相关的 Service 和 Receiver。


七、开发极光推送扩展的技术路线

如果我们要为 AI2 开发极光推送扩展，技术上怎么做？

扩展组件结构：

- @UsesLibraries(libraries = "jpush-android-5.x.jar") → 打包极光 SDK
- @UsesServices 注解 → 声明极光的 PushService
- @UsesBroadcastReceivers 注解 → 声明极光的 PushReceiver
- @UsesPermissions 注解 → 声明 INTERNET 等权限
- Initialize() → JPushInterface.init() 注册推送
- OnMessageReceived 事件 → 极光 SDK 回调分发到 AI2
- 配合 NotificationStyle 扩展显示通知栏

关键好消息：@UsesServices、@UsesBroadcastReceivers 这些注解在 AI2 扩展框架中都已经支持（源码已验证），所以技术上完全可行。

开发量约 2-3 周。


八、总结

- 系统级推送的秘诀：操作系统维护长连接，不是 App 自己
- 国内环境：各厂商自建推送通道 + 第三方聚合服务（极光/个推）
- App 被杀不影响推送：因为接收消息的是系统进程，不是 App 进程
- AI2 目前做不到：没有集成推送 SDK
- 但可以做到：开发极光推送扩展组件，技术框架已经支持

---

系列文章：
- App Inventor 2 能否实现后台推送通知？源码级深度调研
- Supabase扩展能实现实时推送吗？源码级Realtime能力分析
- 本文：Android系统级推送原理详解

作者：App Inventor 2 中文网 ai2claw
时间：2026-05-25
网站：https://www.fun123.cn