面对Android单应用50条pending notifications限制，Flutter应用如何可靠调度数百条通知？

哥们儿，我太懂你这个痛点了！之前做一款老年医疗提醒App的时候，刚上线就遇到用户反馈“设置了100条服药提醒，结果只收到前40多条”的问题，排查了好久才发现是Android这个50条pending notifications的限制在搞鬼。下面给你分享我踩坑后总结的靠谱方案，都是行业里通用的路子，包括Google Calendar这类官方App的底层逻辑也差不多是这样：

一、核心思路：别一次性挂所有通知，用“按需调度+后台重排”模式 #

Android这个50条限制是针对已注册但未触发的PendingIntent的，所以根本没必要把未来几个月的所有通知都提前转换成PendingIntent挂着。正确的做法是只维护“近期即将触发”的一批通知，剩下的存在本地数据库里，靠后台任务定期补位。

二、Android端标准实现：WorkManager + 本地数据库 #

这是官方推荐的可靠方案，也是Google Calendar、主流医疗提醒App的核心逻辑：

• 本地存储所有任务：把用户的所有日程、提醒任务存在Flutter的本地数据库里（比如Isar、Hive或者sqflite），每条记录要包含触发时间、优先级、通知内容、是否已触发这些字段。
• 仅调度近期任务：每次启动App或者后台任务触发时，只把未来1-7天内（根据实际情况调整，比如留10条的冗余额度）的任务转换成PendingIntent挂到系统上，确保pending数量不超过40条左右，给系统留缓冲。
• WorkManager定期重排：用WorkManager创建一个周期性任务（比如每天凌晨2点），这个任务会：
  1. 清理已经触发过的过期PendingIntent，释放额度；
  2. 从数据库里拉取下一批即将触发的任务，转换成PendingIntent补上；
  3. 处理高优先级任务：如果有紧急的提醒（比如当天的服药通知），优先把这些任务排进去，普通日程往后靠。
• 处理系统重启：注册Android的BootCompleted广播，手机重启后立即触发WorkManager的重排任务——因为系统重启后所有PendingIntent都会失效，必须重新挂起近期的通知。

三、Flutter层面的优雅封装：用成熟插件简化开发 #

不用自己写太多原生代码，Flutter生态里的插件已经把这些逻辑封装得很好了：

• 通知调度用flutter_local_notifications：这个插件直接支持Android的AlarmManager和WorkManager集成，Dart层就能创建、清理PendingIntent，还能监听系统重启事件。
• 封装调度管理单例：写一个NotificationScheduler单例类，统一处理所有通知的增删改查：
  • 新增任务时，先存数据库，再检查当前pending数量，如果没到上限就直接调度；
  • App启动时自动触发一次调度检查，确保近期通知都已挂好；
  • 通知触发后，自动标记数据库里的任务为已触发，并清理对应的PendingIntent。
• 本地存储选Isar或Hive：这两个都是Flutter生态里性能出色的NoSQL数据库，支持按时间排序、快速查询，适合存储大量的提醒任务。

四、踩坑避坑指南 #

• 别迷信单一调度方式：AlarmManager适合精确的短期触发（比如未来1小时内的通知），WorkManager适合长期的周期性重排，两者结合用更可靠；
• 别加太严的WorkManager约束：比如不要设置setRequiresDeviceIdle(true)，否则任务可能被系统无限延迟，只需要设置基本的约束比如setRequiresBatteryNotLow(true)就行；
• 定期清理过期任务：很多人踩坑就是因为只加不删，导致PendingIntent数量很快堆满50条，一定要在每次重排时把已触发、已过期的任务对应的PendingIntent清理掉；
• 优先级优先：如果你的App有任务优先级区分，调度时先处理高优先级的，确保重要通知不会被普通任务挤掉。

五、开源参考例子 #

可以参考这些Flutter开源项目的实现逻辑：

• 医疗提醒类：开源版的Medication Reminder，用了Isar存储+WorkManager调度，代码里有完整的批量通知处理逻辑；
• 日程管理类：Open Calendar的Flutter分支，里面的通知模块展示了如何和Android系统服务交互，处理大量日程的调度问题。

内容来源于stack exchange