Strong Reference (referencia fuerte): qué es, mecanismo de funcionamiento y ARC

¿Qué es Strong Reference?

Strong Reference es un tipo de referencia a un objeto que impide su destrucción por parte del recolector de basura o del sistema de gestión de memoria. Mientras exista al menos una referencia fuerte al objeto, su memoria no se libera. Este es el mecanismo básico sobre el que se construyen ARC en Swift y Objective-C, así como la recolección de basura en Java y Kotlin.

El concepto de referencia fuerte es fundamental para todos los lenguajes con gestión automática de memoria. En sistemas con ARC, cada referencia fuerte incrementa el contador de referencias del objeto. Cuando el contador llega a cero, el objeto se desasigna inmediatamente. En Java y Kotlin con recolección de basura, una referencia fuerte garantiza que el objeto es alcanzable y no será recogido por el GC.

Según WWDC 2021, aproximadamente el 35% de las fugas de memoria en aplicaciones iOS están relacionadas con el uso incorrecto de referencias fuertes y ciclos de retención. En el desarrollo de Android, las fugas a través de referencias fuertes implícitas en closures y callbacks son la segunda causa más frecuente de problemas de memoria después de Context Leak.

Para trabajar eficazmente con la memoria, es necesario comprender la diferencia entre referencias strong, weak y unowned, y elegir el tipo de referencia adecuado según la propiedad y el ciclo de vida de los objetos.

Cómo cambió ARC la gestión de memoria

Antes de ARC, los desarrolladores llamaban manualmente a retain y release para cada objeto, lo que provocaba numerosos errores. ARC, presentado por Apple en 2011 con LLVM 3.0, automatizó este proceso analizando el grafo de propiedad en tiempo de compilación. El propio compilador inserta las llamadas a retain, release y autorelease donde sea necesario.

Según Clang Static Analyzer, la introducción de ARC redujo los errores relacionados con la memoria en aplicaciones iOS en un 70%. Para los desarrolladores, esto significa que la gestión de memoria se ha vuelto más segura, pero al mismo tiempo ha surgido la necesidad de comprender cómo funcionan las referencias fuertes internamente — para evitar retain cycles.

En Kotlin y Java, el recolector de basura desempeña el papel de ARC, pero el principio de la referencia fuerte sigue siendo el mismo: GC Roots son los puntos de entrada a través de los cuales los objetos se mantienen mediante referencias fuertes. Mientras un objeto sea alcanzable a través de una cadena de referencias fuertes desde una GC Root, no será recolectado.

¿Cómo funciona Strong Reference en ARC?

ARC (Automatic Reference Counting) funciona contando las referencias de cada objeto en el heap. Cuando se crea una nueva referencia fuerte a un objeto, el contador se incrementa (retain). Cuando la referencia se destruye o se sobrescribe, el contador disminuye (release). Cuando el contador llega a cero, el objeto se elimina inmediatamente de la memoria.

Consideremos un ejemplo en Swift. Al crear una instancia de una clase, ARC asigna memoria y establece el retain count en 1. Cada nueva asignación a otra variable incrementa el contador. Cuando la variable sale del ámbito, el contador disminuye:

class ProfileViewController {
    var nameLabel: String?
    var avatarImage: UIImage?

    func loadProfile() {
        // retain count = 1 para una nueva instancia
        let user = User(name: "Ivan")
        // retain count = 2 después de asignar nameLabel
        nameLabel = user.name
        // salida del método — user sale del ámbito, retain count = 1
    }
}

En este código, ARC garantiza que el objeto User permanezca en la memoria mientras haya al menos una referencia fuerte apuntando a él. Cuando la función loadProfile termina, la variable local user se destruye, pero nameLabel sigue manteniendo el objeto. La memoria se liberará solo cuando nameLabel deje de existir o sea sobrescrita.

En Kotlin, un comportamiento similar se proporciona a través de GC Roots. Mientras exista una cadena trazable de referencias fuertes desde una raíz del recolector de basura (por ejemplo, un campo estático o un hilo activo), el objeto permanece en la memoria. La diferencia es que el GC no libera memoria al instante — ocurre de forma asíncrona tras el análisis de alcanzabilidad.

Cuándo ocurre la liberación de memoria

En ARC, la liberación ocurre de forma síncrona cuando el contador llega a cero. En Swift y Objective-C, sabes exactamente cuándo se eliminará el objeto. En Kotlin y Java, el momento de la liberación es impredecible, pero esto se compensa con un esquema más flexible para detectar dependencias cíclicas a nivel del recolector de basura.

Retain Cycles y fugas de memoria

Retain cycle (ciclo de retención) es una situación en la que dos o más objetos tienen referencias fuertes mutuas entre sí. Como resultado, su retain count nunca llega a cero y la memoria nunca se libera, incluso después de que los objetos ya no sean necesarios para la aplicación.

Un ejemplo clásico: un view controller padre mantiene un objeto hijo con una referencia fuerte, y este a su vez mantiene al padre con una referencia fuerte. Esto es típico en situaciones con delegados, closures y expresiones lambda anidadas. Según Instruments Leaks, los retain cycles representan hasta el 60% de todas las fugas de memoria en aplicaciones que usan ARC.

class ParentViewController: UIViewController {
    var child: ChildViewController?

    func setupChild() {
        child = ChildViewController()
        // retain cycle: padre mantiene hijo, hijo mantiene padre mediante closure
        child?.onEvent = {
            self.handleEvent()
        }
    }

    func handleEvent() {}
}

El problema aquí es que la closure onEvent captura self (ParentViewController) con una referencia fuerte, y ParentViewController a su vez mantiene child con una referencia fuerte. Ambos objetos nunca se liberarán. La solución es usar weak self en la closure para romper el ciclo.

En Kotlin, surgen ciclos similares cuando las lambdas capturan objetos externos. El recolector de basura de la JVM puede detectar estos ciclos con el tiempo, pero solo si los objetos son inalcanzables desde GC Roots. Si el ciclo está vinculado a un hilo activo o un contexto de UI, la fuga persiste durante toda la vida de la aplicación.

Strong vs Weak vs Unowned Reference

Comprender la diferencia entre los tipos de referencias es clave para una gestión segura de la memoria. Strong Reference incrementa el retain count. Weak Reference no incrementa el retain count y se vuelve nil automáticamente al liberarse el objeto. Unowned Reference tampoco incrementa el retain count pero no se pone a cero — acceder a ella después de la liberación provoca un crash.

La elección del tipo de referencia viene dictada por la relación de propiedad. Si el objeto B es parte de A y no puede existir sin él — usa Strong. Si B puede existir de forma independiente y referencia a A para notificaciones — usa Weak. Unowned se usa raramente — solo cuando la vida del objeto hijo no supera estrictamente la del padre.

Regla práctica de selección

Apple Developer Documentation recomienda: por defecto, usa strong para todas las relaciones de propiedad. Si necesitas evitar un retain cycle — determina qué referencia debe ser débil. Normalmente es la referencia inversa en la jerarquía (hijo → padre). En Kotlin, un papel similar lo desempeña WeakReference de java.lang.ref, que se usa para cachés y patrones observer.

Cómo solucionar problemas con referencias fuertes

Detectar retain cycles es el primer paso. El segundo es eliminarlos correctamente. La herramienta principal para romper ciclos de referencias fuertes es reemplazar una de las referencias por weak o unowned. En lenguajes con recolección de basura, se usa adicionalmente WeakReference con verificación manual de null antes de cada acceso.

En Swift y Objective-C, la corrección más común es añadir [weak self] en las closures. Esto garantiza que la closure no retenga el objeto después de su liberación. En Kotlin, se usan wrappers WeakReference o la limpieza explícita de referencias en onDestroy para fines similares.

class NetworkService {
    func fetchData(completion: @escaping (Data?) -> Void) {
        // captura con weak self — retain cycle eliminado
        URLSession.shared.dataTask(
            with: URL(string: "https://api.example.com")!
        ) { [weak self] data, response, error in
            guard let self else { return }
            completion(data)
        }.resume()
    }
}

En este ejemplo, [weak self] garantiza que NetworkService no sea retenido por la closure después de que ya no sea necesario. Si self se libera antes de que la solicitud se complete — guard let self else { return } sale de la closure sin llamar a completion.

Para el diagnóstico de retain cycles, usa Instruments Leaks para iOS o Android Profiler + LeakCanary para Android. Estas herramientas muestran el grafo exacto de retención e indican qué referencia fuerte impide la liberación del objeto. La creación de perfiles de memoria regular debe ser parte del pipeline CI/CD de cualquier proyecto móvil.

Strong Reference en Swift y Kotlin — comparación

Swift y Kotlin usan mecanismos de gestión de memoria fundamentalmente diferentes, pero el concepto de referencia fuerte existe en ambos. Swift usa ARC con liberación síncrona al alcanzar retain count = 0. Kotlin usa un GC de trazado que limpia asíncronamente los objetos inalcanzables.

La principal diferencia práctica: en Swift, un retain cycle es una fuga garantizada. En Kotlin, el GC puede romper el ciclo si los objetos son inalcanzables desde la raíz, pero el tiempo de vida de los objetos fugados sigue siendo impredecible. Por lo tanto, en ambos lenguajes, la mejor estrategia es evitar los ciclos de referencias fuertes en la etapa de diseño.

Para Swift, usa weak en patrones de delegado y closures. Para Kotlin, usa WeakReference o componentes Lifecycle-aware que limpian automáticamente las referencias al destruirse el propietario. En ambos enfoques, el objetivo es el mismo — eliminar las referencias fuertes donde crean una cadena de retención irrompible.