我正在将基于 JavaScript 的混合应用程序转换为原生 iOS 应用程序。当我开始使用 JavaScript 开发应用程序时，我很失望地发现如果你想发出 HTTP 请求，你必须异步执行。我试图以各种方式解决这个问题，基本上:
var done = false;
$.post(url, data, function() { done = true; });
while (!done) {}
//Continue
但我发现这是丑陋的，而且是很糟糕的做法，所以我克服了它，只是异步地完成了它。
因此，当我开始使用 iOS 时，我对我可能能够同步执行它的想法感到很兴奋，但我再次失望地发现推荐的做法是异步的，支持闭包或委托(delegate)来处理响应。
我的问题分为两部分:
- 为什么几乎在所有情况下都采用异步而非同步方式发出 HTTP 请求？
- 有没有办法在 iOS 中发出不难看或不成问题的同步请求？
本质上，我一直希望能够做这样的事情:
var response = SubmitHTTPPostRequest(url, data)
这不是真的吗？我从来没有在学校学过这种东西，所以如果这是一个基本问题，我深表歉意。我一直不明白为什么通常会这样做。
最佳答案
您需要了解从发送请求到获得响应的过程。请求很可能会通过某个网络适配器，到达某个服务器，返回到适配器，然后返回到您的 CPU。一般来说，不会有只涉及一个处理器的情况，在我描述的情况下有 3 个，但通常会有更多。这意味着在一个进程中完成所有工作的同步是不可能的，因为涉及多个处理器。同步路径(如前所述)是让您当前的线程等待。我不同意这会卡住你的用户界面，但会卡住你的线程(如果它是主线程，它会卡住用户界面)。仍然把整个过程放在另一个等待响应的线程中会产生许多其他问题和疑问，例如“我应该为每个请求创建一个线程”，“如果响应时间太长返回会消耗内存吗？”......
我能理解你想要这种同步，这样你就可以在一个方法中完成操作，但最终这正是造成丑陋代码的原因。然后，您的方法包括创建请求、获取响应、处理响应和处理接收到的所有数据。这在开始时似乎是个好主意，但当此方法变得太长时，您将希望将代码重构为至少 3 个方法，这恰好是您需要对异步请求执行的操作。所以回答你的第二个问题:不太可能，异步过程看起来不那么难看。
在大多数情况下，您应该做的并且已经完成的是创建一些类来处理您的请求和响应，因此您只需从代码的 UI 部分进行一次调用。假设您有一个表格 View ，您将在其中显示从某个社交网络收到的 friend 列表。当你第一次来到这个列表时，你想要一些事件指示器 View 来通知用户数据正在加载，然后发送一些异步请求让 friend 不关心响应何时以及是否返回，但是当收到响应时你只需删除事件指示器并使用收到的新数据重新加载 TableView 。现在我希望您可以想象这是一个非常优雅的代码，这样做可以使用户能够通过按返回来取消请求。
所以进行异步请求的主要原因是不要阻塞线程，因为这可能会产生多个问题，甚至阻塞主线程，这将阻塞 UI，如果主线程阻塞时间过长，应用程序将被杀死iOS(看门狗)。以及进行同步的原因？好吧，从长远来看，我想不出有什么，你应该总是将操作分解成许多方法并使用回调。
关于ios - 同步与异步 HTTP 请求，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/24544185/