我本身是搞 Andorid 开发的，现在想要将应用移植到苹果端，碰见了这个问题，希望各位 iOS 大佬可以指教一下~！

我自己初步调研了一下，iOS 上好像要配置一个backgroundMode
目前好像只有设置为Audio的模式，可以一直在后台循环播放一个静音的音频，但是这种方案不清楚是否可以上架
其它的模式貌似在后台运行都有一定的时间限制，不太符合我需要一直重复运行这个番茄中的需求

番茄钟为啥要后台持续运行？
如果是计时可以用本地推送

因为不仅仅是番茄钟，还有其他不同类型的倒计时器，比如我的应用可以实现 100 个不同时间的倒计时同时运行，且必须在倒计时器结束的时候给用户发送通知，而且要求时间准确（因为有的会精确到毫秒），不能有任何延迟的。本地推送的话，貌似推送的时间不保证准确性吧？

本地推送精确到秒，你的需求提前计算好发送时间生成对应的本地推送即可。

……真有人需要 100 个倒计时么……
本地推送上限是 64 个吧，我觉得正常情况下够用了。
持续在后台跑着计时这种方案太浪费资源了，没必要。记录下结束时间，和本地时间对比一下显示出来就完事。精确到毫秒对于人类来说有些超纲。

好奇什么样的需求要精确到毫秒，通知时间相差 100ms 用户能感知到差距吗

其实应该是 10ms ，是有一个搞运动的要求的，我自己本身也觉的这种精度貌似没必要，但是有用户有这个需求，我就做了，如果 iOS 做不到的话，其实隐藏这个功能就好了

没办法，需要做各种个性化的提醒，所以必须在后台运行，比如每隔几秒中需要播放一个音频文件提醒一下这样的需求，如果仅仅是在计时器结束的时候发送一个通知的花，也没必要使用我们软件了，直接用手机系统自带的计时器更好用还节省资源呢

没有人需要 10ms 精度的提醒，CS 职业选手架枪的反应时间都 100-200ms 了。

就算你完全后台运行，给你 0 延迟弹提醒，手机弹出提醒框都 500ms 过去了。
建议梳理下真正的需求

另外眨眼都要 200ms ，闹麻了

按照你这么说，那些秒表什么的就不需要了。

我们软件的需求都是真实用户反馈的。不是我们自己在脑海里面冥思苦想的假需求。比如这个毫秒级别，其实无论是 10 毫秒还是 100 毫秒，这个都是真实存在的，尤其是我们的运动方面的用户，都反馈过这个需求。至于你说的眨眼 200 毫秒的问题，在给运动员测量每一次跑步或者每一次有用的时间，是允许测量的人眨眼的，且不会影响测量结果。

你功能可以精确到毫秒，但是提醒是不需要精确到毫秒的

举个例子，现在假如你能在后台发送提醒，并且没有延迟。
你觉得发出的这个通知提醒，从 iPhone 亮屏（或从屏幕上面弹出），到用户眼睛看到，读取，再到大脑处理，过去了多少毫秒呢？ 这个场景去扣 10ms 的精度有意义么

虽然我没测试过，但本地通知的触发定时用的是 TimeInterval ，本质是 Double, 传小数应该是支持毫秒。
不管有没有用吧，给你说一下

非高刷屏
最常见刷新率 60ms
显示器刷新间隔就得 1000/60 = 16.6ms
你的 10ms 延迟已经突破物理极限了

精度是由倒计时器的具体算法实现的，提醒只是在时间结束时候触发

楼主直接刚客户就可以了，什么需求需要精确到 10ms,真有这个需求让客户直接用实时操作系统，现在的所有通用操作系统都不能保证 10ms 必须响应，也就是说通知想精确到 10ms 在操作系统层面无论是安卓还是苹果的内核调度系统都无法实现，直接硬刚客户，不同需求就不要提。

如果是回到后台，手机没有任何 UI 的显示，那可以在进入后台的时候生成一个时间戳，然后再进入前台的时候在生成时间戳，两者得到差值，更新 UI 显示

如果是回到后台，手机有 UI 的显示，比如有悬浮框，你可以用到 backgroundMode 的东西，RunLoop.main.add(timer, forMode: .common)，进行操作

希望能够帮助到你

感谢

感谢~

其实不是要用到后台计时，是用到闹钟，Android 上面用闹钟就可实现，iOS 同理

开启灵动岛实时活动就可以了，显示的时候 Text(startDate, style: .timer)

昨天在推特上刷到了一个视频，他做了一个 demo 完全是你说的这个需求，切到后台再切回来时间不会被中断，找了下没有再找到这条推。

精确那么多没有必要。联网的话好解决，比如加个长链接，通过心跳发送服务器时间。在应用 resume 的时候通过长链接或者 http 请求当前时间，就可以计算出来期间过去多久了。