在Apple的AVFoundation演示的每个示例代码中，都有一个单独的队列用于所有会话任务。
dispatch_queue_t sessionQueue = dispatch_queue_create("session queue", DISPATCH_QUEUE_SERIAL);
这也用于观察焦点变化，曝光变化，白平衡变化等:
- (void)viewWillAppear:(BOOL)animated
{
[super viewWillAppear:animated];
dispatch_async([self sessionQueue], ^{
[self addObservers];
[[self session] startRunning];
});
}
- (void)viewDidDisappear:(BOOL)animated
{
dispatch_async([self sessionQueue], ^{
[[self session] stopRunning];
[self removeObservers];
});
[super viewDidDisappear:animated];
}
当我遵循这一点时，一切都很顺利，直到我采用了'GPUImage'，一个第三方api。我被告知，这个api不需要多线程或单独排队，因为它都在内部处理。所以我把'sessionQueue'完全去掉了。
然而，现在我的应用程序运行真的不稳定，我认为这是由于主线列被告知要处理大多数分支任务。
我可以有一个单独的队列只是为了观察自我。videoCamera变化?这会减少mainQueue的大部分负载吗?
等等，gizmodo!我没有说(我认为你的意思是我)，"多线程或单独排队是不需要的"。我说我不相信您在前面的问题中实际展示的(很小的)代码中需要它。
你也完全正确，苹果直接建议在后台线程上启动捕获会话。正如他们在AVCamManual示例代码中的注释明确地说:
-[AVCaptureSession startRunning]为阻塞呼叫，耗时较长。我们将会话设置分派给sessionQueue，这样主队列就不会阻塞(这使UI保持响应)。
到目前为止，一切顺利。但我也说过，我坚持这一点:多线程是硬。
让我们以这个新问题中的代码为例。你在说:
dispatch_async([self sessionQueue], ^{
[[self session] stopRunning];
[self removeObservers];
});
现在，这可能是一个可以说的事情，然后又可能不是。在Apple的示例代码中，决定在后台线程上启动捕获会话后，他们小心地从那时起只在该线程(队列)上访问捕获会话。你似乎也在做同样的事。很好。
但这并不是你在后台线程中所做的全部。我怎么知道在你的removeObservers方法中会发生什么呢?如果它触及self或任何其他对象的任何属性，或者如果它调用任何这样做的方法，或者如果它调用Cocoa的任何非线程安全的部分(实际上，这可能是Cocoa的大部分)，那么当事情神秘地和不可调试地出错时，您将面临严重的麻烦-如果不是对您，那么对某些用户来说(甚至更糟)。(当然，作为简单的假设，我省略了任何以任何方式与除主线程以外的任何应用程序界面连接的危险。)
我怎么知道你在代码的其他部分还做了什么?在这个背景线程中，Apple小心地只触摸[self session] ;这是一条重要的规则，也是好的多线程所包含的一部分。但是你知道这个规则吗?是否您曾经犯过在主线程或与此不同的其他线程上触摸[self session]的错误?我怎么知道?我不喜欢。
现在，也许你已经彻底检查了你的removeObservers方法(以及你从后台线程调用的所有其他方法)。我猜removeObservers可能直接复制了苹果示例代码中的模型，在这种情况下，一切可能都很好。也许你是一个了不起的多线程者，我在这里所说的一切对你来说都很熟悉，就像鸭子背上的水一样被洗掉了。太好了!那么这些担忧对你来说就不是问题了，你应该无视我的话。简而言之，您可以并且可能应该使用后台线程来处理捕获会话，只要您知道自己在做什么并且不超出安全范围即可。如果你知道这些界限是什么，那就太好了!我的警告过去是，现在也是，以防你不知道。