0

顺便说一句：这主要是参考 iOS 6+：

我有一个应用程序——从应用程序的许多不同地方——执行一个可以安全地后台运行的功能，并且是线程安全的。我不希望在执行此功能时停止系统，因此不要将其称为：[self functionName];当前我以较短的间隔触发 NSTimer：

 [NSTimer scheduledTimerWithTimeInterval:.5 target:self selector:@selector(doThis:) userInfo:@"someString" repeats:NO];

我的问题是：我已经开始为此调查 NSNotification 仅仅是因为我讨厌计时器的想法......他们似乎在排队并且不让系统决定（在我看来）执行它们的顺序。FIFO 与大多数他们……或者——事实上——同时发生。你永远不会知道。因此，NSNotification 出现了：

[[NSNotificationCenter defaultCenter] postNotificationOnMainThreadName:@"doThis" object:nil userInfo:[NSDictionary dictionaryWithObjectsAndKeys:@"a",@"varA",@"b",@"varB",nil]];

现在，哪个对系统更有利……在资源方面，真的，在所有方面？NSTimer 还是 NSNotification？

显然 NSNotification 的好处是一旦在 appDelegate 中定义——可以从应用程序的任何方面调用。NSTimer 可以做到这一点，但它需要必要的“目标”......查找目标的几行额外的行等。

建议？

4

2 回答 2

2

计时器和通知都不适用于此。只需在后台运行该方法。你有几个选择：

[self performSelectorInBackground:@selector(doThis:) withObject:@"someString"];

后台线程需要使用自动释放池正确设置。假设您使用的是 ARC，请确保您的doThis:方法如下所示：

- (void)doThis:(NSString *)someParam {
    @autoreleasepool {
        // rest of the code here
    }
}

更好的是，使用 GCD（Grand Central Dispatch）而不是使用performSelectorInBackground:withObject:：

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
    [self doThis:@"someString:];
});

doThis:如果不做任何更新用户界面的事情，这工作正常。如果doThis:确实需要在某个时候更新用户界面，那么界面代码必须在主线程上完成。该代码应包含在：

dispatch_async(dispatch_get_main_queue(), ^{
    // perform UI update here
});
于 2013-05-10T17:10:05.910 回答
0

NSTimer 是错误的，而且一直都是。计时器与正在发生的事情没有任何关系：你只是在猜测0.5 秒后一切都会结束，我们可以继续。不要通过猜测进行编程。如果我们需要知道某个方法何时结束，则响应该方法结束。

于 2013-05-10T18:16:28.923 回答