QMUI_iOS中QMUIModalPresentationViewController内存泄漏问题解析

问题背景

在使用QMUI_iOS框架中的QMUIModalPresentationViewController时，开发者可能会遇到一个典型的内存泄漏问题。这个问题表现为：当使用自定义视图作为模态弹窗的内容视图时，该视图及其关联的控制器无法被正确释放，导致内存持续占用。

问题现象分析

从开发者提供的代码示例中可以看到，他们创建了一个自定义的QMUIAlertView类，该类内部持有一个QMUIModalPresentationViewController实例，同时又将自身设置为该模态控制器的contentView。这种设计模式形成了一个典型的循环引用：

1. QMUIAlertView实例持有modal属性（QMUIModalPresentationViewController实例）
2. modal的contentView属性又反向持有QMUIAlertView实例

这种双向强引用关系导致ARC（自动引用计数）无法在适当的时候释放这两个对象，从而造成内存泄漏。

循环引用的本质

在iOS开发中，循环引用是指两个或多个对象相互持有强引用，形成一个引用环，导致这些对象都无法被释放。在Swift/Objective-C的内存管理机制下，当对象的引用计数降为0时才会被释放。循环引用阻止了引用计数的归零过程。

解决方案

方案一：使用weak打破循环

最优雅的解决方案是使用weak弱引用来打破循环。我们可以将modal属性声明为weak：

private weak var modal: QMUIModalPresentationViewController?

但需要注意，QMUIModalPresentationViewController通常需要被强引用才能保持显示状态，所以这种方法可能不适用所有场景。

方案二：手动解除引用

在适当的时候（如弹窗关闭时）手动解除引用关系：

@objc public func hide() {
    if let window = UIApplication.shared.keyWindow {
        modal?.hide(in: window, animated: true)
    }
    // 解除循环引用
    modal?.contentView = nil
    modal = nil
}

这种方法虽然有效，但需要开发者精确控制生命周期，否则可能导致崩溃。

方案三：重构设计模式

更合理的做法是重构设计，避免视图和控制器相互持有：

1. 将QMUIModalPresentationViewController的创建和管理职责交给调用方
2. 让QMUIAlertView只负责视图展示逻辑
3. 使用闭包或委托模式处理交互事件

示例重构：

class QMUIAlertView: UIView {
    var hideHandler: (() -> Void)?
    
    @objc private func hide() {
        hideHandler?()
    }
}

// 使用方
let alertView = QMUIAlertView()
let modal = QMUIModalPresentationViewController()
modal.contentView = alertView
alertView.hideHandler = { [weak modal] in
    modal?.hide(in: window, animated: true)
}

最佳实践建议

1. 明确职责分离：视图只负责展示，控制器管理生命周期
2. 谨慎使用双向引用：尽量避免对象间的双向强引用
3. 合理使用weak/unowned：在闭包和委托模式中正确使用弱引用
4. 内存泄漏检测：定期使用Xcode的内存图工具或Instruments检查内存泄漏
5. 生命周期管理：为复杂组件设计清晰的创建和销毁流程

总结

QMUIModalPresentationViewController本身并无内存泄漏问题，问题源于不当的使用方式导致了循环引用。理解iOS内存管理机制，合理设计组件间的引用关系，是避免这类问题的关键。通过重构设计模式，明确各组件职责，可以有效解决内存泄漏问题，提升应用稳定性和性能。