清泛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
SupabaseAuthHttpURLConnection认证 REST API
SupabasePgSQLHttpURLConnectionPostgREST CRUD API
SupabaseStorageHttpURLConnectionStorage REST API
SupabaseFunctionHttpURLConnectionEdge 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 扩展需GPS2星
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/) Powered by Discuz! X3.3