NSURLConnection solicitud síncrona de un subproceso vs solicitud asincrónica

Question

¿Cuál es la diferencia entre agregar una operación que realiza una solicitud NSURLConnection síncrona en NSOperationQueue (o solicitud síncrona de un subproceso (no subproceso principal)) Y realizar una solicitud asincrónica desde el subproceso principal ?

Ambos no bloquean el hilo principal, por lo que la IU seguirá siendo sensible, pero ¿hay alguna ventaja de usar uno sobre otro? Sé que en un método posterior puedo rastrear el progreso de la solicitud, etc. pero supongo que el progreso y otras cosas HTTP no son importantes aquí.

Answer 1

Las solicitudes asincrónicas se programan en el ciclo de ejecución y se configuran como una fuente de ciclo de ejecución, activando el código automáticamente solo cuando hay datos recibidos de la red (como cualquier fuente de socket).

Las solicitudes síncronas que se ejecutan en un NSThread monopolizan un subproceso para supervisar los datos entrantes, que en general es bastante exagerado.

Siempre puede cancelar un NSURLConnection, incluso si se ha ejecutado de forma asincrónica, utilizando el método cancel.

apuesto a usar la nueva API que permite enviar una solicitud asincrónica en una NSOperationQueue (+sendAsynchronousRequest:queue:completionHandler:) utiliza GCD bajo el capó y dispatch_source_create, o algo similar, por lo que se comportan de la misma manera que cuando un NSURLConnection está previsto en el ejecutar bucle, evitar usar un hilo adicional (ver los videos WWDC'12 que explica por qué los hilos son malos y su uso debe ser minimizado), la única diferencia es que le permite usar un bloque para estar informado al finalizar en lugar de usar el delegado mecanismo.

Hace algunos años, creé una clase que incorporaba NSURLConnection llamadas asincrónicas y delegué la administración en una bonita API de bloque (ver OHURLLoader en mi github) que hace que sea más fácil de usar (no dudes en echarle un vistazo). Apuesto a que la API nueva que usa NSOperationQueue s usa el mismo principio, sigue haciendo solicitudes asincrónicas en el runloop pero permitiéndole usar bloques en lugar de tener que implementar un delegado.

Answer 2

La posición histórica era que hay una ventaja en el consumo de energía y, por lo tanto, en la duración de la batería en solicitudes asíncronas, que presumiblemente incluye tanto el enfoque de delegado anterior como el nuevo enfoque basado en bloques.

Answer 3

Son muy similares. El mayor problema con las solicitudes sincrónicas es que no se pueden cancelar fácilmente. Dependiendo de su aplicación, eso podría ser un problema. Imagine que está descargando un documento grande y el usuario se mueve a otra pantalla para que ya no necesite esa información. En nuestro caso, en realidad elegí hacer NSURLConnections asíncronas en un NSThread secundario, que puede ser excesivo para algunas aplicaciones. Es más complicado, pero nos da la capacidad de cancelar solicitudes y decodificar los datos JSON/XML/de imagen en subprocesos secundarios para que no afecten la interactividad del usuario del subproceso principal.