Thread en desarrollo móvil — qué es, tipos y gestión de hilos

Qué es Thread

Thread (hilo de ejecución) es una secuencia independiente de instrucciones que el sistema operativo puede planificar en un núcleo de CPU. Cada proceso (aplicación) contiene al menos un hilo — el Hilo Principal. Se crean hilos adicionales para la ejecución paralela de tareas. Cada hilo tiene su propia pila de programa (con variables locales), contador de programa (PC) y registros. La memoria heap es compartida entre todos los hilos del proceso.

En los sistemas operativos móviles, los hilos se planifican mediante multitarea preventiva: el SO puede interrumpir la ejecución de un hilo en cualquier momento y pasar el control a otro (cambio de contexto). El cambio de contexto es una operación costosa (1–10 microsegundos) ya que requiere guardar/restaurar registros de CPU, actualizar el TLB y vaciar los cachés. Por eso un número excesivo de hilos (cientos o miles) degrada el rendimiento — el SO dedica más tiempo a cambiar que a ejecutar.

Hilo vs Proceso — conceptos diferentes. Un proceso es una instancia de una aplicación con memoria virtual asignada. Un hilo dentro de un proceso comparte esta memoria con otros hilos. En Android, cada componente de la aplicación (Activity, Service, BroadcastReceiver) trabaja en un proceso pero puede ejecutarse en diferentes hilos. Una aplicación iOS también es un único proceso capaz de crear hilos adicionales a través de GCD o Thread.

Ciclo de Vida del Hilo: Estados y Transiciones

Cada hilo en Java/Kotlin (Android) y NSThread (iOS) pasa por cinco estados: New (creado), Runnable (listo para ejecutar), Running (ejecutándose en CPU), Blocked/Waiting (esperando un recurso o notificación), Terminated (finalizado). Las transiciones entre estados son gestionadas por el planificador del SO y los primitivos de sincronización. El desarrollador puede influir en la prioridad del hilo (Thread.setPriority()) y su estado (sleep, join, interrupt).

En Android, un hilo entra en estado Blocked al intentar adquirir un monitor ocupado (synchronized), llamar a Object.wait() o Thread.sleep(). En iOS — al llamar a NSCondition.wait(), pthread_cond_wait() o dispatch_semaphore_wait(). En estado Blocked, el hilo no consume CPU pero sigue ocupando memoria (pila). Un hilo puede ser interrumpido desde otro hilo, recibiendo InterruptedException (Java) o verificando isCancelled (Kotlin Coroutines).

Cambio de Contexto y su Costo

Cambio de contexto es una operación donde el SO guarda el estado del hilo actual (registros, PC, TLB) y carga el estado guardado de otro. En sistemas móviles (Linux + ART, XNU para iOS) un cambio de contexto toma 1–10 microsegundos. Si un hilo ejecuta una tarea en 100 microsegundos y un cambio de contexto toma 5, entonces se pierde el 5% del tiempo. Para minimizar los cambios de contexto, iOS usa GCD con work stealing, Android usa pools con fixedThreadCount.

Thread en Android: De Thread a Coroutines

Android ha evolucionado desde java.lang.Thread de bajo nivel hasta las corrutinas modernas. Cada nivel de abstracción proporciona más capacidades con menos sobrecarga. Thread es la clase base, pero no se recomienda su creación directa: un nuevo hilo no es gestionado por un pool, es difícil de monitorear y cancelar. AsyncTask (obsoleto desde API 30) fue un paso adelante, pero sufría de fugas de memoria y manejo incómodo de configuraciones.

HandlerThread es una subclase especial de Thread con Looper que puede procesar una cola de mensajes. Se usa para la ejecución secuencial de tareas en un hilo de fondo, por ejemplo, escribiendo datos en Room o archivos. HandlerThread se crea llamando a start(), después de lo cual se pueden enviar mensajes y Runnable a través de Handler(handlerThread.looper). Llamar a handlerThread.quit() detiene el Looper y termina el hilo.

// Android: Thread, HandlerThread y Executors
import android.os.Handler
import android.os.HandlerThread
import java.util.concurrent.Executors

class ThreadExample {

    // 1. Creación directa de Thread (no recomendada)
    fun directThread() {
        val thread = Thread(Runnable {
            Thread.sleep(1000)
            print("Direct thread executed")
        })
        thread.start()
    }

    // 2. HandlerThread para tareas secuenciales en segundo plano
    fun handlerThreadExample() {
        val handlerThread = HandlerThread("BackgroundQueue")
        handlerThread.start()

        val handler = Handler(handlerThread.looper)
        handler.post {
            // Ejecución secuencial en un hilo de fondo
            Thread.sleep(500)
            print("HandlerThread: tarea completada")
        }

        // Detener el hilo (se ejecuta cuando las tareas terminan)
        handlerThread.quitSafely()
    }

    // 3. Executors — pool de hilos
    fun executorExample() {
        val executor = Executors.newFixedThreadPool(4)
        for (i in 1..10) {
            executor.execute {
                print("Task $i on thread ${Thread.currentThread().getName()}")
            }
        }
        executor.shutdown()
    }

    // 4. Kotlin Coroutines — estándar moderno
    suspend fun coroutineExample() = kotlinx.coroutines.withContext(
        kotlinx.coroutines.Dispatchers.Default
    ) {
        print("Coroutine on thread: ${Thread.currentThread().getName()}")
    }
}

El ejemplo ThreadExample muestra los cuatro niveles de abstracción de hilos en Android. La creación directa de Thread es el enfoque más bajo y menos eficiente. HandlerThread es útil para tareas secuenciales en segundo plano. Executors.newFixedThreadPool(4) crea un pool de 4 hilos para la ejecución paralela de hasta 10 tareas. Kotlin Coroutines con Dispatchers.Default es un enfoque moderno, eficiente y seguro.

HandlerThread: Tareas Secuenciales en Segundo Plano

HandlerThread es una subclase especializada de Thread con un Looper incorporado y cola de mensajes. Se crea llamando a start(), después de lo cual se pueden enviar Runnable y mensajes a través de Handler(handlerThread.looper). HandlerThread ejecuta tareas estrictamente secuenciales — la siguiente tarea no comienza hasta que la anterior se completa. Esto es útil para escribir datos en Room o archivos, donde el orden de las operaciones es crítico. Llamar a quitSafely() detiene el Looper después de que la tarea actual se completa.

import Foundation

class ThreadManager {

    // 1. Thread (bajo nivel)
    func createThread() {
        let thread = Thread {
            // Código ejecutándose en un nuevo hilo
            print("Current thread: \(Thread.current)")
        }
        thread.name = "com.app.worker"
        thread.qualityOfService = .utility
        thread.start()
    }

    // 2. GCD — DispatchQueue
    func gcdExample() {
        // Cola concurrente
        let queue = DispatchQueue(label: "com.app.concurrent",
                                 qos: .utility,
                                 attributes: .concurrent)

        queue.async {
            print("GCD async task")
        }

        // Barrera para sincronización de escritura
        queue.async(flags: .barrier) {
            // Acceso exclusivo durante la escritura
            print("Barrier write: exclusive access")
        }
    }

    // 3. OperationQueue con dependencias
    func operationQueueExample() {
        let queue = OperationQueue()
        queue.maxConcurrentOperationCount = 2
        queue.qualityOfService = .background

        let download = BlockOperation {
            print("Downloading...")
        }
        let process = BlockOperation {
            print("Processing...")
        }
        let save = BlockOperation {
            print("Saving...")
        }

        // Dependencias: download -> process -> save
        process.addDependency(download)
        save.addDependency(process)

        queue.addOperations([download, process, save], waitUntilFinished: false)
    }
}

// Colección thread-safe mediante barrera GCD
class ThreadSafeArray<T> {
    private var array: [T] = []
    private let queue = DispatchQueue(label: "com.app.concurrent",
                                       attributes: .concurrent)

    var count: Int {
        return queue.sync { array.count } // concurrent read
    }

    func append(_ element: T) {
        queue.async(flags: .barrier) { // exclusive write
            self.array.append(element)
        }
    }
}

// Sincronización en Android/Kotlin
import java.util.concurrent.atomic.AtomicInteger
import kotlinx.coroutines.sync.Mutex
import kotlinx.coroutines.sync.withLock

class Counter {

    // 1. AtomicInteger — para contadores simples
    private val atomicCount = AtomicInteger(0)
    fun incrementAtomic() = atomicCount.incrementAndGet()

    // 2. synchronized — para secciones críticas
    @Synchronized
    fun synchronizedOperation() {
        // Solo un hilo a la vez
        doWork()
    }

    // 3. Mutex de corrutina — suspend-safe
    private val mutex = Mutex()
    suspend fun mutexOperation() {
        mutex.withLock {
            // protected code — thread-safe
            doWork()
        }
    }

    private fun doWork() { /* critical section */ }
}

// Ejemplo de Deadlock: A bloquea B, B bloquea A
class DeadlockExample {
    private val lockA = Any()
    private val lockB = Any()

    fun methodA() = synchronized(lockA) {
        Thread.sleep(100)
        synchronized(lockB) { print("OK") }
    }

    fun methodB() = synchronized(lockB) {
        Thread.sleep(100)
        synchronized(lockA) { print("OK") }
    }
}