在单独的线程中做什么？
因此，我阅读了一些有关多线程和 NSOperation 的内容，并想知道如何使用它们来改进我的应用程序。使用 Instruments，我隔离了一些我的应用程序绝对可以提高速度的地方。我的问题是，这些东西适合使用 NSOperation 的另一个线程吗？
绘制视图：我有一个相当复杂的视图，需要一些时间来绘制。当它被绘制时，我经历了一些滞后。
分配和播放音频：我正在使用AVAudioPlayer来播放一些背景音乐。当我分配它时，又出现一些滞后。
计算：我还执行一些计算并与大量整数进行一些比较。
我努力为我的应用程序提供最佳性能，那么您会怎么做？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
UI 更新不适合后台线程。所有 UI 更新始终需要在主线程上完成。如果您的视图渲染时间过长，请考虑重构、预渲染和缓存或其他一些优化方法。
音频代码可以基于后台，但不应该那么昂贵
。计算绝对可以在后台进行，无需担心。
UI updates are not suitable on the Background thread. All UI updates always need to be done on the main thread. If your view is taking too much time to render, consider refactoring, pre-redering and caching or some other means of optimization.
Audio code can be background based, but shouldn't be that expensive
Calculations can definitely be backgrounded without worry.
我同意后台线程不适合 UI 更新。由于用户在等待 UI 向他们显示正在发生的事情时被“阻止” - 从逻辑角度来看这是没有意义的 - 并且可能会导致其他编码问题。
我发现对后台线程来说最有利的事情通常与异步操作有关。 （想想 AJAX 网页）。如果您希望用户在发生某些事情时能够与 UI 进行交互。一个很好的例子是从网络上检索、更新、获取任何类型的数据。
即使您正在执行任何您认为应该同步的 Web 操作（例如从网站加载消息），您也可能希望异步处理它> 因为你不知道什么样的网络条件会导致它花费很长时间 - 也许最终会超时或失败。 （录制音频之类的东西也可以这样工作）。
即使您想要在从网络读取此类同步数据时阻止您的应用程序，您可能仍然希望异步执行此操作> - 这样您就可以在后台线程中加载数据 - 同时您提供进度条、微调器（进度）控件，或允许用户在前台 UI 线程中点击“取消”按钮。
将“异步”请求视为需要较长时间的请求 - 或者您无法确定需要多长时间。
I concur that background threads are not the thing to do for UI updates. Since the user is "blocked" on waiting for the UI to show them what is going on - it doesn't make sense from a logical point-of-view - and it can cause other coding issues.
The biggest thing I have found good for background threads often has to do with asynchronous operations. (Think of an AJAX web page). If you want your user to be able to interact with the UI while something is going on. A good example would be retreiving, updating, fetching any kind of data from the web.
Even if you are doing any kind of web operations which you would think should be synchronous - (like loading a message from a web site) - you would probibly want to handle it asynchronously because you don't know what kind of network conditions would cause it to take a long time - and perhaps eventually timeout or fail. (Something like recording audio would work like this too).
Even if you were to want to block your application when reading such a synchronous piece of data from the web, you may still want to do this asynchronously - so you could load the data in a background thread - while you give a progress bar, spinner (progress) control, or allowed the user to hit a "Cancel" button in the foreground UI thread.
Think of "asynchronous" requests as ones that will take a longer period of time - or in which you can't determine how much time it will take.
iOS 4.0 使一些 UI 绘制方法成为线程安全的：
我发现我的应用程序通常从后台线程中受益最多：
如果您确实决定将某些任务置于后台，我建议使用 NSOperation 和 NSOperationQueue，因为他们把事情简化了很多。有点学习曲线，但绝对值得！
祝你好运！
Some UI drawing methods were made thread safe with iOS 4.0:
I've found that my apps generally benefit the most from background threading:
If you do decide to background some tasks, I would recommend using NSOperation and NSOperationQueue, as they simplify things a lot. A bit of a learning curve, but definitely worth it!
Best of luck!