Swift 4 KVO Block崩溃及iOS版本适配后运行异常求助

Hey there, let's work through your two tricky issues one by one—they're both super common when dealing with Swift 4 and iOS version compatibility, so you're not alone here!

一、KVO Block崩溃：被观察对象释放但观察者仍注册 #

Swift 4引入的基于Block的KVO机制依赖于NSKeyValueObservation对象的生命周期管理，这也是很多人踩坑的点。问题根源在于：如果你没有持有返回的NSKeyValueObservation实例，它会被立即释放，导致观察者提前失效；反过来，如果被观察对象先释放，但观察者还在注册状态，就会触发崩溃。

解决办法很直接：

• 必须将NSKeyValueObservation声明为观察者类的实例变量（而不是局部变量），确保它的生命周期和观察逻辑匹配。
• 使用[weak self]避免循环引用，同时在回调里先判断self是否存在。
• 当不需要观察时（比如观察者即将释放，或被观察对象不再需要被监听），调用invalidate()方法取消观察，或者直接将实例变量置为nil（会自动触发invalidate）。

示例代码：

class ViewController: UIViewController {
    // 持有观察对象，避免提前释放
    private var frameObservation: NSKeyValueObservation?
    private var observedView: UIView?

    override func viewDidLoad() {
        super.viewDidLoad()
        let myView = UIView(frame: CGRect(x: 0, y: 0, width: 100, height: 100))
        observedView = myView
        startObservingView()
    }

    func startObservingView() {
        guard let view = observedView else { return }
        // 保存返回的NSKeyValueObservation实例
        frameObservation = view.observe(\.frame, options: [.new, .old]) { [weak self] (observedView, change) in
            guard let self = self else { return }
            // 处理frame变化的逻辑
            print("Old frame: \(change.oldValue?.debugDescription ?? "nil")")
            print("New frame: \(change.newValue?.debugDescription ?? "nil")")
        }
    }

    override func viewWillDisappear(_ animated: Bool) {
        super.viewWillDisappear(animated)
        // 主动取消观察，避免内存问题
        frameObservation?.invalidate()
        frameObservation = nil
        observedView = nil
    }
}

二、iOS 10.3.1模拟器上UITableViewAutomaticDimension崩溃 #

你从iOS 11降级到iOS 9.3后出现崩溃，大概率是因为UITableViewAutomaticDimension在iOS 10及以下的兼容细节没处理好。虽然这个特性从iOS 8就支持，但iOS 11对AutoLayout的容错性更强，一些在iOS 11能正常运行的布局逻辑，在低版本会触发崩溃。

可以从这几个方向排查修复：

1. 确保正确设置estimatedRowHeight #

iOS 10及以下的UITableView依赖estimatedRowHeight来计算自动行高，如果只设置rowHeight = UITableView.automaticDimension而不设置估算高度，很容易出现布局异常甚至崩溃。建议设置一个接近实际行高的估算值：

override func viewDidLoad() {
    super.viewDidLoad()
    tableView.rowHeight = UITableView.automaticDimension
    tableView.estimatedRowHeight = 120 // 根据你的cell实际高度调整
}

2. 检查Cell的约束完整性 #

低版本iOS对AutoLayout约束的要求更严格，必须保证cell的contentView有完整的垂直方向约束链（从top到bottom的约束都要存在），这样系统才能正确计算行高。比如：

• cell内容的顶部必须和contentView.top有约束
• cell内容的底部必须和contentView.bottom有约束
• 所有元素的高度要么固定，要么能通过约束自动计算

如果有动态内容（比如UILabel的多行文本），要确保UILabel的numberOfLines设为0，并且设置了正确的宽度约束。

3. 替换iOS 11+的API兼容低版本 #

你提到已经修复了safeAreaInsets的编译错误，但可能还有遗漏的地方。比如在cell或tableView的布局中用到safeAreaLayoutGuide的话，要做版本判断：

// 示例：设置cell内容的顶部约束
if #available(iOS 11.0, *) {
    contentView.topAnchor.constraint(equalTo: safeAreaLayoutGuide.topAnchor).isActive = true
} else {
    contentView.topAnchor.constraint(equalTo: topAnchor).isActive = true
}

如果用到safeAreaInsets，同样要做兼容：

let topInset = #available(iOS 11.0, *) ? view.safeAreaInsets.top : view.layoutMargins.top

4. 手动触发行高重新计算 #

iOS 11会自动处理动态内容变化后的行高更新，但iOS 10及以下可能需要手动调用更新方法。如果你的cell内容是动态加载的（比如网络请求后更新），在数据刷新后要调用：

// 刷新指定行
tableView.reloadRows(at: [indexPath], with: .automatic)
// 或者全局刷新行高
tableView.beginUpdates()
tableView.endUpdates()

5. 检查UITableViewCell的autoresizingMask #

在iOS 10及以下，UITableViewCell的contentView默认的autoresizingMask可能会导致布局异常。可以在cell的初始化方法里手动设置：

override init(style: UITableViewCell.CellStyle, reuseIdentifier: String?) {
    super.init(style: style, reuseIdentifier: reuseIdentifier)
    contentView.autoresizingMask = [.flexibleWidth, .flexibleHeight]
}

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