我正在测试使用 Grand Central Dispatch 进行异步处理的代码。测试代码如下：
[object runSomeLongOperationAndDo:^{ STAssert…}];
__block BOOL finished = NO;
[object runSomeLongOperationAndDo:^{
STAssert…
finished = YES;
}];
while (!finished);
这看起来有点粗糙，你知道更好的方法吗？ 我可以暴露队列并通过调用dispatch_sync进行阻塞：
[object runSomeLongOperationAndDo:^{
STAssert…
}];
dispatch_sync(object.queue, ^{});
...但这可能在对象方面暴露了太多。
尝试使用 dispatch_semaphore。它应该类似于这样：
dispatch_semaphore_t sema = dispatch_semaphore_create(0);
[object runSomeLongOperationAndDo:^{
STAssert…
dispatch_semaphore_signal(sema);
}];
if (![NSThread isMainThread]) {
dispatch_semaphore_wait(sema, DISPATCH_TIME_FOREVER);
} else {
while (dispatch_semaphore_wait(sema, DISPATCH_TIME_NOW)) {
[[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:[NSDate dateWithTimeIntervalSinceNow:0]];
}
}
即使 runSomeLongOperationAndDo: 决定操作实际上不够长而不是使用线程同步运行，这段代码也应该可以正确地运行。
除了其他答案中详细介绍的信号量技术外，我们现在可以在Xcode 6中使用XCTest通过 XCTestExpectation 执行异步测试。这消除了在测试异步代码时需要使用信号量的需求。例如：
- (void)testDataTask
{
XCTestExpectation *expectation = [self expectationWithDescription:@"asynchronous request"];
NSURL *url = [NSURL URLWithString:@"http://www.apple.com"];
NSURLSessionTask *task = [self.session dataTaskWithURL:url completionHandler:^(NSData *data, NSURLResponse *response, NSError *error) {
XCTAssertNil(error, @"dataTaskWithURL error %@", error);
if ([response isKindOfClass:[NSHTTPURLResponse class]]) {
NSInteger statusCode = [(NSHTTPURLResponse *) response statusCode];
XCTAssertEqual(statusCode, 200, @"status code was not 200; was %d", statusCode);
}
XCTAssert(data, @"data nil");
// do additional tests on the contents of the `data` object here, if you want
// when all done, Fulfill the expectation
[expectation fulfill];
}];
[task resume];
[self waitForExpectationsWithTimeout:10.0 handler:nil];
}
我知道这里并非如此情况（当这个问题被发布时，还没有像 XCTestExpectation 这样好用的工具；而且，在这些测试套件中，我们必须确保测试在异步调用完成之前不会结束）。这是那些阻塞主线程的信号量技术可能是必要的罕见情况之一。
因此，向原始问题的作者致以歉意，对于他们来说，信号量技术是可行的，但我写下这个警告，提醒所有看到这个信号量技术并考虑将其应用于代码中作为处理异步方法的一般方法的新开发人员：请注意，十有八九，信号量技术不是处理异步操作的最佳方式。相反，请熟悉完成块/闭包模式，以及委托-协议模式和通知。这些往往是处理异步任务的更好方式，而不是使用信号量来使它们表现得同步。通常异步任务被设计成异步执行有其良好的理由，因此请使用正确的异步模式，而不是试图使它们表现得同步。
NSOperationQueue上安排下载。除非我使用类似信号量的东西，否则文档下载NSOperation将立即全部完成，并且不会有任何真正的下载队列 - 它们基本上会并发进行，这是我不想要的。在这里使用信号量合理吗？还是有更好的方法让NSOperations等待其他操作的异步结束？或者其他什么方法？ - BenjohnAFHTTPRequestOperation 对象，那么您应该创建一个完成操作（其将依赖于其他操作）。或者使用调度组。顺便说一句，你说你不想让它们并发运行，如果这是你需要的，那很好，但是如果按顺序执行而不是并发执行，则会支付严重的性能代价。我通常使用 4 或 5 的 maxConcurrentOperationCount。 - Rob最近我又遇到了这个问题，并编写了以下关于NSObject的类别：
@implementation NSObject (Testing)
- (void) performSelector: (SEL) selector
withBlockingCallback: (dispatch_block_t) block
{
dispatch_semaphore_t semaphore = dispatch_semaphore_create(0);
[self performSelector:selector withObject:^{
if (block) block();
dispatch_semaphore_signal(semaphore);
}];
dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
dispatch_release(semaphore);
}
@end
这种方式可以让我在测试中将带有回调函数的异步调用轻松转换为同步调用:
[testedObject performSelector:@selector(longAsyncOpWithCallback:) withBlockingCallback:^{ STAssert…}];
通常不要使用这些答案，它们往往无法扩展（当然也有例外情况）
这些方法与GCD的预期工作方式不兼容，最终会导致死锁和/或通过不断轮询耗尽电池。
换句话说，重新排列代码，使其不再同步等待结果，而是处理状态变化的通知（例如回调/委托协议，可用性，消失，错误等）。 （如果您不喜欢回调地狱，可以将其重构为块。）因为这样才能将真实行为暴露给应用程序的其他部分，而不是隐藏在虚假的外观后面。
相反，使用NSNotificationCenter，为您的类定义一个带有回调的自定义委托协议。如果您不喜欢在各个地方处理委托回调，可以将它们封装到一个具体的代理类中，该类实现自定义协议并将各种块保存在属性中。可能还提供方便的构造函数。
初始工作量稍微多一些，但从长远来看，它将减少可怕的竞态条件和耗电轮询的数量。
别问我要一个例子，因为它太简单了，而且我们也得花时间学习Objective-C的基础知识。
这里有一个不需要使用信号量的巧妙技巧：
dispatch_queue_t serialQ = dispatch_queue_create("serialQ", DISPATCH_QUEUE_SERIAL);
dispatch_async(serialQ, ^
{
[object doSomething];
});
dispatch_sync(serialQ, ^{ });
您需要使用dispatch_sync和一个空块等待，以便在A-Synchronous块完成之前同步等待串行调度队列。
- (void)performAndWait:(void (^)(dispatch_semaphore_t semaphore))perform;
{
NSParameterAssert(perform);
dispatch_semaphore_t semaphore = dispatch_semaphore_create(0);
perform(semaphore);
dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
dispatch_release(semaphore);
}
使用示例：
[self performAndWait:^(dispatch_semaphore_t semaphore) {
[self someLongOperationWithSuccess:^{
dispatch_semaphore_signal(semaphore);
}];
}];
还有SenTestingKitAsync，可以让你编写像这样的代码：
- (void)testAdditionAsync {
[Calculator add:2 to:2 block^(int result) {
STAssertEquals(result, 4, nil);
STSuccess();
}];
STFailAfter(2.0, @"Timeout");
}
（详情请参见objc.io文章。）自从Xcode 6以来，XCTest有一个AsynchronousTesting类别，让你可以编写像这样的代码：
XCTestExpectation *somethingHappened = [self expectationWithDescription:@"something happened"];
[testedObject doSomethigAsyncWithCompletion:^(BOOL succeeded, NSError *error) {
[somethingHappened fulfill];
}];
[self waitForExpectationsWithTimeout:1 handler:NULL];
Swift 4:
在创建远程对象时，请使用synchronousRemoteObjectProxyWithErrorHandler代替remoteObjectProxy。不再需要信号量。
下面的示例将返回从代理接收到的版本。如果没有synchronousRemoteObjectProxyWithErrorHandler，它将崩溃（尝试访问不可访问的内存）：
func getVersion(xpc: NSXPCConnection) -> String
{
var version = ""
if let helper = xpc.synchronousRemoteObjectProxyWithErrorHandler({ error in NSLog(error.localizedDescription) }) as? HelperProtocol
{
helper.getVersion(reply: {
installedVersion in
print("Helper: Installed Version => \(installedVersion)")
version = installedVersion
})
}
return version
}
这里是我其中一个测试的替代方案：
__block BOOL success;
NSCondition *completed = NSCondition.new;
[completed lock];
STAssertNoThrow([self.client asyncSomethingWithCompletionHandler:^(id value) {
success = value != nil;
[completed lock];
[completed signal];
[completed unlock];
}], nil);
[completed waitUntilDate:[NSDate dateWithTimeIntervalSinceNow:2]];
[completed unlock];
STAssertTrue(success, nil);
NSCondition 的文档，在调用 -waitUntilDate: 方法之前，必须先锁定接收器。因此，-unlock 应该在 -waitUntilDate: 之后执行。 - Patrick解决问题的非常原始的方法：
void (^nextOperationAfterLongOperationBlock)(void) = ^{
};
[object runSomeLongOperationAndDo:^{
STAssert…
nextOperationAfterLongOperationBlock();
}];
dispatch_semaphore_wait(sema, DISPATCH_TIME_FOREVER);替换为while (dispatch_semaphore_wait(semaphore, DISPATCH_TIME_NOW)) { [[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:[NSDate dateWithTimeIntervalSinceNow:10]]; }。 - nicktmro