java - 带有 SurfaceView 和逻辑单元的 Android 游戏

Question

我阅读了很多关于 SurfaceView 以及如何将其集成到 Android 游戏中的帖子，但几乎所有帖子都忽略了一些内容......使用 SurfaceView 的原因是将所有图形逻辑和屏幕渲染导出到不同的线程(以实现性能提升)。但在我阅读的所有帖子中，SurfaceView 线程还负责逻辑和游戏状态更新，因此似乎它占据了使用 SurfaceView 的全部意义。即使在逻辑单元使用不同线程的帖子中，更新方法和渲染方法也是同步调用的，而且，这似乎使 SurfaceView 变得不必要了。

我们将不胜感激您的帮助(如果可能，请提供示例)。

Answer 1

有类似的问题here和 here ，尽管您的问题有所不同，因为它不是“如何”而是“为什么”。

能够独立于主 UI 线程进行渲染有一些优势，因为那里总会有一些 Activity ——处理用户输入、响应系统查询、管理屏幕上任何基于 View 的 UI 元素。 SurfaceView 不需要您使用单独的线程，只是让它成为可能。

将游戏逻辑与渲染分离也有优势，尤其是当您使用 Canvas 进行渲染时，因为 SurfaceView 上基于 Canvas 的渲染不是硬件加速的。因为这一切都发生在 CPU 上，所以跨线程拆分工作有一个主要优势。如果您使用的是 OpenGL ES，则优势会减少，但如果您不利用 VBO 和其他优化，仍然会有相当多的 CPU 开销。

跨线程拆分渲染和游戏逻辑的麻烦在于您必须非常小心。您必须使用适当的同步机制，否则事情会变得很奇怪。在 ARM 上比在 x86 上更容易出错。关于这个主题有一篇很长的文档here .如果您省略同步，您可能会遇到严重的错误，如果您的同步过于繁重，则会扼杀并发性并失去拥有多线程的好处。

这样做的一个结果是示例代码倾向于采用更简单的方法，通常会在单个线程上完成所有工作。除非该示例明确试图显示劳动分工，否则跨线程拆分工作所引入的复杂性会使该示例蒙上阴影。

在线程之间划分工作的一个经常被引用的例子是 Replica Island .如果你看看它的方式 onDrawFrame()方法有效，您可以看到它在线程之间传递了一个“绘制队列”。

使用 SurfaceView 还有其他优势。 SurfaceView 输出位于与基于 View 的 UI 完全不同的层上，这意味着您将获得一个大的空白缓冲区来涂鸦。您可以将它放在 View UI 的上方或下方，这样您就可以隐藏 UI 或让 View UI 覆盖游戏(例如“菜单”按钮或装饰框)。您在 Surface 上所做的任何事情都不会导致 View 失效/重绘循环(这可能非常昂贵)。当然，您可以直接使用 OpenGL ES 进行渲染，随着设备屏幕越来越密集，这一点变得越来越重要。

关于游戏循环的一些其他想法可以在 graphics architecture doc 中找到.