performSelector:withObject:afterDelay: 和 dispatch_after 之间的权

问题描述

我遇到的唯一功能差异是我可以取消使用 performSelector:withObject:afterDelay: 安排的消息.我不知道有什么方法可以取消提交给 dispatch_after 的块.(如果有我不知道的方法，请告诉我).

我想了解更多:

• 功能权衡(用一个接口而不是另一个接口可以实现什么?)
• 性能权衡(一种实现更有效吗?在哪些情况下?)
• 风格上的权衡(我是否应该为某些任务选择一个界面以更好地遵循常见的风格或约定?)

dispatch_after 是新 Grand Central Dispatch，它是 iOS 的一个扩展，旨在改进多核硬件上的并发代码执行.

但总的来说，我认为它们总体上满足了不同的需求.GCD 允许对代码的并发执行进行更精细的分级控制.您可以在队列中调度块、删除它们、暂停、恢复等.通常，这是一个更广泛的主题.此外，GCD 提供了更多的同步选项.

就与 performSelector 的比较而言，我认为 dispatch_after 的一个优点是可以调度块而不需要定义选择器.请参阅此讨论.p>

总的来说，我对 GCD 没有太多经验，但我想说的是，除了块调度之外，当您只需要延迟 UI 中的某些选择器执行时，通常对并发性没有太多要求，我会使用 performSelector.

如果你想一想，performSelector 给你的并发性很差，因为它只是安排你的选择器在最短时间后在运行循环上执行.另一方面， dispatch_after 为您提供了一个原则上似乎在纳秒级别的控制(！！这是我从 Apple 文档中得到的，但我从未使用过它，我不认为在 iPhone 上你会得到那个，可能在 MacOS 上).

关于取消调度一个块，我从未尝试从队列中取消调度一个块，但是 dispatch_release 也有可能允许您控制它.如果没有，您可以为要取消的块定义自定义队列并释放整个队列(在块开始执行之前)，如果这对您有意义的话.

至于性能，我真的不知道performSelector里面做了什么，但是如果它调度一个线程，那么Apple 声明使用 GCD 调度一个块只需 15 条指令，而创建线程则需要数百条指令.

除了performSelector，别忘了你可以选择使用NSOperationQueue，它是基于GCD的，有一些开销，但不是很大，他们说.NSOperationQueue 当然提供了取消的可能性.

The only functional difference I have encountered is that I can cancel the message scheduled with performSelector:withObject:afterDelay:. I don't know of a way to cancel a block submitted to dispatch_after. (Please let me know if there is a way to do this that I do not know about).

I'd like to know more about:

• functional tradeoffs (What else can be accomplished with one interface but not the other?)
• performance tradeoffs (Is one implementation more efficient? In which cases?)
• stylistic tradeoffs (Should I prefer one interface for certain tasks to better follow common styles or conventions?)

dispatch_after is part of the new Grand Central Dispatch, which is an extension to iOS aimed at improving concurrent code execution on multicore hardware.

But overall, I think they address different requirements overall. GCD allows to a much finer graded control over concurrent execution of code. You can schedule blocks on a queue, remove them, suspend, resume, etc. It is a broader topic to be considered here in general. Also, GCD provides many more synchronization options.

As far as the comparison with performSelector, I think that one advantage dispatch_after rightly has is the possibility of scheduling a block without the need to define a selector. See this discussion.

On in all, I haven't got much experience with GCD, but I would say that apart from the block scheduling thing, when you simply need to delay some selector execution in your UI, without much a requirement for concurrency in general, I would use performSelector.

If you think about it, performSelector gives you a very poor concurrency, since it simply schedules your selector for execution on the run loop after a minimum amount of time. On the other hand, dispatch_after gives you a control which seems in principle at the level of nanoseconds (!! this is what I get from Apple docs, but I have never used it and I don't think that on an iPhone you would get that, possibly on MacOS).

EDIT: about unscheduling a block, I have never tried to unschedule a block from a queue, but there is a possibility that dispatch_release also allows you to control that. If it does not, you could define your custom queue for the block that you want to cancel and release the whole queue (before the block starts being executed), if that ever makes sense to you.

As to performance, I really don't know what performSelector does inside, but if it schedules a thread, then Apple states that scheduling a block with GCD only costs 15 instructions, while creating a thread costs several hundred of them.

Apart from performSelector, don't forget you have the option of using NSOperationQueue, which is based on GCD, and has some overhead overt it but not that big, they say. NSOperationQueue certainly offers the possibility of cancelling.

这篇关于performSelector:withObject:afterDelay: 和 dispatch_after 之间的权衡是什么的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持跟版网！