开发即时通讯APP时如何实现消息的定时提醒推送

做即时通讯开发这些年，我发现有个功能看起来简单，做起来却坑特别多——定时提醒推送。听起来不就是”设个时间，到点发个消息”吗？但当你真正上手做的时候，才会发现这里面的门道比想象的要复杂得多。今天就聊聊怎么在即时通讯APP里把这事儿做好，既能让用户收到提醒，又不会因为技术问题导致体验崩塌。

先说个事儿吧。去年有个朋友找我吐槽，说他开发的APP里用户设了个早上7点的提醒，结果有时候8点才收到，有时候干脆第二天才想起来。这种情况其实很常见，问题就出在定时推送的实现机制上。所以今天这篇文章，我想用比较直白的方式，把这里面的技术逻辑讲清楚，尽量让不管是用声网还是其他方案的开发都能用得上。

一、为什么定时提醒推送没那么简单

很多人觉得，定时提醒嘛，不就是在数据库里存个时间戳，等时间到了调个接口发出去吗？这话对了一半。定时提醒推送的难点不在于”定时”，而在于”推送”这两个字背后的一系列问题。

你想啊，用户设了晚上8点的提醒，这时候手机可能在用户手里，也可能躺在桌上没动。网络可能开着，也可能关着。APP可能在后台运行，也可能已经被系统杀掉了。这种情况下，你怎么保证消息能准确送到？光这个前提条件，就够你折腾好一阵子的。

另外还有一个容易被忽略的问题——时区。用户在北京设的早上7点提醒，到了上海还是早上7点吗？如果用户坐飞机出国了呢？这事儿要没处理好，用户的体验就会很糟糕。我见过有些APP直接用服务器时区存储，结果用户跨个时区就收不到正确的提醒了，这种bug特别隐蔽，测试都不一定能测出来。

二、定时提醒的核心技术逻辑

要理解定时提醒推送的实现方式，咱们得先搞清楚它的整个流程是怎么跑的。其实说起来也不复杂，一共就三个环节：时间触发、消息投递、到达确认。

时间触发是整个流程的起点。简单说，就是系统要知道”什么时候该发这个消息”。这里有两种主流的实现思路，一种是本地触发，另一种是服务器触发。本地触发就是靠手机自己的时钟来判断时间，时间到了就唤醒APP发消息。这种方式的好处是不依赖服务器，坏处是Android和iOS的后台管理策略越来越严，APP很可能被系统杀掉之后就收不到触发了。

服务器触发呢，就是把所有用户的定时提醒信息存在服务器上，服务器按时去检查哪些提醒该发了，然后通过长连接或者推送通道把消息发出去。这种方式更可靠，毕竟服务器不会”被杀后台”，但它依赖网络，而且服务器的并发处理能力是个需要考虑的问题——要是同一时刻有几十万个提醒要发，服务器扛得住吗？

现在很多成熟的即时通讯方案，比如声网提供的IM服务，会把这两者结合起来用。服务器负责统一管理时间和调度，本地端负责保活和兜底，这样既保证了可靠性，又不会太耗资源。这种混合模式基本上是目前的主流做法，单靠哪一种都有明显的短板。

时间触发机制的两种方案对比

三、推送通道的选择很关键

说完了时间触发，再来说说消息怎么送达到用户设备。这里就涉及到一个很现实的问题——APP在后台的时候，怎么把消息发出去？

在iOS上，这个问题的答案相对统一，就是走APNs（Apple Push Notification service）。苹果规定得很死，APP在后台的时候，普通的长连接基本是保不住的，只能通过APNs来推送通知。这是苹果的硬性要求，没得商量。开发者能做的，就是尽量优化通知的 payload 设计，让通知的内容更丰富、交互更灵活。

Android的情况就复杂多了。Google自己有个FCM推送服务，但在国内基本用不了。各家手机厂商都有自己的推送通道——华为的推送、小米的推送、OPPO的推送、vivo的推送等等。开发者如果想让自己的推送到达率高点，就得上架各大应用市场，接入他们的推送SDK。这事儿特别繁琐，但没办法，国内的生态就是这样的。

我见过有些团队为了省事，直接用轮询的方式——APP后台的时候每隔几分钟就去服务器问一下有没有消息。这种方式虽然能凑合用，但有几个致命问题：第一，电量消耗大，用户体验不好；第二，实时性差，万一服务器刚有了消息，用户得等几分钟才能收到；第三，有些系统的后台限制很严，轮询根本跑不起来。所以除非是极其轻量级的应用，否则不太建议用这种办法。

说到推送通道，有个点值得提一下。声网在IM服务里专门做了多通道适配的事情，他们把国内各大厂商的推送通道都集成好了，开发者不用一个一个去对接，这对中小团队来说确实能省不少事儿。当然如果你有时间有精力，自己去做通道对接也不是不行，就是比较费时费力。

四、本地通知和远程推送的区别要搞清楚

在实现定时提醒的时候，有个概念特别容易搞混，就是本地通知和远程推送的区别。这两个东西长得像，用起来完全是两码事。

本地通知是APP自己发给自己看的，不需要网络，也不需要服务器参与。比如你设了个早上7点的闹钟，这个通知就是APP在本地生成的，时间到了系统帮你弹出来。这种方式的好处是不依赖任何外部条件，断网也能工作。缺点是只能在APP内部生成，而且如果APP被系统杀掉了，有些系统的本地通知也会跟着消失。

远程推送则是服务器发给APP的，需要经过推送通道。比如服务器跟你说要发条消息，这条消息经过APNs或者厂商推送通道，最终到达你的手机。这种方式的好处是服务器可以主动触达用户，不管APP当时是什么状态。缺点是依赖推送通道的可用性，而且有各种长度和格式的限制。

那定时提醒应该用哪个呢？答案是两个都要用。一般来说，服务器推送负责触发和兜底，本地通知负责实时性和用户体验。具体怎么做呢？服务器到了时间点先发一条远程推送过来，APP收到之后立刻生成一条本地通知弹出去。这样既保证了可靠性，又能让通知的显示更灵活。

五、数据存储和状态管理的细节

定时提醒不是发出去就完事了，还得好好管理这些提醒的状态。什么时候发的、发了没有、用户有没有点开、过期了没有——这些状态都要记录清楚，不然用户会收到重复的通知，或者该收的时候收不到。

存储方案这块儿，通常需要两张表。一张是提醒任务表，存的是用户设置的提醒的原始信息：谁设置的、什么内容、什么时候发、重复周期是什么样的。另一张是发送记录表，记录的是每条提醒的实际发送情况：发了没有、什么时候发的、服务器返回了什么结果。

为什么分开存呢？因为用户的设置可能随时会改。比如用户本来设了每天早上8点提醒，后来改成每天9点了。如果你把发送记录和任务存在一起，修改起来就很麻烦。分开存的话，修改任务只需要更新任务表，发送记录保持不变，互不干扰。

还有一个要注意的是过期处理。很多APP的定时提醒是有过期时间的，比如一个会议提醒，会议结束后就不应该再发了。如果你的系统一直存着这些过期数据，一方面浪费存储空间，另一方面查询的时候也会变慢。最好建一个定时清理的任务，比如每天凌晨清理一下三天前已经过期的提醒记录，保持数据量的可控。

六、时区和夏令时的处理坑最多

前面提过时区的问题，这里展开说说。这玩意儿看起来简单，做起来处处是坑。

首先，存储的时候一定要用UTC时间，也就是世界标准时。不要用服务器本地时间，更不要用用户手机的本地时间。UTC时间全世界都一样，不会因为你换了个地方就变了。存储之后，在展示给用户看的时候，再根据用户当前所在的时区转换成当地时间。

然后是夏令时。这个在国内不太常见，但在欧美国家，每年春天和秋天都会调整一次时钟。夏令时的影响在于，同一个时区在不同的时间，偏移量是不一样的。比如纽约在夏令时的时候是UTC-4，冬令时的时候是UTC-5。如果你只存了时区名字”America/New_York”，系统自己会处理夏令时的转换；但如果你存的是具体的偏移量比如”-5″，那夏令时的时候就对不上了。

所以正确的做法是，存储时区信息的时候，用时区名称而不是偏移量。比如”America/New_York”而不是”-5″。然后在展示时间的时候，让系统自动根据当前时间和时区规则去计算当地时间。这样不管用户在哪里，也不管有没有夏令时，显示的时间都是对的。

七、性能和并发怎么扛住

假设你的APP有100万用户，其中10%的用户设置了定时提醒。如果这些提醒都集中在早上8点、晚上8点这种热门时间段，那服务器一下子就要处理10万条发送请求。这还只是一个场景，如果同时有几个热门时间段加起来，服务器的压力可想而知。

怎么解决这个问题呢？核心思路是削峰填谷。与其让所有请求集中在同一时刻爆发，不如让它们分散一点。

一个简单的办法是给每个提醒加一个随机延迟。比如用户设的是早上8点提醒，实际发送时间可以在8点前后浮动个5分钟。这样100万条提醒就不是同一时刻发出，而是分散在10分钟里慢慢发，服务器的压力就小多了。当然这个浮动范围要看具体场景，有些精确度要求高的提醒就不能这么干。

另一个办法是分层处理。把发送任务分成实时任务和延迟任务两类。实时任务必须按时完成，延迟任务可以稍微延后。比如早上8点提醒这种，8点正负1分钟内发出去就算成功；如果是晚上12点提醒的，这种延后几分钟用户也感觉不出来。服务器可以优先处理实时任务，延迟任务放到后台慢慢处理。

还有就是缓存的使用。快要到时间的提醒可以缓存在内存里，不用每次都去数据库查。查数据库可比读内存慢多了，这一层缓存能扛住很多并发压力。当然内存缓存要注意数据一致性的问题，别缓存了过期的数据。

八、测试覆盖要全面

定时提醒这个功能，测试的覆盖面一定要广。因为你永远不知道用户会在什么奇怪的情况下使用它。

基础的功能测试就是各种时间设置能不能正确保存、正确发送。往前设置行不行、往后设置行不行、跨年行不行、闰年行不行。重复提醒的逻辑对不对，每天、每周、每月各种周期对不对。这些是最基本的，就不多说了。

边界测试特别重要。手机断网的时候提醒还能不能发？APP被杀掉之后呢？手机关机重启之后呢？时区突然变化呢？这些极端情况虽然大部分用户遇不到，但一旦遇到就是影响体验的问题。测试团队最好能模拟各种网络状态、系统状态、地理位置变化的场景。

压力测试就是模拟高并发场景。比如同一时刻几万条提醒发出去，系统能不能扛住。发送失败了有没有重试机制，重试个几次能成功。这些数据对系统容量规划很有帮助，也能让你提前发现性能瓶颈。

还有一点容易被忽视——用户操作对提醒的影响。用户修改了提醒时间，旧的提醒还在不在？用户删除了这条消息，对应的提醒还发不发？用户卸载了APP，重新安装之后提醒还在不在？这些场景都要考虑到。

九、实际开发中的几点建议

说了这么多技术细节，最后给正在做这个功能的朋友几点实操建议。

• 能用SDK解决的就别自己造轮子。定时推送这事儿看似简单，其实背后要处理的一大堆边界情况。声网这类专业的即时通讯服务商早就把这些问题解决得差不多了，直接用他们的方案能省很多事儿。除非你有特别特殊的需求，否则真没必要自己从零开始写。
• 日志一定要打清楚。推送失败的时候，日志是排查问题的唯一依据。什么时候发的、发给谁了、服务器返回了什么、客户端收到没有——这些信息都要能查得到。最好把发送记录存到数据库里，而不是只存在日志文件里，方便查询和统计。
• 失败重试机制要做好。推送失败的情况很常见，网络抖动、推送通道维护、用户设备问题……一次发送失败不代表这条消息就不发了。最好设计一个指数退避的重试策略，比如第一次失败等1分钟再试，第二次失败等5分钟，第三次失败等30分钟，试个三四次还不行再放弃。这样既能提高成功率，又不会给服务器造成太大压力。
• 用户能感知到的失败要友好处理。如果一条提醒确实发失败了，在APP里最好能有个提示告诉用户。比如”您的提醒因网络问题未能及时发送”之类的。用户知道了原因就不会一脸懵，觉得是APP出bug了。

十、写在最后

定时提醒推送这个功能，说大不大说小不小。它不像消息收发那样是即时通讯的核心功能，但做不好的话真的挺影响用户体验的。很多用户吐槽”APP不好用”，往往就是因为这些细节没处理好。

技术实现上没有什么捷径，就是得把每个环节都考虑到：时间怎么存、触发怎么搞、通道怎么选、状态怎么管、并发怎么扛。每一个环节都有坑，踩过一个就记住一个，慢慢经验就积累起来了。

如果你正在开发这个功能，希望这篇文章能给你带来一些参考。有问题欢迎一起交流，做即时通讯这行，大家都是在不断踩坑中成长的。祝你开发顺利，用户体验棒棒的。