QMUIKit中QMUIModalPresentationViewController内存泄漏问题解析

问题背景

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

问题现象

通过内存检测工具可以观察到，当使用自定义视图（如QMUIAlertView）作为QMUIModalPresentationViewController的contentView时，即使关闭弹窗，相关对象也不会被释放。控制台中的deinit方法不会被调用，表明存在内存泄漏。

问题根源分析

经过深入分析，这个问题本质上是一个典型的循环引用问题：

1. QMUIAlertView实例持有一个QMUIModalPresentationViewController实例（modal属性）
2. QMUIModalPresentationViewController又反过来持有QMUIAlertView实例（通过contentView属性）
3. 两者相互强引用，形成一个引用环，导致ARC无法释放任何一方

解决方案

方案一：使用weak打破循环引用

最优雅的解决方案是使用weak弱引用来打破循环：

private weak var modal: QMUIModalPresentationViewController?

这样修改后，QMUIAlertView对modal的引用变为弱引用，不会阻止modal被释放。当外部没有其他强引用时，整个引用链可以被正确释放。

方案二：手动解除引用

在适当的时候手动解除引用关系：

@objc public func hide() {
    if let window = UIApplication.shared.keyWindow {
        modal?.hide(in: window, animated: true)
    }
    modal?.contentView = nil
    modal = nil
}

这种方法虽然可行，但需要开发者非常小心地管理生命周期，容易出错。

方案三：使用闭包封装

将弹窗逻辑封装到闭包中，利用闭包的生命周期自动管理内存：

func showAlert() {
    let alert = QMUIAlertView()
    let modal = QMUIModalPresentationViewController()
    modal.contentView = alert
    modal.show(in: UIApplication.shared.keyWindow!, animated: true)
}

这种方式利用了局部变量的自动释放机制，但会限制一些使用场景。

最佳实践建议

1. 优先使用weak方案：这是最符合Swift内存管理理念的方案，代码清晰且不易出错。

2. 注意生命周期管理：确保在不需要弹窗时及时调用hide方法。

3. 避免全局持有：尽量不要将modal控制器长期保存在全局变量或单例中。

4. 使用内存检测工具：定期使用Xcode的内存图工具或Instruments检查内存泄漏。

深入理解

这个问题很好地展示了iOS开发中常见的内存管理陷阱。理解ARC的工作原理对于避免这类问题至关重要：

• 强引用会使引用计数+1
• 弱引用不会增加引用计数
• 循环引用会导致引用计数永远不为0
• deinit方法只在对象被释放时调用

QMUIKit作为优秀的UI框架，其设计本身没有问题。开发者需要理解框架的使用方式，合理管理对象之间的关系。

总结

内存管理是iOS开发中的核心技能之一。通过这个QMUIModalPresentationViewController的内存泄漏案例，我们不仅学会了如何解决具体问题，更重要的是理解了循环引用的原理和预防方法。在实际开发中，养成良好的内存管理习惯，合理使用weak/unowned修饰符，可以避免大多数内存泄漏问题。