2

So I've read some stuff about multithreading and NSOperation and wondering how I can use that to improve my app. Using Instruments I have isolated a few places where my app could definitely use a speed improvement. My question is, are these kinds of things suitable for another thread using NSOperation?

Drawing a view: I have a rather complex view that is taking a little time to draw. When it's drawn I experience some lag.

Allocating and playing audio: I'm using AVAudioPlayer to play some background music. When I allocate it, again some lag.

Calculations: I'm also performing some calculations and doing some comparisons with lots of integers.

I strive for the best possible performance for my app, so what would you do?

4

3 回答 3

5

UI 更新不适用于后台线程。所有 UI 更新总是需要在主线程上完成。如果您的视图渲染时间过长，请考虑重构、预渲染和缓存或其他一些优化方法。

音频代码可以基于背景，但不应该那么昂贵

计算绝对可以毫无后顾之忧。

于 2010-10-24T15:17:46.943 回答
4

我同意后台线程不是 UI 更新要做的事情。由于用户在等待 UI 向他们显示正在发生的事情时被“阻止”——从逻辑的角度来看这是没有意义的——并且它可能导致其他编码问题。

我发现对后台线程最有利的事情通常与异步操作有关。（想想 AJAX 网页）。如果您希望您的用户能够在发生某些事情时与 UI进行交互。一个很好的例子是从网络上检索、更新、获取任何类型的数据。

即使您正在执行您认为应该是同步的任何类型的 Web 操作（例如从网站加载消息），您也可能希望异步处理它，因为您不知道什么样的网络条件会导致它需要很长时间 - 可能最终会超时或失败。（像录制音频之类的东西也可以这样工作）。

即使您想在从 Web读取这样的同步数据时阻止您的应用程序，您可能仍然希望异步执行此操作- 这样您可以在后台线程中加载数据 - 同时提供进度条，微调器（进度）控制，或允许用户在前台UI 线程中点击“取消”按钮。

将“异步”请求视为需要较长时间的请求 - 或者您无法确定需要多少时间。

于 2010-10-24T21:34:29.080 回答
3

在 iOS 4.0 中，一些 UI 绘制方法是线程安全的：

资料来源：Apple 开发人员：iOS 的新功能：iOS 4.0

在 UIKit 中绘制到图形上下文现在是线程安全的。具体来说：

  • 用于访问和操作图形上下文的例程现在可以正确处理驻留在不同线程上的上下文。
  • 字符串和图像绘制现在是线程安全的。
  • 现在可以安全地在多个线程中使用颜色和字体对象。

我发现我的应用程序通常从后台线程中受益最多：

  • 从网上下载东西
  • 对数据库的昂贵查询（读/写）
  • 长时间运行的算法

如果您决定将某些任务置于后台，我建议您使用 NSOperation 和 NSOperationQueue，因为它们可以简化很多事情。有点学习曲线，但绝对值得！

祝你好运！

于 2010-10-24T23:35:52.407 回答