iOS 游戏和运行循环管理

Question

首先，我的问题是：你如何管理你的 iOS Run-Loop？

接下来是我的理由：我一直在研究各种原型（相对于早期开发），并发现了许多令人困惑的问题。

• 首先，输入问题和运行循环导致我尝试以下操作：
  • 当使用最推荐的系统 (CADisplayLink) 时，我注意到一旦 CPU 负载导致缓冲区翻转 (presentRenderBuffer) 必须等待一帧，某些触摸输入就会被丢弃。这种情况仅发生在设备上，而不是在模拟器中（令人烦恼 - 这似乎与主线程上等待垂直同步阻塞以及应用程序运行循环处理触摸输入和吃消息的方式有关）
  • 当使用下一个最推荐的系统（NSTimer）时，我注意到，一旦 CPU 负载达到模拟器中的某个点，某些触摸输入就会被丢弃，但在设备中却不会（也很烦人）。当我的更新触发时，NSTimer 也会导致精度低得多
  • 当使用最不推荐的系统时（使用从 mach_absolute_time 构建的高精度计时器在内部管理的自己的线程中运行运行循环，我所有的触摸输入问题都消失了，但是我的 ASSERT 代码现在陷入了错误的线程，并且仅如果我在软件中断后睡眠（我的断言代码类似于 http://iphone.m20 .nl/wp/?p=1）我真的很喜欢让我的断言代码立即陷入导致问题的行，所以这个解决方案对我来说并不真正可行：更难调试。
• 其次，
  • 在调查系统时，我发现无论帧速率如何（奇怪的是，但我认为从统计角度看，使用垂直同步仍然有意义），我大约有 22% 的时间在等待垂直同步。我通过移动 glFlush/glFinish 并调整执行presentRenderBuffer 调用的频率来确认这一点。这是我想要处理 AI 等的关键时刻，而不是简单地停滞在阻塞的 gl 调用上。我能想到的解决这个问题的唯一方法是将渲染移动到它自己的线程中，但我不确定是否有必要在单处理器设备上开始重新构建多线程。

那么有人找到解决这些问题的灵丹妙药了吗？有没有人拥有在这个平台上表现出色的杀手级运行循环架构？目前看来我必须两害相权取其轻。

Answer 1

对于我自己的 iOS 项目，我使用经典方法（创建一个窗口 .nib，创建一个继承 EAGLView 的类，将 EAGLView 添加到视图控制器中的视图，该视图控制器放置在在它自己的 .nib 中）。

在工作中，受 SDL 启发，我采取了一种略有不同的方法，您可以在我们的开源库 APRIL 中检查该方法。 APRIL 的主要目标是支持尽可能多的平台，同时保持简单性（仅窗口和输入管理）并明确许可问题和免费使用。我们的开发人员希望在一个平台（Windows、Mac 或 Linux，根据喜好和愿望）上编写应用程序，然后将代码交给我以适应其他平台。

在我们在 APRIL 中使用的方法中，您不创建任何 .nib，并且在调用 UIApplicationMain 时，您将委托类指定为其第四个参数。对于每个平台，游戏的主要代码都保持完全相同，只有特定于平台的内容才会被 #ifdef 添加到代码中，或者抽象到辅助库中。

在应用程序委托中，您创建视图控制器和窗口：

- (void)applicationDidFinishLaunching:(UIApplication *)application {
    // create a window.
    // early creation so Default.png can be displayed while we're waiting for 
    // game initialization
    window = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]];

    // viewcontroller will automatically add imageview
    viewController = [[AprilViewController alloc] initWithWindow:window];
    [viewController loadView];

    // set window color
    [window setBackgroundColor:[UIColor blackColor]];

    // display the window
    [window makeKeyAndVisible];

    // thanks to Kyle Poole for this trick
    // also used in latest SDL
    // quote:
    // KP: using a selector gets around the "failed to launch application in time" if the startup code takes too long
    // This is easy to see if running with Valgrind

    [self performSelector:@selector(runMain:) withObject:nil afterDelay:0.2f];
}

注意到我们如何将启动延迟 0.2？这就是我上面提到图像视图的原因。在这 0.2 秒内，我们会在 Default.png 之后立即显示空白屏幕，并且在控制权转移到 runMain: 之前会引入额外的延迟，这会将控制权释放给主应用程序：

- (void)runMain:(id)sender
{       
    // thanks to Kyle Poole for this trick
    char *argv[] = {"april_ios"};
    int status = april_RealMain (1, argv); //gArgc, gArgv);
#pragma unused(status)
}

因此，现在控制权永远不会转移回 UIApplication 的实际的主循环。然后您创建自己的主循环。

    void iOSWindow::enterMainLoop()
    {
            while (mRunning) 
            {
                    // parse UIKit events
                    doEvents();
                    handleDisplayAndUpdate();
            }
    }

    void iOSWindow::doEvents()
    {
            SInt32 result;
            do {
                    result = CFRunLoopRunInMode(kCFRunLoopDefaultMode, 0, TRUE);
            } while(result == kCFRunLoopRunHandledSource);
    }

（顺便说一句，当然，使用视图控制器来简化 UI 的旋转以匹配设备方向。）

如果操作系统支持，这两种方法都使用 CADisplayLink。尽管我的私人项目主要基于加速度计，但我没有注意到这两种方法有任何问题。我怀疑四月的方法也可能会让一些问题消失。