ios - 为什么 UI 事件在 Swift/Objective-C 中不是线程安全的？

Question

所以我开始学习 Grand Central Dispatch 的基础知识以及 iOS 应用程序多线程的整个概念。每个教程都会告诉你必须在主线程上运行 UI 事件，但我不完全明白为什么。

这是我昨天遇到的一个问题，最后通过在主线程上运行 segue 解决了它，但我仍然不明白为什么在主线程上运行它会出现问题:

我有一个自定义的初始 VC(条形码扫描仪)和一个连接到新 View Controller 的连接，并附有 UIWebView。一旦 VC 找到条形码，它就会调用处理程序，在那个闭包中，我有一个 performSegueWithIdentifier。然而，我得到了一个 EXC_BAD_ACCESS 因为这个(当第二个 VC 有一个标签或一个 UIImageView 时，它没有发生，只有 UIWebView ).我终于意识到，由于某种原因，闭包在主线程之外被调用，因此 segue 是在主线程之外执行的。为什么在另一个线程上执行 segue 会引发内存错误？是因为 self.performSegueWithIdentifier 中的 self 不知何故为零吗？为什么 Swift 不会在主线程上自动分派(dispatch)一个 segue 事件？

Answer 1

有趣的问题!崩溃与 UIKit 无关。这是 UIWebView 特有的崩溃。查看堆栈跟踪，异常发生在 WebCore::FloatingPointEnvironment::saveMainThreadEnvironment 函数中，它是 WebKit 初始化进程的一部分。由于 WebKit 管理自己的线程执行环境，因此它需要一个明确的起点(即主线程)来构建这个环境是有道理的。

在 main 以外的线程上执行的 UIKit 操作(如呈现 View Controller )不会导致异常，但它们会被延迟(取决于调度队​​列的 QoS)。

至于为什么 UIKit 操作没有自动分配到主队列上，我只能推测在库调用中添加额外检查会增加太多冗余工作，只需遵循约定即可避免。

有关 UIKit 和主线程的更详细讨论，请参阅此答案:Why must UIKit operations be performed on the main thread?

简短的回答是，所有修改应用 UI 的操作都需要集中在一个地方进行评估，以定期(特别是 V-Sync 间隔)生成下一帧。跟踪所有变异状态需要所有更改同步发生，并且出于性能原因，所有这些操作通常都进行批处理并每帧执行一次(同时还与 GPU 协调)。