ios - 关于使用完成 block 排队

Question

所以，在前一段时间了解完成 block 之后，我非常喜欢使用完成 block 。我喜欢关闭，我喜欢将任何东西传递到任何我想要的地方的能力。

作为线程编程的新手，我一直远离 GCD 和 NSOperation——但最近我不得不编写异步更新到核心数据的东西，我开始怀疑我的“所有完成 block ”始终”的方法。

所以这里有一个我正在质疑自己的例子:我有一系列可能相当大的数据(图像、声音、视频，你有什么)要上传到某处的服务器。这些数据的元数据存储在 Core Data 中，我有一个时间戳，用于决定应上传哪些对象。所有这些上传都应该按顺序完成。

我编写的代码基本上只是一个带有完成 block 的函数，在 block 的末尾有一个对自身的调用，如下所示:

(void)uploadAllAsynchronously {
  ... // First figure out what to upload based on core data
  // Here comes the completion block in question
  void(^blk)(BOOL) = ^(BOOL)uploadSuccess {
    ... // if upload successful, update core data to mark what has been uploaded
    [self uploadAllAsynchronously]; // Recursively calls the function that contains this block.  I actually have a weak self, or if that fails to break a retain cycle, I should be able to pass in a NSManagedObjectContext as an argument.
  }
  [NSURLConnection sendAsynchronousRequest:... queue:... completionHandler:blk];


}

这应该行得通，对吧？这里有什么完全危险的东西建议我必须使用 GCD 并处理我自己的队列吗？我问这个是因为我现在遇到了一些麻烦，可能其中的数据会出现不同的线程由于异步调用而无法正确更新，但不确定我的代码的哪一部分是罪魁祸首。

提前致谢。

Answer 1

您的 block 类型错误。

作为the documentation对于

+ (void)sendAsynchronousRequest:(NSURLRequest *)request queue:(NSOperationQueue *)queue completionHandler:(void (^)(NSURLResponse *, NSData *, NSError *))handler

显示，完成黑色的类型是

void (^) (NSURLResponse *, NSData *, NSError *)

不是

void (^) (BOOL)

你应该把 blk 改成类似

void (^blk) (NSURLResponse *, NSData *, NSError *) = ^ (NSURLResponse *response, NSData *data, NSError *error) {
    //...
};

---

这样写会更有格调

[NSURLConnection sendAsynchronousRequest:theRequest queue:theQueue completionHandler:^ (NSURLResponse *response, NSData *data, NSError *error) {
    //...
}];

完成 block 与方法内联。

---

关于在完成处理程序中对 NSManagedObjectContext 执行操作的问题:只要将 NSOperationQueue 传递给 sendAsynchronousRequest:queue:completionHandler 就可以了: 与创建托管对象上下文的代码相同。但是作为the documentation for NSManagedObjectContext州

Core Data uses thread (or serialized queue) confinement to protect managed objects and managed object contexts (see “Concurrency with Core Data”). A consequence of this is that a context assumes the default owner is the thread or queue that allocated it—this is determined by the thread that calls its init method. You should not, therefore, initialize a context on one thread then pass it to a different thread. Instead, you should pass a reference to a persistent store coordinator and have the receiving thread/queue create a new context derived from that.

如果您传递的队列不是您创建托管对象上下文的队列，您必须执行以下操作之一

1. 在创建托管对象上下文的队列上调用 -[NSOperationQueue addOperation:]。

2. 在进行核心数据操作的队列上创建第二个托管对象上下文(具有相同的持久存储协调器)。

3. 在进行核心数据操作的队列上创建第二个托管对象上下文和第二个持久存储协调器。

4. 使用锁定。

关于 Concurrency with Core Data 的文档明确表示您必须使用线程限制(上面的选项 1-3)或使用锁定(上面的选项 4)。

这是文档中关于使用锁的说法:

If you choose not to use the thread containment pattern—that is, if you try to pass managed objects or contexts between threads, and so on—you must be extremely careful about locking, and as a consequence you are likely to negate any benefit you may otherwise derive from multi-threading.

这就是文档所说的不仅有每线程管理的对象上下文，还有每线程持久存储协调器:

This approach provides for greater concurrency at the expense of greater complexity (particularly if you need to communicate changes between different contexts) and increased memory usage.