(iphone) 哪一个在时间上更精确:performSelector:afterDelay vs NSTimer

发布于 2024-10-16 07:26:11 字数 1465 浏览 6 评论 0原文

我正在使用 PerformSelector:withObject:afterDelay 以 24fps 制作动画。
(原因是,UIImageView不支持图像之间的不同间隔)
当我同时运行多个动画时,似乎由执行选择器排队的消息需要很长时间才能被拾取。

我想知道 NSTimer 或另一个会是更好的选择。

谢谢

  • 编辑,

除了运行动画之外我没有做任何事情。
我正在运行的选择器占用了 0.0003 左右的时间。(几乎没有时间)
但是,当我测量调用“performSelector”和实际调用选择器的时间之间的时间时,该时间实际上比我用“afterDelay”或“scheduledTimerWithDuration”指定的时间长,

我已经查看了仪器,但无法弄清楚是什么导致了延迟.
我刚刚看到了很多与线程相关的(我猜线程暂停/恢复)活动。
也许我下面的 threadMain 代码占用了很多时间?

- (void) myThreadMain
{
    NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];

    // Add your sources or timers to the run loop and do any other setup.                                                                                                                                                                                                     
    NSRunLoop *runloop = [NSRunLoop currentRunLoop];
    [runloop addPort:[NSMachPort port] forMode:NSDefaultRunLoopMode];

    do
    {
        // Start the run loop but return after each source is handled.                                                                                                                                                                                                        
        SInt32    result = CFRunLoopRunInMode(kCFRunLoopDefaultMode, 10, YES);

    }
    while (self.isNeedToExit == false);

    [pool release];

    SYSLOG(LOG_DEBUG, "thread exiting");
}

I'm doing animation with performSelector:withObject:afterDelay at 24fps.
(reason being, UIImageView doesn't support different interval between images)
When I run multiple animations simultaneously, seems like message queued by performselector takes long time to be picked up.

I am wondering NSTimer or yet another would be a better choice.

Thank you

  • EDIT

I'm not doing anything besides running animation.
The selector I'm running takes up 0.0003 ish time.(almost no time)
But when I measure time between calling "performSelector" and the time the selector actually gets called, the time actually is longer than I specified with "afterDelay" or "scheduledTimerWithDuration"

I looked at instruments already but couldn't figure out what's causing the delay.
I just saw thread related(i guess thread pause/resume) activity a lot.
Maybe my below threadMain code is taking up much time?

- (void) myThreadMain
{
    NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];

    // Add your sources or timers to the run loop and do any other setup.                                                                                                                                                                                                     
    NSRunLoop *runloop = [NSRunLoop currentRunLoop];
    [runloop addPort:[NSMachPort port] forMode:NSDefaultRunLoopMode];

    do
    {
        // Start the run loop but return after each source is handled.                                                                                                                                                                                                        
        SInt32    result = CFRunLoopRunInMode(kCFRunLoopDefaultMode, 10, YES);

    }
    while (self.isNeedToExit == false);

    [pool release];

    SYSLOG(LOG_DEBUG, "thread exiting");
}

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

南薇 2024-10-23 07:26:11

苹果说:

此方法 [performSelector:withObject:afterDelay:] 设置一个计时器以在当前线程的运行循环上执行 aSelector 消息。

所以他们都做同样的事情。你的罪魁祸首在别处。

顺便说一句,您可能想看一下CADisplayLink。它是一个专门的计时器,以与屏幕刷新率相同的频率触发,专门用于听起来像您想要做的事情。

Apple says:

This method [performSelector:withObject:afterDelay:] sets up a timer to perform the aSelector message on the current thread’s run loop.

So they both do the same thing. Your culprit is elsewhere.

By the way, you may want to take a peek at CADisplayLink. It's a specialized timer that fires at the same frequency as the screen refresh rate, intended specifically for what it sounds like you're trying to do.

千柳 2024-10-23 07:26:11

由于所有选择器/方法共享一个 CPU 和一个运行循环(UI 运行循环,除非您另外指定),因此如果发生太多事情,计时器和延迟选择器都将被延迟调用。您需要分析您的应用程序(仪器)以查看哪些内容占用了时间,从而导致其他事情延迟。

Since all the selectors/methods share one CPU and one run loop (the UI run loop, unless you specify otherwise), both timers and delayed selectors will get called late if there is too much going on. You need to profile your app (instruments) to see what's taking up the time, and thus making other things late.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文