Xamarin Forms+SQL Server如何实现定时提醒及全员推送通知功能

首先明确技术选型边界：FCM完全可以覆盖你的两类推送需求，你之前了解的"FCM仅支持手动向全量用户发送通知"是FCM控制台的操作限制，通过服务端SDK可以实现全自动化的单发、群发逻辑；SignalR/WebSocket仅适合应用前台在线场景，无法替代系统级推送通道实现离线送达。

前置准备 #

• 改造用户数据表：新增设备推送Token关联表，用户首次启动应用完成注册/登录后，将设备获取到的FCM推送Token上传到后端存储，支持同一用户绑定多台设备的Token，标记Token的生效状态
• 后端集成FCM Admin SDK，所有推送触发逻辑全部在后端代码中实现，不需要登录FCM控制台手动操作
• Xamarin端引入对应FCM组件，完成两端推送权限申请、通知接收、点击跳转的基础逻辑：iOS端完成APNs证书与FCM的关联配置，安卓13及以上版本主动申请POST_NOTIFICATIONS运行时权限

两类核心需求实现 #

1. 单用户定时提醒 #

不要用服务进程内内存定时器实现定时逻辑，避免服务重启、实例扩容导致任务丢失，依托AWS托管服务实现高可靠定时触发：

• 当用户向Event表插入事件数据时，同步计算提醒触发时间（date_event往前推10分钟），将待提醒任务写入独立的定时任务表，关联对应事件ID、目标用户ID，标记任务状态为「待执行」
• 配置AWS EventBridge规则，以1分钟为周期触发执行逻辑（可以直接触发Lambda函数，也可以调用你后端的任务扫描接口），扫描任务表中触发时间早于当前时间、状态为「待执行」的任务记录
• 拿到待执行任务后，关联查询目标用户绑定的所有有效设备Token，调用FCM多设备发送接口推送提醒内容
• 推送完成后将对应任务状态更新为「已执行」，如果推送失败则累计失败次数，配置最多3次的重试规则，避免重复推送
• 如果用户后续修改了事件时间，同步更新对应待执行任务的触发时间即可，逻辑调整灵活

2. 全员广播通知 #

不要每次发广播都遍历全量用户Token循环调用发送接口，借助FCM主题订阅能力实现高效群发：

• 所有用户的设备端完成FCM初始化后，自动订阅固定全局主题（例如global_broadcast）
• 当后端确认用户文件上传完成后，直接调用FCM Admin SDK的主题发送接口，指定发送目标为global_broadcast主题，推送内容为「TestUser uploaded new files」即可，FCM会自动完成全量订阅设备的消息投递，不需要你自行遍历用户列表
• 用户卸载应用、Token失效后，FCM会自动清理对应订阅关系，不需要你手动维护列表减少脏数据
• 后续如果需要按用户分组发定向广播，只要让对应组用户订阅专属主题即可，扩展成本极低

SignalR/WebSocket适配场景说明 #

这类长连接技术仅适合应用处于前台活跃状态时的实时消息场景：

• 优势是延迟低、不需要走系统推送通道，适合做应用内即时聊天、实时状态同步这类高频交互
• 缺陷是应用退到后台后，长连接会被系统挂起、强制断开，无法保证消息送达，完全不能替代系统推送做离线提醒
• 最优实践是两者结合：用户在线打开应用时走SignalR通道收消息，降低延迟、减少推送通道的配额消耗；用户离线时走FCM通道推送通知唤醒用户，保证送达率。你的两类需求都要求用户无论是否打开应用都能收到通知，核心逻辑必须以FCM实现为主，SignalR仅作为前台场景的体验优化补充。

常见避坑点 #

• iOS端务必区分沙箱/生产环境的APNs证书，证书配置错误会导致FCM转发到APNs的消息全部投递失败
• 如果应用需要在国内安卓应用商店上架，FCM在国内大部分机型无法正常工作，需要替换为国内厂商统一推送服务，海外发行版本保留FCM即可
• 定时任务不需要追求秒级精度，1分钟的扫描粒度完全满足提前10分钟提醒的需求，过高的扫描频率只会浪费数据库资源
• 推送payload中不要携带敏感信息，通知通道为公网传输，敏感数据等用户点击通知打开应用后，再通过已鉴权的REST接口拉取即可

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