1

我有一个 iPhone 应用程序，它几乎是一个网站的移动应用程序。它所做的几乎所有事情都是从我们的服务器调用 API 方法。该应用程序检索用户的信息，并使用 API 不断更新服务器。

我和我的同事讨论了是否将 GCD 引入应用程序的下载方面。我的同事认为，由于 UI 需要等待下载完成才能显示图片、文本或其他内容，因此绝对不需要 GCD。我的观点是，我们应该让主线程忙于 UI 渲染（即使没有数据），并将 GCD 引入应用程序以创建其他线程以供下载。

哪个论点是正确的？就我而言，如果 UI 呈现没有数据，会不会有某种滞后？哪个会产生更清洁、更时尚、更快速的应用程序？

4

4 回答 4

4

一种说法是：当下载失败并因为服务器端出现问题而超时时会发生什么？

  • 如果没有 GCD，应用程序将保持被阻止状态，并在超时后崩溃，因为 UI 不能被阻止超过 20 秒。
  • 使用 GCD，应用程序仍然可以正常工作，但不会下载任何数据，应用程序也不会崩溃。

其他需要考虑的方面是：

  • 您正在使用的对象的线程安全性
  • 您如何处理由于用户离开页面而不再需要的下载
于 2012-07-12T10:57:54.217 回答
2

我不认为在主线程中进行耗时的操作是一个好主意。

即使用户必须等待下载数据才能做任何有意义的事情，他仍然不希望 UI 被阻塞。

假设您有一个导航器视图，并且在用户点击某个按钮后，您将一个新视图推送到它并开始下载一些东西。如果用户突然决定他不想再等待，他点击“返回”按钮。如果您的下载操作阻塞了 UI，用户将不得不等待它结束，这真的很糟糕。

于 2012-07-12T11:00:23.923 回答
1

一个更合适的问题可能是您应该异步下载还是在应用程序的主线程上下载，因为在 iOS 上有几种不同的异步下载方法（例如使用 NSThread、NSOperation 或 GCD）。实现目标的一种简单方法是使用AFNetworking库。它使多线程网络/互联网代码非常容易实现和理解。

就我个人而言，我非常喜欢 GCD，并建议您尽快学习它，尽管与 AFNetworking 之类的库（我相信它在底层使用 GCD）相比，它本身并不适合异步下载。

于 2012-07-12T11:32:27.753 回答
0

这是关于使用 NSOperationQueues（在幕后使用 GCD）下载图像的好读物。您还可以查看一些 Github 代码。当用户移动到应用程序的不同部分时，他们有一个优雅的解决方案来暂停下载并将新的下载加入队列。

http://eng.alphonsolabs.com/concurrent-downloads-using-nsoperationqueues/?utm_medium=referral&utm_source=pulsenews

使用 GCD / NSOperationQueues 而不是使用 NSThreads。您将很好地学习核心基础知识，同时创建一个架构良好的应用程序。:)

于 2014-07-18T22:38:07.000 回答