TLDR：我想知道基于运行循环的UndoManager自动撤销分组是如何在使用后台线程时实现的，以及我最好的选择是什么。
我在自定义Swift框架中使用UndoManager（以前的NSUndoManager），其中包含iOS和macOS的目标。
在框架内，在后台GCD串行队列上进行了大量的工作。据我所知，UndoManager会自动将每个运行循环周期的顶级注册撤消操作分组，但我不确定不同的线程情况会如何影响。
我的问题：
UndoManagers运行循环分组注册撤消操作产生什么影响？在以下所有情况下，假设methodCausingUndoRegistration()和anotherMethodCausingUndoRegistration()都没什么特别的，并且在没有任何调度的情况下从调用它们的线程调用UndoManager.registerUndo。
// Assume this runs on main thread
methodCausingUndoRegistration()
// Other code here
anotherMethodCausingUndoRegistration()
// Also assume every other undo registration in this framework takes place inline on the main thread
我的理解：这就是UndoManager期望被使用的方式。上述两个撤销注册都将在相同的运行循环周期中进行，因此可以放在同一个撤消组中。
// Assume this runs on an arbitrary background thread, possibly managed by GCD.
// It is guaranteed not to run on the main thread to prevent deadlock.
DispatchQueue.main.sync {
methodCausingUndoRegistration()
}
// Other code here
DispatchQueue.main.sync {
anotherMethodCausingUndoRegistration()
}
// Also assume every other undo registration in this framework takes place
// by syncing on main thread first as above
我的理解：显然，我不想在生产中使用这个代码，因为在大多数情况下同步调度并不是一个好主意。但是，我怀疑这两个动作有可能根据时序考虑进入单独的运行循环周期。
// Assume this runs from an unknown context. Might be the main thread, might not.
DispatchQueue.main.async {
methodCausingUndoRegistration()
}
// Other code here
DispatchQueue.main.async {
anotherMethodCausingUndoRegistration()
}
// Also assume every other undo registration in this framework takes place
// by asyncing on the main thread first as above
我的理解：尽管我希望能够产生与情况1相同的效果，但我怀疑它可能会导致类似于情境2的未定义分组。
// Assume this runs from an unknown context. Might be the main thread, might not.
backgroundSerialDispatchQueue.async {
methodCausingUndoRegistration()
// Other code here
anotherMethodCausingUndoRegistration()
}
// Also assume all other undo registrations take place
// via async on this same queue, and that undo operations
// that ought to be grouped together would be registered
// within the same async block.
我的理解：我真的希望只要UndoManager在同一个后台队列中使用，它就会和情境1一样。但是，我担心可能有一些因素导致分组未定义，特别是因为我不认为GCD队列（或它们的托管线程）总是（如果有的话）获得运行循环。
TLDR：当从后台线程使用UndoManager时，最简单的选项是简单地通过groupsByEvent禁用自动分组并手动执行。上述情况都不会按预期工作。如果你真的想在后台自动分组，你需要避免使用GCD。
我将添加一些背景来解释期望，然后根据我在Xcode Playground中所做的实验，讨论每种情况下实际发生的情况。
Apple的Cocoa Application Competencies for iOS指南中的“撤消经理”章节指出：
NSUndoManager通常在运行循环的循环期间自动创建撤消组。第一次要求它在循环中记录撤消操作时，它会创建一个新组。然后，在周期结束时，它关闭该组。您可以创建其他嵌套的撤消组。
通过将NotificationCenter作为NSUndoManagerDidOpenUndoGroup和NSUndoManagerDidCloseUndoGroup的观察者注册自己，可以在项目或游乐场中轻松观察到这种行为。通过观察这些通知并将结果打印到控制台（包括undoManager.levelsOfUndo），我们可以实时查看分组的具体信息。
该指南还指出：
撤消管理器收集在运行循环的单个循环内发生的所有撤消操作，例如应用程序的主事件循环......
这种语言表明主运行循环不是UndoManager能够观察的唯一运行循环。最有可能的是，UndoManager会观察代表CFRunLoop实例发送的通知，这些通知是在记录第一个撤消操作并打开组时的当前状态。
尽管Apple平台上的运行循环的一般规则是“每个线程一个运行循环”，但此规则也有例外。具体而言，人们普遍认为Grand Central Dispatch并不总是（如果有的话）使用标准的CFRunLoops及其调度队列或其相关的线程。事实上，似乎有一个关联的CFRunLoop的唯一调度队列似乎是主队列。
Apple的Concurrency Programming Guide声明：
主调度队列是一个全局可用的串行队列，它在应用程序的主线程上执行任务。此队列与应用程序的运行循环（如果存在）一起工作，以将排队任务的执行与附加到运行循环的其他事件源的执行交错。
有意义的是，主应用程序线程并不总是有一个运行循环（例如命令行工具），但如果确实如此，似乎可以保证GCD将与运行循环协调。此保证似乎不存在于其他调度队列中，并且似乎没有任何公共API或记录的方式将任意调度队列（或其基础线程之一）与CFRunLoop相关联。
使用以下代码可以观察到：
DispatchQueue.main.async {
print("Main", RunLoop.current.currentMode)
}
DispatchQueue.global().async {
print("Global", RunLoop.current.currentMode)
}
DispatchQueue(label: "").async {
print("Custom", RunLoop.current.currentMode)
}
// Outputs:
// Custom nil
// Global nil
// Main Optional(__C.RunLoopMode(_rawValue: kCFRunLoopDefaultMode))
RunLoop.currentMode的文档说明：
此方法仅在接收器运行时返回当前输入模式;否则，它返回零。
由此，我们可以推断全局和自定义调度队列并不总是（如果有的话）有自己的CFRunLoop（这是RunLoop背后的潜在机制）。因此，除非我们派遣到主队列，否则UndoManager将没有活跃的RunLoop来观察。这对情况4及其后的情况非常重要。
现在，让我们使用Playground（使用PlaygroundPage.current.needsIndefiniteExecution = true）和上面讨论的通知观察机制观察每种情况。
这正是UndoManager期望使用的方式（基于文档）。观察撤消通知会显示一个撤消组，其中包含两个撤消内部。
在使用这种情况的简单测试中，我们将每个撤销注册都放在其自己的组中。因此，我们可以得出结论，这两个同步调度的块每个都在它们自己的运行循环周期中发生。这似乎总是行为调度同步在主队列上产生的。
但是，当使用async时，一个简单的测试显示出与情况1相同的行为。似乎因为两个块都被分派到主线程之前有可能实际上由运行循环运行，所以运行循环执行了两个块在同一个循环中。因此，两个撤销注册都放在同一组中。
纯粹基于观察，这似乎引入了sync和async的细微差别。因为sync阻塞当前线程直到完成，所以运行循环必须在返回之前开始（并结束）一个循环。当然，然后，运行循环将无法在同一周期中运行另一个块，因为当运行循环开始并查找消息时它们不会存在。但是，使用async，运行循环可能不会开始，直到两个块都已排队，因为async在工作完成之前返回。
基于这种观察，我们可以通过在两个sleep(1)调用之间插入async调用来模拟情境3中的情境2。这样，运行循环有机会在第二个块发送之前开始其循环。这确实会导致创建两个撤消组。
这是事情变得有趣的地方。假设backgroundSerialDispatchQueue是GCD自定义串行队列，则会在第一次撤消注册之前立即创建单个撤消组，但它永远不会关闭。如果我们考虑上面关于GCD和运行循环的讨论，这是有道理的。创建撤消组只是因为我们调用了registerUndo并且还没有顶级组。但是，它从未关闭过，因为它从未收到有关结束循环的运行循环的通知。它从来没有得到通知，因为背景GCD队列没有得到与它们相关的功能性CFRunLoops，所以UndoManager可能从来没有能够首先观察到运行循环。
如果在后台线程中使用UndoManager是必要的，则上述情况都不是理想的（除了第一个，不符合在后台触发的要求）。有两种选择似乎有效。两者都假设UndoManager只能在同一个后台队列/线程中使用。毕竟，UndoManager不是线程安全的。
可以通过undoManager.groupsByEvent轻松关闭基于运行循环的自动撤消分组。然后可以像这样实现手动分组：
undoManager.groupsByEvent = false
backgroundSerialDispatchQueue.async {
undoManager.beginUndoGrouping() // <--
methodCausingUndoRegistration()
// Other code here
anotherMethodCausingUndoRegistration()
undoManager.endUndoGrouping() // <--
}
这完全符合预期，将两个注册放在同一组中。
在我的生产代码中，我打算简单地关闭自动撤消分组并手动完成，但我确实在调查UndoManager的行为时发现了另一种选择。
我们之前发现UndoManager无法观察到自定义GCD队列，因为它们似乎没有相关的CFRunLoops。但是，如果我们创建了自己的Thread并设置了相应的RunLoop。从理论上讲，这应该有效，下面的代码演示了：
// Subclass NSObject so we can use performSelector to send a block to the thread
class Worker: NSObject {
let backgroundThread: Thread
let undoManager: UndoManager
override init() {
self.undoManager = UndoManager()
// Create a Thread to run a block
self.backgroundThread = Thread {
// We need to attach the run loop to at least one source so it has a reason to run.
// This is just a dummy Mach Port
NSMachPort().schedule(in: RunLoop.current, forMode: .commonModes) // Should be added for common or default mode
// This will keep our thread running because this call won't return
RunLoop.current.run()
}
super.init()
// Start the thread running
backgroundThread.start()
// Observe undo groups
registerForNotifications()
}
func registerForNotifications() {
NotificationCenter.default.addObserver(forName: Notification.Name.NSUndoManagerDidOpenUndoGroup, object: undoManager, queue: nil) { _ in
print("opening group at level \(self.undoManager.levelsOfUndo)")
}
NotificationCenter.default.addObserver(forName: Notification.Name.NSUndoManagerDidCloseUndoGroup, object: undoManager, queue: nil) { _ in
print("closing group at level \(self.undoManager.levelsOfUndo)")
}
}
func doWorkInBackground() {
perform(#selector(Worker.doWork), on: backgroundThread, with: nil, waitUntilDone: false)
}
// This function needs to be visible to the Objc runtime
@objc func doWork() {
registerUndo()
print("working on other things...")
sleep(1)
print("working on other things...")
print("working on other things...")
registerUndo()
}
func registerUndo() {
let target = Target()
print("registering undo")
undoManager.registerUndo(withTarget: target) { _ in }
}
class Target {}
}
let worker = Worker()
worker.doWorkInBackground()
正如预期的那样，输出表明两个undos都放在同一个组中。 UndoManager能够观察周期，因为Thread使用的是RunLoop，与GCD不同。
但老实说，坚持使用GCD并使用手动撤销分组可能更容易。