flutter_local_notifications与awesome_notifications功能差异对比

早期版本的awesome_notifications曾内置远程推送功能，无需额外依赖firebase_messaging即可实现推送通知能力，但由于该实现和firebase_messaging共同使用时存在严重的兼容冲突，后续插件作者已经完全移除了内置的远程推送模块，目前两款插件的核心定位都是本地通知场景的实现方案。

awesome_notifications 对比 flutter_local_notifications 的独有特性 #

• 更完善的原生交互支持：无需编写大量平台端桥接代码，即可实现通知内嵌快捷按钮、快捷输入框等交互组件，用户在通知栏的按钮点击、文本输入操作可以直接触发Flutter层的业务回调，支持的交互组件类型远多于flutter_local_notifications
• 全链路通知生命周期监听：提供统一的回调入口覆盖通知创建、送达、展示、点击、滑动清除、取消的全流程事件，不需要分别在Android、iOS端单独配置原生生命周期监听，可直接基于回调做通知行为埋点、业务逻辑触发
• 开箱即用的丰富通知样式：原生支持大图文通知、进度条通知、分组折叠通知、自定义铃声通知、全屏强提醒通知（闹钟、来电类场景）等样式，针对Android 13+、iOS 16+的系统新通知特性适配速度更快，不需要额外编写原生适配代码
• 内置权限与渠道管理能力：无需额外接入权限类插件，即可完成全系统版本的通知权限申请、权限状态查询、跳转系统通知设置页操作，同时支持对Android端通知渠道、通知优先级的统一配置管理
• 厂商系统适配更完善：针对国内定制Android系统的后台省电策略、应用杀进程场景做了专门的调度保活适配，定时通知、预约通知的触发准确率明显高于flutter_local_notifications，能减少应用被后台清理后通知不触发的问题

选型参考 #

• 仅需要基础的本地通知展示、简单定时通知能力，追求插件轻量、依赖少、社区资料充足的场景，优先选择flutter_local_notifications
• 需要实现复杂通知交互、强提醒类通知（待办闹钟、来电提醒）、对通知触发准确率要求高、需要统计通知全链路用户行为的场景，优先选择awesome_notifications，可以节省大量跨端适配的工作量
• 已经接入firebase_messaging实现远程推送的项目，两款插件都可以正常搭配使用，当前新版本的awesome_notifications已经修复了早期版本的推送兼容冲突问题，只需要做好远程消息接收后转本地通知展示的逻辑对接即可

内容的提问来源于stack exchange，提问作者Konstantin Kozirev