为何在viewDidAppear调用fitLayers会内存泄漏，viewWillLayoutSubviews则不会？

这是个很典型的布局生命周期与内存管理冲突的问题，咱们从几个维度拆解分析：

1. 两个生命周期方法的核心差异 #

首先得明确这两个回调的时机和系统处理逻辑：

• viewWillLayoutSubviews：这个方法触发时，视图的布局还处于动态调整阶段，系统的布局循环尚未结束。此时你修改图层frame，系统会把这个操作纳入到整体布局流程中，自动管理图层的引用关系，布局完成后会清理临时的引用计数变化，不会让引用固化。
• viewDidAppear：这个方法在视图完全显示、布局彻底稳定后触发。此时系统已经完成了所有布局相关的内部处理，图层树的状态被固定下来。你此时手动修改图层frame，相当于在系统布局周期外操作，任何引用关系的变化都不会被系统的自动清理机制处理，容易导致引用无法被打破。

2. 你的递归fit方法的潜在问题 #

看你写的CALayer扩展：

extension CALayer { 
    func fit(rect: CGRect) { 
        frame = rect 
        sublayers?.forEach { $0.fit(rect: rect) } 
    } 
}

这里的递归遍历子图层并设置frame，在布局稳定的viewDidAppear阶段，很容易触发循环引用：

• 如果某个子图层的delegate指向了父视图（比如你给子图层设置过代理处理绘制），父视图的layer又通过sublayers强持有这个子图层，就形成了父视图 -> 父图层 -> 子图层 -> 父视图的双向强引用链。
• 在viewWillLayoutSubviews时，系统还在调整布局，会暂时解除这类临时引用，让对象可以被释放；但在viewDidAppear阶段，布局已经稳定，这个引用链会被固化，导致图层对象无法被ARC回收，从而引发内存泄漏。

3. 解决方案 #

方案一：遵循系统布局生命周期（推荐） #

尽量把图层布局调整放在专门的布局回调中，比如viewWillLayoutSubviews或者重写layoutSubviews，让系统帮你处理引用管理：

override func viewWillLayoutSubviews() {
    super.viewWillLayoutSubviews()
    priorityButton.fitLayers()
}

或者直接重写按钮的layoutSubviews：

class PriorityButton: UIButton {
    override func layoutSubviews() {
        super.layoutSubviews()
        fitLayers()
    }
}

方案二：修改递归逻辑避免循环引用 #

如果你一定要在viewDidAppear中调用，可以给递归遍历加上弱引用检查，防止引用链固化：

extension CALayer { 
    func fit(rect: CGRect) { 
        frame = rect 
        sublayers?.forEach { [weak self] layer in
            // 检查当前图层是否还存在，避免循环引用
            guard self != nil else { return }
            layer.fit(rect: rect) 
        } 
    } 
}

方案三：用Memory Graph Debugger定位具体泄漏链 #

你可以打开Xcode的Memory Graph Debugger，查看泄漏的图层对象的引用链，确认是不是某个子图层的代理、关联对象或者其他强引用导致的循环，这样能更精准地解决问题。

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