2

我一直在为 iOS 开发一个 opencv 项目。我得到了一个简单的项目，开始使用捕获和显示的帧进行开发。在我开始遇到内存问题并将它们追溯到原始项目设置之前，我从来没有过多关注它是如何工作的。我现在计划重新编写捕获/显示代码，但我不明白为什么它首先会起作用。有一个播放/暂停按钮调用该方法

- (IBAction)play_pause:(id)sender
{
  play = !play;
  while(play)
  {
    if (_videoCapture && _videoCapture->grab())
    {
        (*_videoCapture) >> _display_frame;
        //process frame
        self.imageView.image = [UIImage imageWithCVMat:_display_frame];
    }
  }
}

play 只是一个全局布尔值，表示应用程序是在播放还是暂停。奇怪的是，处理应该发生在一个无限循环中，没有出路。play 在循环中永远不会被修改。尽管如此，当应用程序运行时，播放/暂停按钮保持响应，并且能够翻转播放布尔并暂停执行。不仅如此，其他布尔值（例如use_greyscale）可以被其他按钮翻转，并且它们的值在循环内改变。我原以为应用程序会冻结，甚至永远不会在屏幕上绘制新帧。应用程序在其生命周期的大部分时间里都应该被困在该函数中，无法执行其他任务，例如绘图和 UIControl。似乎唯一可行的方法是 IBAction 调用在其自己的线程上运行。我在源代码中找不到任何线程的证据。有人可以解释一下苹果如何处理其 UI 中的线程吗？我的印象是只有一个主运行循环线程，并且不会自动创建额外的线程。如果这是真的，如何解释这种行为？

边注-

最终让我调查的是 [UIImage imageWithCVMat:_display_frame] 返回一个自动释放的对象。由于所有这些都发生在一个循环内，因此如果不暂停执行，就无法释放对象，这会导致崩溃。

4

2 回答 2

3

之所以起作用是因为该cv::VideoCapture::grab()方法的实现运行当前的运行循环以暂停线程，直到它获得一帧。

当您启动应用程序时，该main函数会执行一个名为 的函数，该函数UIApplicationMain会执行CFRunLoopRun。当CFRunLoopRun在主线程上执行时，它运行主运行循环，即处理从系统接收到的所有 UI 事件并刷新用户界面的运行循环。有关运行循环的信息，您可以阅读Apple Threading Programming Guide。

因此，当您执行无限循环时，您的代码永远不会返回到运行循环，并且无法处理等待事件。但是在您的情况下，该grab方法会再次运行运行循环，并具有到期延迟。因此，运行循环可能会处理传入事件（可能会再次调用您的代码），直到延迟到期，然后返回将再次运行运行循环的代码。

如果您在触摸按钮暂停时查看调用堆栈，您将看到：

主函数 → 运行循环 → 事件处理 → 你的代码 → OpenCV → 运行循环 → 事件处理 → 你的代码

运行循环在其自身内部运行，这非常好，因为运行循环是可重入的。滚动视图实际上使用了这种行为：当您滚动 aUIScrollView时，它会以不同的模式再次运行运行循环，以便在您结束滚动之前忽略某些事件。

但我不确定 OpenCV 的开发人员在编写代码时是否考虑到了这一点。所以我认为在后台线程/队列中加载你的帧会更好。

于 2012-06-25T18:02:30.540 回答
0

你是对的，iOS 中没有“自动线程”。Grand Central Dispatch (GCD) 确实使线程更容易，但它不会自动发生。

您可以编写一些调试代码并在 while 循环中测试 [NSThread isMainThread] 以查看 play_pause 是否确实在主 UI 线程上运行，我怀疑它不是。

于 2012-06-25T17:18:47.383 回答