向NSOperationQueue
添加NSOperation
是否安全,然后将此操作添加到另一个NSOperationQueue
?
这是一些可视化我想要做的事情的代码。
NSOperationQueue *mainQueue = [NSOperationQueue alloc] init];
// Here I declare some NSBlockOperation's, i.e. parseOperation1-2-3
// and also another operation called zipOperation, which includes
// an NSOperationQueue itself. This queue takes the processed (parsed) files
// and write them to a single zip file. Each operation's job is to write the data
// stream and add it to the zip file. After all operations are done,
// it closes the zip.
[zipOperation addDependency:parseOperation1];
[zipOperation addDependency:parseOperation2];
[zipOperation addDependency:parseOperation3];
[mainQueue addOperation:parseOperation1];
[mainQueue addOperation:parseOperation2];
[mainQueue addOperation:parseOperation3];
[mainQueue addOperation:zipOperation];
答案 0 :(得分:5)
我使用过这种方法,并在App Store上部署的实时代码中运行。在开发期间或自代码生效以来的最近2个月内,我没有遇到任何问题。
在我的情况下,我有一系列高级操作,其中一些操作包含一组子操作。我没有将每个子操作的细节暴露在高级代码中,而是创建了NSOperations
,它们自己包含NSOperationQueues
并将自己的子操作排入队列。我最终得到的代码更清晰,更易于维护。
我在NSOperation
广泛阅读,并没有看到任何警告反对这种方法的评论。我在线查看了很多信息,Apple文档和WWDC视频。
唯一可能的“缺点”可能是理解和实施Concurrent
操作增加了复杂性。在NSOperationQueue
中嵌入NSOperation
表示操作变为Concurrent
。
这对我来说是'是'。
有关并发操作的其他详细信息:
NSOperationQueue
在普通(非并发)start
上调用NSOperation
方法,并期望在start
调用返回时完成操作。例如,您提供给NSBlockOperation
的某些代码在块结束时完成。
如果在start
调用返回时工作无法完成,那么您将NSOperation
配置为Concurrent
操作,因此NSOperationQueue
知道它已经等到你告诉它操作在稍后的某个时间点完成。
例如,并发操作通常用于运行异步网络调用; start方法只启动网络调用,然后在后台运行,并在完成后回调操作。然后,您可以更改isFinished
的{{1}}属性,以标记工作现已完成。
所以....通常当您向NSOperation
添加操作时,该队列在后台运行这些操作。因此,如果您将NSOperationQueue
放在NSOperationQueue
内,那么操作工作将在后台完成。因此,操作为NSOperation
,您需要标记内部concurrent
何时完成所有操作的处理。
或者NSOperationQueue
上有一些方法,例如NSOperationQueue
,可用于确保在waitUntilAllOperationsAreFinished
调用返回之前完成所有工作,但这些方法涉及阻塞线程,我避免他们,您可能会对这种方法感到更舒服,并确保您不会因阻塞线程而产生任何副作用。
在我的情况下,我已经熟悉了start
操作,因此只需将其设置为Concurrent
操作即可。
有关并发操作的一些文档:
Concurrency Programming Guide: Configuring Operations for Concurrent Execution
在这个例子中,他们正在分离一个线程以在后台执行工作,在我们的例子中,我们将在这里开始Concurrent
。