Retain Cycle — esencia, causas y eliminación en el desarrollo de aplicaciones

¿Qué es Retain Cycle?

Retain Cycle es una situación en la que dos o más objetos se poseen mutuamente a través de referencias fuertes, creando un grafo de dependencias cerrado. ARC no puede liberar ninguno de estos objetos porque el retain count de cada uno es siempre ≥ 1: el objeto A retiene a B, B retiene a A, y sus contadores nunca llegan a cero.

El problema ocurre exclusivamente en sistemas con conteo de referencias (ARC, MRR). En Garbage Collection, el recolector determina la inalcanzabilidad a través del grafo de referencias desde el conjunto raíz — los ciclos no son un obstáculo. En ARC, sin embargo, un ciclo equivale a una fuga, porque la liberación determinista mediante conteo no puede resolver dependencias circulares.

Según la WWDC 2012 Session 406, retain cycle es la causa más común de fugas de memoria en aplicaciones Objective-C y Swift. Escenarios típicos: relaciones padre-hijo con delegados, closures que capturan self y arquitecturas en capas con relaciones bidireccionales.

Ejemplos de retain cycle en desarrollo iOS

Examinemos escenarios clásicos de retain cycle que todo desarrollador iOS encuentra. Comprender estos patrones es la base para escribir código seguro con ARC.

Parent-Child con delegado

Escenario clásico: un objeto padre (por ejemplo, UIViewController) crea un objeto hijo y se convierte en su delegado. Si ambos usan referencias fuertes, se produce un retain cycle. La solución — el delegado debe ser weak.

// ERROR: retain cycle a través de delegate fuerte
protocol ChildDelegate: AnyObject { }

class ParentVC: UIViewController, ChildDelegate {
    var child: ChildVC?

    func showChild() {
        child = ChildVC()
        child?.delegate = self        // Parent → Child (strong)
    }                                 // Child → Parent (strong mediante delegate)
}                                     // ⚠️ ¡Retain cycle!

class ChildVC: UIViewController {
    var delegate: ChildDelegate?    // ❌ strong por defecto
}

// SOLUCIÓN: delegate weak
class ChildVC: UIViewController {
    weak var delegate: ChildDelegate? // ✅ weak — no retiene
}

En el ejemplo, ParentVC mantiene una referencia fuerte a ChildVC a través de su propiedad child. ChildVC mantiene una referencia fuerte a ParentVC a través de delegate. El ciclo está cerrado. Solución: weak var delegate — la referencia no aumenta el retain count, y ParentVC puede liberarse.

NSTimer y retain cycle

NSTimer es una fuente clásica de retain cycles. El timer retiene su target (normalmente self), y el target retiene el timer a través de una propiedad. Incluso si el timer es de un solo uso, no se liberará hasta que se llame a invalidate. Solución: llamar siempre a timer.invalidate() en deinit o viewDidDisappear.

Arquitecturas en capas

En arquitecturas con propiedad en cascada (coordinadores, enrutadores), suelen producirse ciclos de múltiples pasos: Coordinator → ViewController → ViewModel → Coordinator (a través de un callback). Cada referencia fuerte en la cadena debe elegirse conscientemente — una referencia weak en cualquier eslabón rompe el ciclo.

Retain Cycle en closures de Swift

Las closures en Swift capturan variables externas por referencia fuerte. Si una closure se almacena como propiedad de un objeto (por ejemplo, un completion handler) y captura self, se crea un retain cycle: self → closure → self.

Esta es la fuente más común de retain cycles en el desarrollo moderno con Swift. Ocurre implícitamente — un desarrollador puede no notar la captura de self en una closure, especialmente cuando se usa sintaxis abreviada sin self explícito.

class DownloadService {
    var onComplete: ((Data) -> Void)?
    var result: Data?

    func startDownload() {
        // ❌ Retain cycle: self → onComplete → self
        onComplete = { data in
            self.result = data
            self.notifyUI()
        }

        // ✅ Solución: capture list con weak self
        onComplete = { [weak self] data in
            guard let self else { return }
            self.result = data
            self.notifyUI()
        }
    }

    func notifyUI() { }
}

Una lista de captura [weak self] crea una referencia débil a self dentro de la closure. Si DownloadService se libera antes de que la closure se ejecute, self se vuelve nil, y el código sale de forma segura mediante guard. Este es un patrón estándar para closures asíncronas en Swift — debe usarse siempre que una closure se almacene como propiedad.

Unowned self en closures

unowned self es una alternativa a weak self cuando se garantiza que self vive más que la closure. Ejemplo: closures síncronas que se ejecutan inmediatamente (sorted, filter). En esos casos self definitivamente está vivo, y unowned es seguro. Sin embargo, unowned falla al acceder a un objeto liberado — por lo tanto, weak se considera la opción segura por defecto.

Cómo detectar retain cycle: herramientas de diagnóstico

Detectar retain cycles en una etapa temprana es crítico para el rendimiento de la aplicación. Revisemos las principales herramientas y técnicas para identificar referencias cíclicas en el desarrollo iOS.

Xcode Memory Debugger

Xcode Memory Debugger (Debug Memory Graph) es una herramienta visual que muestra el grafo de objetos en memoria con sus referencias. Un retain cycle aparece como una cadena cerrada de flechas fuertes. Para iniciarlo: haga clic en el botón Debug Memory Graph en el panel Debug area mientras la aplicación se ejecuta. Cada objeto se muestra con su tipo, dirección y lista de referencias.

Instruments Leaks

Instruments Leaks es un profiler para la detección automática de fugas. Registra las asignaciones y analiza el grafo de referencias en tiempo real. Detecta no solo retain cycles, sino también referencias olvidadas, ViewControllers no liberados y otras fugas. Leaks señala el objeto exacto y la cadena de retención.

Registro de deinit

El método más simple es agregar un print en el deinit de cada clase clave. Si deinit no se llama cuando se espera que el objeto se destruya, hay un retain cycle. Este método no requiere herramientas y es efectivo para el diagnóstico inicial.

Enfoque recomendado: use registro de deinit durante el desarrollo, Memory Debugger durante las pruebas manuales e Instruments Leaks en el pipeline de CI/CD para la detección automatizada de regresiones de fugas.

Prevención de retain cycle y mejores prácticas

Prevenir retain cycles es más fácil que corregirlos en producción. Aquí hay algunas reglas que minimizan el riesgo de referencias cíclicas.

Regla de delegado weak

Todos los delegados y dataSources deben ser weak. Esta regla está incorporada en UIKit: todos los protocolos de delegados en el SDK de Apple se declaran con propiedades weak (UITableView.delegate, UICollectionView.dataSource). Para sus propios protocolos, use weak var delegate: MyDelegate? y herede el protocolo de AnyObject.

Lista de captura en closures

Cualquier closure que se almacene como propiedad (completion handler, callback) y capture self debe usar [weak self] en la lista de captura. La excepción son las closures que se ejecutan inmediatamente y no se almacenan (sorted, map, filter). Para ellas, unowned self es seguro.

Revisión de arquitectura

En arquitecturas complejas (VIPER, Coordinators, Redux), rastree la dirección de las referencias fuertes. El propietario mantiene una referencia fuerte al subordinado, pero el subordinado debe referenciar al propietario solo a través de weak o unowned. El flujo de datos unidireccional simplifica la gestión de referencias.

// Ejemplo: verificación con registro de deinit
class BaseViewController: UIViewController {
    deinit {
        print("✅ \(type(of: self)) deallocated")
    }
}

// Uso: todos los ViewController heredan de BaseViewController
class ProfileVC: BaseViewController {
    var viewModel: ProfileViewModel?
    var onLogout: (() -> Void)?

    override func viewDidLoad() {
        super.viewDidLoad()
        onLogout = { [weak self] in
            self?.dismiss(animated: true)
        }
    }
}
// Al cerrar ProfileVC esperamos "✅ ProfileVC deallocated" en la consola

Una clase base con registro de deinit proporciona retroalimentación instantánea. Si el mensaje no aparece cuando se espera que la pantalla se cierre, hay un retain cycle en esta clase. Agregue esta práctica a la plantilla del proyecto para todos los ViewControllers.