Antes de que Swift introdujera Automatic Reference Counting (ARC), los desarrolladores gestionaban manualmente la memoria con llamadas retain, release y autorelease, lo que conducía a fugas de memoria o punteros colgantes. El ARC de Swift automatiza esto en tiempo de compilación al insertar llamadas de retención/liberación, pero introdujo una complejidad sutil con los cierres, que son tipos de referencia que capturan variables circundantes. Esto creó una nueva clase de problemas de memoria específicos de Swift, donde dos tipos de referencia podían formar una dependencia circular indestructible, lo que requería la sintaxis de lista de captura introducida para proporcionar control explícito sobre estas semánticas de captura.
Cuando una instancia de clase almacena un cierre como propiedad, y ese cierre hace referencia a self u otras propiedades de instancia, ARC incrementa el conteo de referencias de la instancia para mantenerla viva durante la vida del cierre. Debido a que el cierre es referenciado por la instancia, surge un ciclo de retención: la instancia sostiene el cierre fuertemente y el cierre sostiene la instancia fuertemente. Ningún conteo de referencia llega a cero, lo que impide que deinit se ejecute y causa que la memoria se filtre durante la vida de la aplicación.
Swift proporciona listas de captura: expresiones delimitadas por comas dentro de corchetes que preceden a la lista de parámetros del cierre, para modificar el comportamiento de captura predeterminado. Especificar [weak self] crea una referencia débil (opcional, se convierte en nil cuando se desaloca), mientras que [unowned self] crea una referencia no poseedora (asume existencia, falla si se accede después de la desalocación). Para valores, [x = x] captura el valor actual en lugar de la referencia. Esto rompe explícitamente el ciclo de referencia fuerte, permitiendo que ARC desalojé la instancia cuando se eliminan las referencias externas.
Ejemplo de Código:
class DataManager { var completionHandler: ((Data) -> Void)? var data: Data = Data() func fetchData() { // Ciclo de retención: self sostiene el cierre, el cierre sostiene self completionHandler = { newData in self.data = newData // Captura fuerte de self } } func fetchDataFixed() { // Solución: captura débil completionHandler = { [weak self] newData in guard let self = self else { return } self.data = newData } } deinit { print("DataManager desalojado") } }
En una aplicación de producción de iOS, implementamos un ProfileViewController que dependía de una clase UserService para obtener datos de perfil de forma asíncrona. El servicio exponía una API utilizando manejadores de completitud basados en cierres almacenados como propiedades para soportar solicitudes cancelables. Observamos que navegar lejos de la pantalla de perfil nunca activó el deinit del ViewController, y Instruments reportó un objeto gráfico de memoria persistente que mantenía la jerarquía de vistas.
Consideramos varios enfoques arquitectónicos para resolver esta fuga.
Intentamos explícitamente establecer el manejador de completitud en nil en viewWillDisappear. Si bien esto rompe técnicamente el ciclo cuando el usuario navega de regreso, resultó poco confiable para terminaciones abruptas o transiciones de estado inesperadas. También filtraba si el cierre nunca se invocaba y el controlador de vista era desalojado por el sistema bajo presión de memoria antes del evento de desaparición. Este enfoque requería una programación defensiva excesiva y violaba el principio de responsabilidad única al forzar al controlador de vista a gestionar el estado interno del servicio.
Evaluamos el uso de [unowned self] en el cierre para evitar el costo de desenvuelto opcional. Esto ofrecía limpieza sintáctica y beneficios de abstracción sin costo. Sin embargo, durante las pruebas, descubrimos condiciones de carrera donde la navegación rápida podría desalojar el ViewController mientras la solicitud de red aún estaba en curso, lo que provocaba fallos cuando el callback intentaba acceder a la instancia desalojada. El riesgo de comportamiento indefinido en producción superaba los beneficios de rendimiento.
Implementamos [weak self] combinado con un chequeo guard let self = self else { return } en el punto de entrada del cierre. Esto manejaba de manera segura todos los escenarios de ciclo de vida: si el controlador de vista se desalojaba antes de que se activara el callback, la referencia débil se convertía en nil, el guard fallaba silenciosamente, y ARC limpió el cierre después. Si bien requería ligeramente más código, garantizaba la seguridad de memoria y operación sin fallos.
Adoptamos el enfoque de captura débil de manera universal en toda la base de código. Después de refactorizar la integración de UserService para utilizar [weak self], la depuración del gráfico de memoria confirmó que las instancias de ProfileViewController se desalojaban inmediatamente tras la liquidación. El depurador de gráfico de memoria de Xcode mostró que no quedaban referencias fuertes desde el cierre, y la detección de fugas de Instruments reportó cero fugas en la función. Este patrón se convirtió en nuestro estándar para todas las APIs asíncronas basadas en cierres.
¿Cómo se diferencia la captura de una instancia de estructura en un cierre de la captura de una instancia de clase, y por qué las estructuras no pueden crear ciclos de retención?
Muchos candidatos asumen incorrectamente que capturar self en un cierre siempre implica riesgos de ciclos de retención independientemente del contexto. Las estructuras son tipos de valor en Swift, lo que significa que son copiados en lugar de referenciados. Cuando una estructura es capturada por un cierre, ARC copia el valor de la estructura en la lista de captura del cierre (o captura una referencia a la copia inmutable dependiendo de la optimización), pero crucialmente, la estructura no tiene un conteo de referencias. Debido a que el cierre sostiene el valor, no un puntero a un objeto asignado en heap, no hay posibilidad de referencia circular entre el cierre y la instancia original de la estructura.
El peligro existe exclusivamente cuando self se refiere a una clase (tipo de referencia), donde el cierre almacena un puntero al objeto de heap, incrementando su conteo de referencias. Comprender esta distinción es crucial para decidir si aplicar modificadores de listas de captura al trabajar con estructuras de vistas de SwiftUI frente a controladores de vistas de UIKit.
¿Cuál es la diferencia precisa entre [weak self] y [unowned self] respecto a las suposiciones sobre la vida del objeto, y cuándo causa un fallo [unowned self]?
Los candidatos a menudo tratan estos de manera intercambiable. [weak self] convierte la captura en una WeakReference opcional, que ARC establece automáticamente en nil cuando el objeto se desaloca. Acceder a ella requiere vinculación opcional y es seguro incluso si el objeto muere. [unowned self] crea una referencia no poseedora que asume que el objeto existirá durante toda la vida del cierre; se comporta como un opcional implícitamente desenrollado que nunca se establece en nil.
Si el cierre vive más que el objeto (por ejemplo, un manejador de completitud almacenado llamado después de que el controlador de vista se cierre), acceder a self desreferencia un puntero colgante, causando un fallo EXC_BAD_ACCESS. Usa [unowned self] solo cuando el cierre y el objeto tengan vidas idénticas, como en cierres no escapantes o patrones delegados específicos donde el cierre no puede vivir más que el capturador.
¿Cómo interactúan las listas de captura con las variables declaradas fuera del alcance del cierre y crea [x] una copia o una referencia para tipos de valor?
Un concepto erróneo común es que las listas de captura solo afectan a self. Cuando escribes { [x] in ... }, capturas explícitamente el valor actual de x en el punto de creación del cierre, creando efectivamente una copia sombra inmutable dentro del cierre. Sin la lista de captura, el cierre captura una referencia a la ubicación de almacenamiento de la variable original, permitiéndole ver las mutaciones realizadas después de la creación del cierre y potencialmente participar en lógica circular si x es un tipo de referencia.
Para tipos de valor como Int o String, [x] captura una copia, impidiendo que el cierre observe cambios externos a x y asegurando que el comportamiento del cierre sea determinístico según el estado en el momento de captura.