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