iPhone: hilo principal de Grand Central Dispatch

He estado usando con éxito, gran distribución central en mis aplicaciones, pero me preguntaba cuál es la verdadera ventaja de usar algo como esto:

dispatch_async(dispatch_get_main_queue(), ^{ ... do stuff

o incluso

dispatch_sync(dispatch_get_main_queue(), ^{ ... do stuff

Quiero decir, en ambos casos estás disparando un bloque para que se ejecute en el hilo principal, exactamente donde se ejecuta la aplicación y esto no ayudará a reducir la carga. En el primer caso, no tienes ningún control sobre cuándo se ejecutará el bloque. He visto casos de bloques ejecutados medio segundo después de que los disparas. El segundo caso, es similar a

[self doStuff];

¿Derecha?

Me pregunto qué piensan ustedes.

El envío de un bloque a la cola principal generalmente se realiza desde una cola en segundo plano para indicar que ha finalizado algún procesamiento en segundo plano, por ejemplo

- (void)doCalculation
{
    //you can use any string instead "com.mycompany.myqueue"
    dispatch_queue_t backgroundQueue = dispatch_queue_create("com.mycompany.myqueue", 0);

    dispatch_async(backgroundQueue, ^{
        int result = <some really long calculation that takes seconds to complete>;

        dispatch_async(dispatch_get_main_queue(), ^{
            [self updateMyUIWithResult:result];
        });    
    });
}

En este caso, estamos haciendo un cálculo largo en una cola en segundo plano y necesitamos actualizar nuestra interfaz de usuario cuando se complete el cálculo. La actualización de la interfaz de usuario normalmente debe realizarse desde la cola principal, por lo que 'señalizamos' de nuevo a la cola principal utilizando un segundo dispatch_async anidado.

Probablemente hay otros ejemplos en los que es posible que desee volver a la cola principal, pero generalmente se hace de esta manera, es decir, anidada desde un bloque enviado a una cola en segundo plano.

• procesamiento en segundo plano terminado -> actualizar la interfaz de usuario
• fragmento de datos procesados ​​en la cola de fondo -> señalizar la cola principal para comenzar el siguiente fragmento
• datos de red entrantes en la cola de fondo -> señalizar la cola principal de que el mensaje ha llegado
• etcétera etcétera

En cuanto a por qué es posible que desee enviar a la cola principal desde la cola principal ... Bueno, generalmente no lo haría, aunque posiblemente podría hacerlo para programar algún trabajo para la próxima vez en el ciclo de ejecución.

El envío de bloques a la cola principal desde el hilo principal puede ser útil. Le da a la cola principal la oportunidad de manejar otros bloques que se han puesto en cola para que no esté simplemente bloqueando la ejecución de todo lo demás.

Por ejemplo, podría escribir un servidor de subprocesos esencialmente único que, sin embargo, maneje muchas conexiones concurrentes. Mientras ningún bloque individual en la cola tarde demasiado, el servidor responde a las nuevas solicitudes.

Si su programa no hace nada más que pasar toda su vida respondiendo a eventos, entonces esto puede ser bastante natural. Simplemente configure sus controladores de eventos para que se ejecuten en la cola principal y luego llame a dispatch_main (), y es posible que no tenga que preocuparse por la seguridad del hilo.

Espero que comprenda su pregunta correctamente, ya que se pregunta sobre las diferencias entre dispatch_async y dispatch_sync.

dispatch_async

enviará el bloque a una cola de forma asincrónica. Lo que significa que enviará el bloque a la cola y no esperará a que regrese antes de continuar con la ejecución del código restante en su método.

dispatch_sync

enviará el bloque a una cola sincrónicamente. Esto evitará más ejecución del código restante en el método hasta que el bloque haya terminado de ejecutarse.

Principalmente utilicé una dispatch_asynccola de fondo para sacar el trabajo de la cola principal y aprovechar los núcleos adicionales que pueda tener el dispositivo. Luego dispatch_asyncal hilo principal si necesito actualizar la interfaz de usuario.

Buena suerte

Un lugar donde es útil es para las actividades de la interfaz de usuario, como configurar una ruleta antes de una operación larga:

- (void) handleDoSomethingButton{

    [mySpinner startAnimating];

    (do something lengthy)
    [mySpinner stopAnimating];
}

no funcionará, ya que está bloqueando el hilo principal durante su actividad prolongada y no está permitiendo que UIKit realmente inicie la ruleta.

- (void) handleDoSomethingButton{
     [mySpinner startAnimating];

     dispatch_async (dispatch_get_main_queue(), ^{
          (do something lengthy)
          [mySpinner stopAnimating];
    });
}

devolverá el control al ciclo de ejecución, que programará la actualización de la interfaz de usuario, iniciará el control giratorio, luego obtendrá lo siguiente de la cola de despacho, que es su procesamiento real. Cuando finaliza el procesamiento, se llama a la parada de animación y vuelve al ciclo de ejecución, donde la interfaz de usuario se actualiza con la parada.

Swift 3, 4 y 5

Ejecutando código en el hilo principal

DispatchQueue.main.async {
    // Your code here
}

Asíncrono significa asíncrono y debes usarlo la mayor parte del tiempo. Nunca debe llamar a la sincronización en el hilo principal porque bloqueará su interfaz de usuario hasta que se complete la tarea. You Here es una mejor manera de hacer esto en Swift:

runThisInMainThread { () -> Void in
    // Run your code like this:
    self.doStuff()
}

func runThisInMainThread(block: dispatch_block_t) {
    dispatch_async(dispatch_get_main_queue(), block)
}

Está incluido como una función estándar en mi repositorio, échale un vistazo: https://github.com/goktugyil/EZSwiftExtensions