la programmation des téléchargements asynchrones dans runloop du thread principal vs runloop bg thread sur iOS?

Question

est ici une diapositive de la WWDC session de 2010 208:

conn = [[NSURLConnection alloc] initWithRequest:req 
    delegate:self startImmediately:NO]; 
[conn scheduleInRunLoop: [NSRunLoop currentRunLoop] 
    forMode: NSDefaultRunLoopMode]; 
[conn start]; 

Y a-t-il des problèmes liés à la mise plusieurs années Conn dans le currentRunLoop? Quels sont les avantages de la planification de NSURLConnection dans la boucle de lancement d'un thread d'arrière-plan?

Merci!

Answer 1

L'utilisation de la phrase «cycle secondaire» suggère que vous ne savez pas ce qu'est une boucle d'exécution. Un NSRunLoop est une implémentation de la "boucle principale" d'un thread. Plus ou moins,

while ([runLoop waitNextEvent]) { 
    NSAutoreleasePool * pool = [NSAutoreleasePool new]; 
    [runLoop handleEvent]; 
    [pool release]; pool = nil; 
} 

Une boucle d'exécution a un thread. Chaque thread a au plus une boucle d'exécution. "performSelectorOnMainThread" le planifie sur la boucle d'exécution, mais les programmeurs parlent généralement de threads plutôt que de l'abstraction de boucle qu'il utilise, car ils sont tous les mêmes. Tous les threads n'ont pas de boucles d'exécution (les fonctions de NSThread vous donneront généralement un thread sans boucle d'exécution, je pense que vous devez créer vous-même la boucle d'exécution si vous en voulez une). "CurrentRunLoop" est la boucle d'exécution du thread en cours d'exécution.

C'est probablement le thread principal, sauf si vous avez utilisé NSOperation/dispatch _ */etc. Si vous le programmez sur un autre thread, alors (je pense) les rappels de délégués seront exécutés à partir d'un autre thread. Vous ne voulez probablement pas que cela arrive.

Maintenant, les threads.

Il y a peu de points qui génèrent un thread d'arrière-plan qui est inactif la plupart du temps. NSURLConnection devrait très peu de traitement (vous ne pouvez pas obtenir autant de bande passante dans un téléphone en premier lieu); il n'y a pratiquement pas de frais généraux associés à l'exécution dans la boucle d'exécution principale; les threads ont tendance à avoir des frais généraux beaucoup plus importants.

Si vous traitez les données et que le traitement est gourmand en ressources processeur, vous souhaiterez peut-être qu'il s'exécute dans le thread d'arrière-plan. Vous pouvez mettre les connexions dans le thread d'arrière-plan, mais en général, il est plus facile d'en faire autant que possible dans le thread principal.

Et je ne vais pas commencer sur les ennuis de communication inter-thread, parce qu'ils sont une douleur majeure. N'utilisez la concurrence que si vous savez que vous en avez besoin.

(Et jusqu'à ce que l'iPhone va dual-core, vous certainement ne pas avoir besoin de 99% du code que vous écrivez.)