我应该在我的 OpenGL ES 游戏中使用多个线程吗？答案

【问题标题】：Should I use multiple threads within my OpenGL ES game?我应该在我的 OpenGL ES 游戏中使用多个线程吗？
【发布时间】：2011-03-09 13:04:31
【问题描述】：

我正在开发一款包含一个玩家和许多敌人的 iPhone 游戏。我使用 OpenGL ES 来显示游戏的视觉效果。

对于我应该只使用一个线程还是使用多个线程来移动和控制玩家和敌人，我有点困惑。对于这个基本的游戏架构，您有什么建议？

【问题讨论】：

标签： iphone multithreading opengl-es

【解决方案1】：

我不同意 Max 在这一点上的观点，并说您不应该完全忽略在应用程序中使用多线程。 OpenGL ES 可以从后台线程中绘制，但您一次只能使用单个线程与 OpenGL ES 上下文进行通信。

Apple 在他们的 OpenGL ES Programming Guide for iOS 中有一个完整的部分，标题为“Concurrency and OpenGL ES”。其中，他们描述了使用多线程提高 OpenGL ES 应用程序性能的几种方案。

一般来说，建议您将耗时的操作移出主线程。主线程处理应用程序的用户界面，如果您阻止它，您将阻止标准 UI 元素更新和触摸事件注册。根据您的游戏（物理、AI 等）在幕后进行的处理量，您可能需要将其中的大部分内容移至后台线程。

多线程不是一个简单的话题，但 Apple 通过 Grand Central Dispatch 使这变得更容易，所以我强烈建议阅读他们的Concurrency Programming Guide，其中描述了在您的应用程序中实现多线程的技术和其他技术。另外，我在iOS开发课程中教授了多线程和GCD课程，视频可以是found on iTunes U。

随着 Apple 推出多核设备，现在利用多线程和 GCD 将在未来为您带来巨大的回报。

【讨论】：

我并没有说要忽略多线程（阅读第二段的第一句话）。
结论..我应该使用主线程进行 UI 控制和后台线程进行逻辑，对吗？
@Ali - 主线程应该用于不涉及 OpenGL ES 的用户界面更新、响应触摸事件、执行其他非线程安全的任务（例如处理单个 Core Data 上下文），并可能作为其他进程的同步点。我会将任何需要一段时间来处理的东西卸载到后台线程（同样，不要使用手动线程，看看使用 GCD，因为它会让你的生活更轻松）。
@BradLarson 我喜欢你在那里获得的CLEAN LYRICS 评级。尽管它是 iPhone 编程。

【解决方案2】：

这真的取决于很多事情。首先，如果您使用多个线程，您将不会获得任何性能提升（因为所有现代 iOS 设备都有单核处理器，尽管 iPad2 有 2 个）。其次，多个线程使任何应用程序变得更加复杂，因为您必须跟踪共享资源、同步线程等等。

仅当您确实需要时才使用多个线程。例如，您将大量纹理从文件加载到内存中，这可能需要几秒钟。如果您在执行渲染的同一个线程上执行此操作，那么所有渲染都将在此期间挂起。所以最好在单独的线程上执行此操作，然后将加载的数据提供给主线程。或者，您可以在具有更高更新率的单独线程上更新物理场（但您只能在几个内核上从中受益）。

如果您是新手开发人员并制作一些简单的游戏，请不要使用多线程。这东西需要很多经验。

【讨论】：

仅仅因为应用程序在单核设备上运行并不意味着线程是无用的。如果可能，任何耗时的操作都应该在非主线程上执行以避免阻塞 UI。 OpenGL ES 也可以在后台线程上绘制。
@Brad Larson 抱歉，但真的读过我写的东西吗？请指出我所说的线程是无用的。至于多线程绘图：谢谢，我的错误（我确信只能在非主线程上的单独上下文中执行离屏渲染或渲染到纹理）
我的措辞不准确，但我在评论“如果您使用多个线程，您将不会获得任何性能提升”这一行以及您关于仅受益于在后台执行物理计算的评论多核系统上的线程。您确实可以通过在单核系统上执行多线程任务来实现性能提升，但更重要的是，用户可以通过确保应用程序始终响应来感知您的应用程序速度更快。你对多线程很困难提出了有效的观点，但我不希望人们不必要地拒绝它。
@Brad Larson 多线程将使应用程序在单核上流畅运行，但速度不会更快（可能是由于内部处理器和操作系统优化的缘故）。而且我并不是说我们只能在单独的线程上计算物理（这只是一个例子）。我不鼓励人们使用多线程，但我认为对于经验不足的开发人员来说还为时过早。他无法充分利用线程，只会给应用程序带来额外的混乱。一切都在适当的时候
@Brad Larson 不注意关于物理的评论（我读错了你的答案）