我试图弄清楚如何使用后台线程每 4 小时执行一次命令。
我以前从来没有创造过这样的东西，所以到目前为止只读过它。我读过的一件事是这个
“线程占用物理内存和关键系统资源”
所以在那种情况下，让这个线程检查时间然后执行我的方法会是一个坏主意......还是有更好的选择，我已经阅读了 GCD（Grand Central Dispatch），但我不确定这是否是适用，因为我认为它更适用于并发请求？不是一遍又一遍地检查时间的东西..
或者最后有没有我完全错过的东西，你可以每 4 小时执行一次请求？
任何帮助将不胜感激。
允许后台进程运行的最长时间（10 分钟）会使您的方法变得困难。您的下一个最佳尝试是计算下一个事件，将时间戳保存在某处。然后，如果应用程序在该事件时或之后执行，它可以执行您想要的任何操作。
这可能会有所帮助： http ://www.audacious-software.com/2011/01/ios-background-processing-limits/
我认为最好利用时间戳并在时间从现在开始几个小时后发布通知。
多线程不是一个很好的方法来做到这一点，因为基本上你会运行一个循环四个小时吃时钟周期。多亏了操作系统的魔力，这不会吃掉整个核心或任何类似的愚蠢的东西，但是如果允许它运行，它将被连续计算。这将是对资源的巨大浪费，因此是不允许的。GCD 并不是真的适合这种事情。它的目的是允许并发来平滑 UI 交互以及更有效地完成任务，一个 4 小时的循环将是低效的。将并发视为一种工具，用于在加载或更改内容时与表格进行交互。GCD 块在正确使用时使这非常容易。GCD 和其他多线程能力提供了在后台进行计算以及与数据库交互和处理请求的工具，而不会影响用户体验。许多比我聪明得多的人都写了大量关于多线程/多任务是什么以及它有什么好处的文章。在某种程度上发布消息一段时间将是多任务处理的方法，而无需通过 GCD 不断执行块以等待 4 小时的时间段，但是可以这样做。您可以执行一个块，该块监视的时间少于线程生命周期的最大长度，然后当线程执行过度时再次分派它，直到达到所需的时间。这是一种不好的做法。向通知中心发布通知，
您可以发布通知请求以观察时间变化，它会返回其注释，但这需要您的应用程序处于活动状态或在后台。我不能保证操作系统不会杀死您的应用程序，但是如果它在“后台”状态下运行良好且安静且内存占用很小，则其通知中心请求将保持活动状态并按预期运行。