Swift使用带Double?的泛型闭包函数时出现内存泄漏求助

嘿，这个问题我之前也碰到过，确实挺坑的！咱们先搞清楚为什么会出现这种奇怪的内存泄漏，再来看怎么修复。

这个泄漏的根源是Swift编译器在处理**可选数值类型（比如Double?、Int?）**和闭包捕获unowned/weak self时的特殊行为（或者说编译器的小bug）：

• 首先，Double?本质是Optional<Double>，而Double遵循Numeric协议，Swift对这类数值类型的Optional有特殊的底层优化逻辑。
• 当你把捕获了unowned/weak self的闭包存入[(Double?) -> Void]这样的数组时，编译器生成的闭包底层结构会错误地保留对self的强引用——哪怕你明确用了unowned或weak标记。
• 而String?（Optional<String>）不会出现这个问题，是因为String虽然也是值类型，但它不遵循Numeric协议，编译器不会触发那个特殊的优化逻辑，因此闭包能正确处理弱引用/无主引用的捕获。

简单来说，就是数值类型的Optional和闭包捕获列表的组合触发了编译器的内存管理异常，形成了隐性循环引用：数组持有闭包，闭包错误地强持有self，self又持有数组。

这里有几个可靠的修复方法，你可以根据自己的需求选择：

方案1：用自定义类型包装可选数值 #

把Double?包装成一个引用类型（比如简单的Box类），绕过编译器对Numeric Optional的特殊处理：

class ValueBox<T> {
    let value: T?
    init(_ value: T?) {
        self.value = value
    }
}

// 修改observations的类型
var observations = [(ValueBox<Double>) -> Void]()

// 使用时：
observations.append { [unowned self] box in
    print(self)
    if let doubleValue = box.value {
        // 处理数值逻辑
    }
}

这样编译器就不会触发那个异常的优化逻辑，闭包能正确处理unowned self的捕获，避免泄漏。

方案2：调整捕获逻辑显式处理弱引用 #

用weak捕获后在闭包里显式解包，让编译器更清晰地处理引用计数：

// 显式指定闭包类型为@escaping（数组存储的闭包默认是逃逸的，这里写出来更明确）
var observations: [@escaping (Double?) -> Void] = []

func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
    weak var weakSelf = self
    observations.append { new in
        guard let self = weakSelf else { return }
        print(self)
    }
    return true
}

这种方式能强制编译器正确识别弱引用关系，打破隐性的循环引用。

方案3：将闭包逻辑提取为实例方法 #

把闭包里的逻辑单独写成一个实例方法，再把方法作为闭包存入数组，也能绕过这个问题：

var observations = [(Double?) -> Void]()

func handleNewObservation(_ new: Double?) {
    print(self)
}

func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
    observations.append(handleNewObservation)
    return true
}

方法引用的内存管理逻辑更简单直接，不会触发编译器的异常优化。

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