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

Question

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

这是我昨天遇到的一个问题,最后通过在主线程上运行segue来修复它,但我仍然不明白为什么从主线程运行它是一个问题:

我有一个自定义的初始VC(条形码扫描仪)和一个带有UIWebView附加的新视图控制器的segue .一旦VC找到条形码,它就会调用一个处理程序,在那个封口中,我有了一个performSegueWithIdentifier.但是,我得到了EXC_BAD_ACCESS,因为这个(当第二VC有一个标签,或者它没有发生UIImageView,只是用UIWebView).我终于意识到由于某种原因,闭包被称为主线程,因此segue正在主线程上执行.为什么要在另一个线程上执行segue会引发内存错误？是因为self在self.performSegueWithIdentifier某种程度上是零吗？为什么Swift不会自动在主线程上发送segue事件？

Answer 1

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

在非线程上执行的UIKit操作(如呈现视图控制器)main不会导致异常,但它们将被延迟(取决于调度队​​列的QoS).

至于为什么UIKit操作没有在主队列上自动分派,我只能推测在库调用中添加额外的检查会增加太多的冗余工作,只需按照惯例就可以避免.

有关UIKit和主线程的更多讨论,请参阅以下答案:为什么必须在主线程上执行UIKit操作？

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