dispatch_after recursion vs NSTimer scheduledtimerwithtimeinterval

Question

我读了一段代码，它每秒都会检查数据并更新UI。这听起来像我们通常使用include_path做的事情。但是这个代码是通过递归调用NSTimer scheduledtimerwithtimeinterval实现的，如下所示：

dispatch_after

dispatch_after recursion 和 NSTimer scheduledtimerwithtimeinterval 之间有什么区别？使用前者时是否存在潜在风险？我想当你使用它时，只要不结束这种递归，调用栈就会增长。

Answer 1

NSTimer：

1. Need a NSRunloop.
2. Can repeat.
3. Can be invalid anytime if u want to cancel.
4. Can only run with delegate.
5. High level API.

dispatch_after：

1. Can be run everywhere that u want with dispatch_queue.
2. Can't repeat by itself.
3. Can't be cancel.
4. It run as block.
5. GCD.

Answer 2

您的代码实际上没有任何递归。在您的情况下使用dispatch_after的行为类似于使用NSTimer。

使用dispatch_after，对retriggerMethod的下一次调用来自执行排队的GCD。所以你没有在电话中打电话 - 这里没有递归。

所以就递归而言，没有风险。虽然在这种情况下使用NSTimer似乎更合理，如果有必要，可以更容易取消。

Answer 3

这真的很晚了，但现在还有一些额外的考虑：

1. 消除差异并不是什么大不了的

dispatch_after 确实接受可以像计时器一样轻松取消的工作项。

2. 时光倒流

对于大量重复，dispach_after 递归可能会导致准确性下降很多。每个滑动都复合到下一个递归中，因为下一个递归仅在执行前一个递归之后设置。比如说 dispatch_after 可能会滑到 10 毫秒。这意味着在 100 次递归之后，它可能会滑到 1 秒。

相比之下，虽然 NSTimer 的每个滴答声也可能最多关闭 10 毫秒（例如），但后来的滴答声不会滑动超过 10 毫秒，因为每个滴答声时间都是相对于原始计划时间的.