3

我一直在使用一些处理 NSURLConnections 的应用程序。在研究最佳实践时，我注意到网上有很多例子展示了如何使用NSOperation和NSOperationQueue处理这个问题。

我还在 stackoverflow 上注意到了一些示例，这些示例显示使用NSURLConnection:sendAsynchronousRequest和的类方法将连接初始化为同步和异步sendSynchronousRequest。

目前我正在按如下方式进行初始化：

[[NSURLConnection alloc] initWithRequest:request delegate:self];

在执行此操作时，我监控了主线程和对委托方法的调用：

connectionDidFinishLoading, connectionDidReceiveResponse,connectionDidReceiveData和connectionDidFailWithError

我在 Apples 文档中阅读的所有内容和我的测试都向我证明，默认行为是异步的。

我想从更有经验的Objective C程序员那里知道什么时候其他选项将用于最佳实践，或者只是比我认为获得异步行为的最简单方法更正确？

这是我在这里发布的第一个问题，如果需要更多信息，请询问。

4

2 回答 2

3

同步是坏坏坏。尽量避免它。如果数据传输量很大，这将阻塞您的主线程，从而导致 UI 无响应。

是的，可以将同步调用分派到不同的线程上，但是您必须在主线程上访问任何 UI 元素，这很混乱。

通常我只使用您描述的委托方法 - 它很简单，并且 NSURLConnection 已经为您处理远离主线程的异步调用。您需要做的就是实现简单的委托方法！代码有点多，但你总是想异步。总是。当它完成加载时，使用您从finishedLoading 委托方法获得的信息来更新UI。

你现在也可以选择使用积木，但我不能说它们的效果如何，甚至不能说如何很好地使用它们。我确信某处有一个教程 - 委托方法很容易实现。

于 2012-07-06T00:31:11.600 回答
2

您列出的方法是传统的异步传输方式，使用它们的应用程序在处理器（以及因此电源）使用方面将是有效的。

该sendAsynchronousRequest方法是一个相对较新的添加，在 iOS 5 中出现。就最佳实践而言，除了可以取消使用后者创建的请求和使用以前不能。sendAsynchronousRequest然而，如果你知道你不想取消你的连接，那么基于块的错误的整洁性以及可读性和更大的不可能性可以说给了它一个优势。

作为最佳实践，sendSynchronousRequest应始终避免。如果您在主线程上使用它，那么您将阻止用户界面。如果您在为更通用目的而创建的任何其他线程或队列上使用它，那么您将阻止它。如果您为它创建一个特殊的队列或线程，或者将其发布到一个，NSOperationQueue那么您将不会比普通的异步发布获得任何真正的优势，并且根据 Apple 的标准 WWDC 评论，您的应用程序的能效将降低。

对的引用sendSynchronousRequest可能是 iOS 5 之前的模式的残余。在您看到 a 的任何地方sendSynchronousRequest，asendAsynchronousRequest都可以很容易地实现，从而更有效地执行。我猜它最初是包含在内的，因为有时您正在调整需要以直线流动的代码，并且因为没有块，因此没有“基本上是直线”的方式来实现异步调用。我现在真的想不出任何好的理由来使用它。

于 2012-07-06T01:14:35.090 回答