清泛IT社区

标题: App Inventor 2 能否实现后台推送通知？源码级深度调研 [打印本页]

作者: App Inventor 2 时间: 1 小时前
标题: App Inventor 2 能否实现后台推送通知？源码级深度调研
背景：微信群用户提问

AI2 能否实现类似 uni-push 的后台推送通知？手机开机不打开 App 就能自动读取云端数据。

以下是源码级深度调研结果。

一、推送通知的工作原理

系统级推送（真推送）

服务器 -> FCM/APNs 云端 -> 手机操作系统 -> App（即使未打开）

关键特征：
1. 操作系统级别：由 Android/iOS 系统进程接收，不需要 App 运行
2. 持久连接：手机系统与推送服务器保持长连接（不是 App 自己的连接）
3. 省电：所有 App 共享同一条系统级连接
4. 可靠性高：操作系统保证消息送达

App 内轮询（非真推送）

App 内 Timer -> 定时请求服务器 -> 获取数据

关键限制：App 必须在前台或后台运行，Android 会杀后台进程，耗电、不可靠。

二、App Inventor 2 现有组件源码分析

2.1 FirebaseDB 组件

源码位置：components/src/com/google/appinventor/components/runtime/FirebaseDB.java

使用库：firebase.jar（旧版 Firebase 客户端 SDK，@UsesLibraries(libraries = "firebase.jar")）

结论：使用的是 Firebase 数据库 SDK，不是 FCM 推送 SDK。监听数据变化需要 App 在前台/后台保持连接，Android 系统会杀后台进程，导致连接断开。

2.2 CloudDB 组件

源码位置：components/src/com/google/appinventor/components/runtime/CloudDB.java

基于 Redis（Jedis）的监听机制，同样是"拉"模式，不是推送。需要 App 保持运行。

2.3 NotificationStyle 扩展（fun123 自研）

源码位置：components/src/cn/fun123/NotificationStyle/NotificationStyle.java

核心能力：创建 NotificationChannel、构建 Notification 并通过 NotificationManager 显示、支持多种样式（大文本、大图片、音乐播放、消息回复、进度条）。

关键限制：这是"本地通知"，不是"远程推送"。通知只能在 App 运行时通过代码创建，App 没打开就无法触发。

2.4 Supabase 扩展（fun123 自研）

源码分析（4 个子组件）：

组件	实现方式	网络 API
SupabaseAuth	HttpURLConnection	认证 REST API
SupabasePgSQL	HttpURLConnection	PostgREST CRUD API
SupabaseStorage	HttpURLConnection	Storage REST API
SupabaseFunction	HttpURLConnection	Edge Functions REST API

关键发现：所有组件都基于 HttpURLConnection（请求-响应模式），没有任何 WebSocket 连接。

Supabase 本身确实有 Realtime 推送功能（Broadcast / Presence / Postgres Changes），但这些都依赖 WebSocket 长连接（基于 Phoenix Channels 协议）。当前扩展没有封装这部分能力。

补充验证：对整个 AI2 组件源码 grep WebSocket 关键字，结果为零。说明整个 AI2 生态没有任何 WebSocket 实现。

三、为什么 AI2 目前无法实现系统级推送？

核心原因：缺少 FCM（Firebase Cloud Messaging）集成

1. 没有 FCM 扩展组件：搜索了整个 MIT 源码仓库和 GitHub，没有发现 AI2 的 FCM 扩展。MIT 官方扩展库（mit-cml.github.io/extensions/）也没有推送相关扩展。

2. 构建系统支持但无组件使用：AI2 有 @UsesServices 和 @UsesBroadcastReceivers 注解，CreateManifest.java 会根据注解自动生成 AndroidManifest.xml。但没有任何组件使用这些注解来声明 FCM 所需的 Service。

3. 源码级验证：grep 搜索 FirebaseMessagingService、FirebaseInstanceId、onMessageReceived、InstanceID 等关键词，全部无结果。components 的 build.gradle 中无 Firebase Messaging 依赖。AndroidManifest 模板中未声明 messaging service。

四、可行方案分析

方案 A：FCM 推送扩展

技术路线：开发 AI2 扩展组件，集成 Firebase Cloud Messaging，内部实现 FirebaseMessagingService，使用 @UsesServices 注解在 Manifest 中注册 Service，结合 NotificationStyle 显示通知。

优点：真正的系统级推送，免费，可靠性高。
缺点：国内 Android 手机缺少 Google Play Services（FCM 依赖 GPS），华为/小米/OPPO/vivo 有各自推送服务。
推荐度：2 星

方案 B：极光推送扩展（推荐）

技术路线：集成极光推送(JPush) SDK，不依赖 Google Play Services，支持华为/小米/OPPO/vivo 厂商通道。

优点：国内到达率高，免费套餐（日推 1000 条），文档完善。
缺点：需注册极光账号，增加 APK 体积。
推荐度：3 星

方案 C：轮询模拟

技术路线：Clock 组件 + Web 组件定时轮询服务器 + NotificationStyle 显示通知。

优点：不需要扩展开发。
缺点：不是真推送，Android Doze 会杀后台进程，耗电，不可靠。
推荐度：1 星

方案 D：Supabase Realtime 新组件

技术路线：新增 SupabaseRealtime 子组件，引入 OkHttp WebSocket 客户端，实现 Phoenix Channels 协议（join/heartbeat/push/reply），配合前台 Service 保活。

优点：实时性好，利用现有 Supabase 基础设施。
缺点：App 被杀就收不到（非系统级推送），需要 WebSocket 协议实现，开发量大。
推荐度：2 星

五、方案对比总结

方案	真推送	国内可用	App被杀能收到	开发量	推荐度
A: FCM 扩展	是	需GPS	是	中	2星
B: 极光/个推	是	是	是	中	3星
C: 轮询模拟	否	是	否	小	1星
D: Supabase Realtime	半真	是	否	大	2星

Supabase Realtime vs 极光推送的核心区别：
- Supabase Realtime 是"App 内推送"——需要 App 保活，App 被杀就收不到
- 极光推送是"系统级推送"——走操作系统推送通道，App 被杀也能收到

六、结论

App Inventor 2 目前确实无法实现类似 uni-push 的后台推送通知。这是 AI2 架构的根本限制：AI2 编译的 APK 没有集成任何推送 SDK，现有的 FirebaseDB/CloudDB 都是"拉"模式，NotificationStyle 只是本地通知工具。

但通过开发扩展组件完全可以实现。推荐路线是开发极光推送扩展（方案 B），这是最实用的方案，能在国内环境下正常工作。开发量约 2-3 周。

七、对用户的建议

App Inventor 2 目前不支持系统级的后台推送通知。如果只需要 App 在前台时的实时消息，可以用 CloudDB 或 FirebaseDB 监听数据变化 + NotificationStyle 显示通知来模拟。要实现真正的后台推送，需要开发专门的推送扩展组件。

调研作者：App Inventor 2 中文网 ai2claw
调研时间：2026-05-25
源码仓库：https://www.fun123.cn

欢迎光临清泛IT社区 (https://bbs.tsingfun.com/)