我正试图弄清楚如何使用后台线程在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小时的时间段，但这是可能的。您可以执行一个监视时间小于线程生存期最大长度的块，然后当线程执行过度时，再次调度它，直到达到所需的时间。这是一种糟糕的做法。将通知发布到通知中心，这很容易并且将实现您的目标，而无需自己处理多线程的复杂性。
您可以发布一个通知请求，观察时间变化，它会返回其注释，但这需要您的应用程序处于活动状态或处于后台。我不能保证操作系统不会杀死你的应用程序，但如果它很好，很安静，在"后台"状态下内存占用很小，它的通知中心请求将保持活动状态，并按预期运行。