我一直在处理一些处理NSURLConnections的应用程序。在研究最佳实践时，我注意到很多在线示例展示了如何使用NSOperation和NSOperationQueue来解决这个问题。
我还在stackoverflow上注意到一些示例，它们使用NSURLConnection：sendAsynchronousRequest和sendSynchronousRequest的类方法将连接初始化为同步和异步。
目前我正在进行如下初始化：
[[NSURLConnection alloc] initWithRequest:request delegate:self];
在执行此操作时，我监视了主线程和对委托方法的调用：
connectionDidFinishLoading，connectionDidReceiveResponse，connectionDidReceiveData和connectionDidFailWithError
我在Apples文档中读到的所有内容以及我的测试都证明，默认情况下这是异步的。
我想从更有经验的Objective C程序员那里知道其他选项是用于最佳实践，还是比我认为最简单的异步行为方式更正确？
这是我在这里发布的第一个问题，如果需要更多信息，请询问。
答案 0 :(得分：3)
同步坏坏坏。尽量避免它。如果数据传输很大，这将阻止您的主线程，从而导致无响应的UI。
是的，可以将同步调用分派到不同的线程上，但是你必须在主线程上访问任何UI元素，这是一团糟。
通常我只使用你所描述的委托方法 - 它很简单，并且NSURLConnection已经处理了远离主线程的异步调用。您需要做的就是实现简单的委托方法！这是一些代码，但你总是希望异步。总是。加载完成后，使用您获得的信息从finishedLoading委托方法更新UI。
您现在也可以选择使用块，但我不能说这些工作有多好，甚至不能使用它们。我确定在某个地方有一个教程 - 委托方法很容易实现。
答案 1 :(得分：2)
您列出的方法是传统的异步传输方式，使用它们的应用程序在处理器（以及功率）的使用方面效率很高。
sendAsynchronousRequest方法是一个相对较新的附加功能，可以在iOS 5中使用。就最佳实践而言，除了样式之外，除了使用后者创建的请求之外，还可以区分它和数据委托方法之外的其他方法。被取消，与前者创建的请求不能。然而，如果你知道你不想取消你的连接，基于块的sendAsynchronousRequest的错误的整洁性和可读性以及更大的不可能性可能会给它带来优势。
作为最佳做法，应始终避免使用sendSynchronousRequest。如果您在主线程上使用它，那么您将阻止用户界面。如果您在为更常见的目的创建的任何其他线程或队列中使用它，那么您将阻止它。如果你为它创建一个特殊的队列或线程，或者将它发布到NSOperationQueue，那么你将比普通的异步帖子没有真正的优势，而且根据Apple的标准WWDC评论，你的应用程序的功效将会降低。
对sendSynchronousRequest的引用可能是iOS 5之前模式的残余。在您看到sendSynchronousRequest的任何地方，sendAsynchronousRequest都可以轻松实施，以便更有效地执行。我猜它最初被包含在内，因为有时候你需要调整需要直线流动的代码，因为没有块，因此没有“基本上是直线”的方式来实现异步调用。我现在真的想不出任何有理由使用它。