28

首先，我的问题：你如何管理你的 iOS 运行循环？

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

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

那么有没有人找到解决这些问题的灵丹妙药？有没有人在这个平台上有一个杀手级的运行循环架构？目前看来，我必须从邪恶中取其轻。

4

1 回答 1

6

对于我自己的 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如果操作系统支持，这两种方法都可以使用。尽管我的私人项目主要基于加速度计，但我没有注意到这两种方法有任何问题。我怀疑 APRIL 方法也可能使一些问题消失。

于 2011-02-04T19:11:35.877 回答