iOS平台UndoManager持久化实现及跨启动撤销重做问题咨询

注意：苹果官方提供的UndoManager没有公开内部操作栈的读写接口，也不支持序列化归档，直接存储UndoManager实例会失败，必须自行维护可持久化的操作存储结构。

• 定义可序列化的操作模型
  把每一步可撤销操作抽象为支持Codable（Swift）或NSSecureCoding（Objective-C）的结构体/类，至少需要包含操作类型、操作作用范围、操作前后的内容、关联的控件标识、时间戳几个核心字段，示例代码如下：

struct TextEditOperation: Codable {
    enum OperationType: Int, Codable {
        case insert, delete, replace
    }
    let type: OperationType
    let range: NSRange
    let oldText: String
    let newText: String
    let fieldID: String // 标记操作对应的TextField
    let timestamp: TimeInterval
}

• 自行维护双栈结构
  在自定义文档类中额外维护两个数组作为操作栈：undoStack: [TextEditOperation]存储可撤销操作，redoStack: [TextEditOperation]存储可重做操作。所有通过UndoManager注册的操作，都需要同步写入这两个数组中，UndoManager仅负责运行时的撤销/重做逻辑调度。

• 持久化操作栈
  每次操作栈发生变更（新增操作、执行撤销/重做）时，将两个栈序列化为JSON或plist文件，存储到对应文档的专属沙盒目录下，和文档本体绑定存储。

• 绑定TextField和操作
  给每个TextField设置唯一的fieldID，在TextField的文本变更回调中生成对应的TextEditOperation实例，一方面调用UndoManager的registerUndo方法注册撤销逻辑，另一方面将操作写入自定义的undoStack，同时清空redoStack。

• 启动时重建UndoManager状态
  应用启动、打开文档时，先读取对应文档持久化的undoStack和redoStack数据，倒序遍历undoStack的所有操作，依次给UndoManager重新注册撤销回调，确保运行时的操作顺序和应用重启前完全一致。

• 处理边界校验

  • 限制操作栈的最大长度（比如最多保存50步操作），避免持久化文件过大，栈满时自动移除栈底的最早操作
  • 执行撤销/重做操作时，同步更新对应TextField的文本内容和光标位置，避免内容和操作栈不同步
  • 检测到文档内容被外部修改时，直接清空所有操作栈，避免撤销操作导致内容错乱

内容的提问来源于stack exchange，提问作者Deepak Sharma