iOS UI 线程/后台或后台到后台线程通信

Question

我有一个基于 map 的程序，当用户与屏幕上的元素交互时，应用程序会查询数据库并根据用户选择的内容添加注释。为防止整个 map UI 锁定，我已将此查询和注释代码放在后台线程中。它运行良好。

现在的问题是，如果用户点击界面上的另一个元素，在后台线程完成之前启动一个新线程来做同样的事情。这本身并不是问题，但在较慢的设备(旧的 iPod 和 iphone 3gs 等)上，第二个线程可能会在第一个线程之前完成，因此用户会短暂地获得与上次交互相关的 View , 但如果第一次交互需要很长时间来处理..(经典赛车条件)，则会显示第一个的结果。

所以，我想做的是进行第二次交互，通知任何已经在运行的后台线程，嘿，你基本上可以退出你现在正在做的事情并结束。我该怎么做呢？

Answer 1

使用 GCD 调度队列。它自动提供 FIFO 排序和 block 。虽然您无法取消已在运行的请求，但您可以阻止其他请求运行。

因为你没有说你在使用 CoreData，而且你已经在使用一个单独的线程，我假设你没有使用 CoreData 作为你的“数据库”。

尝试一些简单的事情，比如...

在你的类初始化时创建你的队列(或者应用程序启动，如果它总是应该在那里)......

dispatch_queue_t workQ = dispatch_queue_create("label for your queue", 0);

并在你的类解除分配(或其他适当的时间)时释放它......

dispatch_release(workQ);

要获得类似的取消，如果已经做出另一个选择，您可以做一些简单的事情，比如使用 token 来查看您正在处理的请求是否是“最新的”，或者此后是否有另一个请求出现。 ..

static unsigned theWorkToken;
unsigned currentWorkToken = ++theWorkToken;
dispatch_async(workQ, ^{
    // Check the current work token at each step, to see if we should abort...
    if (currentWorkToken != theWorkToken) return;
    MyData *data = queryTheDatabaseForData(someQueryCriteria);

    if (currentWorkToken != theWorkToken) return;
    [data doTimeConsumingProcessing];

    for (Foo *foo in [data foo]) {
        if (currentWorkToken != theWorkToken) return;
        // Process some foo object
    }

    // Now, when ready to interact with the UI...
    if (currentWorkToken != theWorkToken) return;
    dispatch_async(dispatch_get_main_queue(), ^{
        // Now you are running in the main thread... do anything you want with the GUI.
    });
});

该 block 将“捕获”堆栈变量“currentWorkToken”及其当前值。请注意，解锁检查在这里很好，因为您不需要跟踪连续计数，只要它在您设置后发生了变化即可。在最坏的情况下，您将执行额外的步骤。

如果您正在使用 CoreData，您可以使用 NSPrivateQueueConcurrencyType 创建您的 MOC，现在您根本不需要创建工作队列，因为私有(private) MOC 有自己的...

static unsigned theWorkToken;
unsigned currentWorkToken = ++theWorkToken;
[managedObjectContext performBlock:^{
    // Check the current work token at each step, to see if we should abort...
    if (currentWorkToken != theWorkToken) return;
    MyData *data = queryTheDatabaseForData(someQueryCriteria);

    if (currentWorkToken != theWorkToken) return;
    [data doTimeConsumingProcessing];

    for (Foo *foo in [data foo]) {
        if (currentWorkToken != theWorkToken) return;
        // Process some foo object
    }

    // Now, when ready to interact with the UI...
    if (currentWorkToken != theWorkToken) return;
    dispatch_async(dispatch_get_main_queue(), ^{
        // Now you are running in the main thread... do anything you want with the GUI.
    });
}];

GCD/Blocks 确实是这类东西的首选方法。

编辑

为什么它是首选？好吧，首先，使用 block 可以使您的代码保持本地化，而不是分散到另一个类 (NSOperation) 的其他方法中。还有很多其他原因，但我将个人原因放在一边，因为我不是在谈论我的个人喜好。我说的是 Apple 的。

周末坐下来观看所有 WWDC 2011 视频。来吧，这真的是一场爆炸。我的意思是真诚的。如果你在美国，你将迎来一个漫长的周末。我敢打赌你想不出更好的事情去做......

无论如何，观看这些视频，看看您是否可以数出不同的演示者说他们强烈推荐使用 GCD...和 block ...(以及 Instruments 作为另一边)的次数。

现在，随着 WWDC 2012，这一切可能很快就会改变，但我对此表示怀疑。

具体来说，在这种情况下，它也是比 NSOperation 更好的解决方案。是的，您可以取消尚未启动的 NSOperation。哎呀。 NSOperation 仍然没有提供自动取消已经开始执行的操作的方法。您必须继续检查 isCanceled，并在提出取消请求时中止。因此，所有那些 if (currentToken != theWorkToken) 仍然必须像 ([self isCancelled]) 一样存在。是的，后者更容易阅读，但您还必须明确取消未完成的操作。

对我来说，GCD/blocks 解决方案更容易遵循，是本地化的，并且(如所呈现的那样)具有隐式取消语义。 NSOperation 的唯一优点是，如果排队的操作在开始前被取消，它会自动阻止排队的操作运行。但是，您仍然必须提供自己的取消运行操作功能，所以我认为 NSOperation 没有任何好处。

NSOperation 有它的一席之地，我可以立即想到几个我更喜欢它而不是直接 GDC 的地方，但对于大多数情况，尤其是在这种情况下，它是不合适的。