msk*_*skw 0 user-interface objective-c grand-central-dispatch ios
告诉我这是否有意义.这是一个iOS问题.
我看到它已经存在于主线程中的代码,但是代码会将各种UI代码分配给主线程的队列.布局,动画等
有人告诉我一些如何加快响应速度(例如,当推送视图控制器时,你会在那里调度其他UI操作,因此它不会阻止推送转换.
这没有意义,因为首先它是危险的,其次,它不保证UI代码何时运行(即使它可能以毫秒运行).我能看到的唯一好理由是它保证UI代码不会意外地在不同的线程中运行.
你们有什么感想?
肯定有一些时候你会使用这种调度回主队列的模式,所以我可能不会太快解除它或将其标记为"危险"(尽管你表征它的方式,它确实听起来很可疑).您应该共享一些代码示例,了解您如何看待使用此模式,我们可以进一步发表评论.
你什么时候派遣到主队列?原型示例是当您在后台队列上执行某些操作时,但是然后想要将UI更新分派回主队列,例如:
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
// do something time consuming here, like network request or the like
// when done, update the UI on the main queue:
dispatch_async(dispatch_get_main_queue(), ^{
// update the UI here
});
});
Run Code Online (Sandbox Code Playgroud)
但我假设这不是你正在谈论的主要队列的派遣.我假设从你的评论中你在主队列上有东西异步调度回到主队列本身.
你这样做的原因是你不希望调度代码立即运行,而是排队等待运行循环的下一次迭代.这允许自动释放池耗尽,让当前方法完成(并释放它可能已经使用的任何资源),让其他调度任务先运行,让UI有机会反映您可能已启动的任何更改,等等.
一些开发人员可能会这样做的一些例子包括:
如果你想要一个递归的方法调用本身,你可能会使用这种模式,但你想要回到运行循环,让资源被释放,让UI反映任何变化等等.你基本上说"好吧,让这个方法完成,但在下一个运行循环中,再次运行此方法."
更viewDidLoad令人怀疑的是,我已经看到了这种模式,你想让自动布局有机会"赶上"并更新帧.例如,如果您只是从中调用它viewDidLoad,则会有一个常见的第三方进度指示器无效,但如果您将该更新发送回主队列,则它可以正常工作.
我已经看到了为什么我看到开发人员从主队列调回主队列的原因,我必须承认这些模式中的许多都受到代码嗅觉的影响,并且通常通过不同的模式更好地完成.但这些是我见过的几个例子.
但是,如果您需要有关特定代码示例的帮助,则必须与我们分享.如果没有看到代码示例,我们无法分辨开发人员的意图.
| 归档时间: |
|
| 查看次数: |
1630 次 |
| 最近记录: |