Je suis aimant dans Le deuxième numéro de objc.io Ils passent sur Nsoperationqueur et mentionnent qu'il possède deux types de files d'attente, la file d'attente principale qui fonctionne sur le fil principal et les files d'antécédents. Ils mentionnent que vous pouvez accéder à la file d'attente principale avec Il mentionne également que vous pouvez ajouter aux files d'attente de fond (ce que je comprends serait mieux?) En créant des instances de nsopération (sous-classes potentiellement).
Il mentionne également que vous pouvez contrôler la quantité d'opérations fonctionnant simultanément avec la propriété nsoperationqueur mais j'ai des problèmes de compréhension des parties de celle-ci.
[Nsoperation Mainqueur] , puis ajouter le manipuler.
Mainqueur , alors comment gérer l'ajout de tâches aux files d'attente de fond?
MaxConCurrentOperationCount .
NsoperationQueudEfaultMaxConcurrentOverationCount , mais si je l'ai défini sur un numéro spécifique manuellement, correspond-il au nombre maximal de threads pouvant être exécutés à la fois? Par exemple, si le processeur sur l'iPhone peut exécuter 4 threads à la fois et je définirai cette propriété à 8, que se passe-t-il?
3 Réponses :
Généralement, vous ne voulez pas utiliser la file d'attente principale. Toute opération là-bas sera exécutée sur le fil principal.
Lorsque vous créez une file d'attente de commande, créez-la à des fins. Comme il sera utilisé pour toutes les demandes de serveur. Vous pouvez donc contrôler combien de demandes simultanées sont en cours. N'ajoutez donc pas d'opérations de traitement algorithmique à cette file d'attente, car elles ont un but différent. Gardez une référence à la file d'attente afin que vous puissiez ajouter des opérations à l'avenir (et mettre en pause / annuler des opérations).
Il n'y a pas de paramètre «normal» pour Si vous le définissez sur 8, la file d'attente fonctionnera jusqu'à 8 en même temps. Cela peut ne pas être l'option la plus efficace. Gardez toujours le but de la file d'attente à l'esprit. MaxConcurentOperationCount - il devrait être défini en fonction de l'objectif.
Vous demandez:
Normalement, vous ne voulez pas [ajouter des opérations au
mainQueue code>], correct? Si elle fonctionne sur le fil principal, ne bloquera-t-elle pas le fil principal pour d'autres tâches? Ne serait-il pas fonctionner en même temps que d'autres tâches? P> Blockquote>Oui, vous ne voudrez plus jamais ajouter quoi que ce soit lent à la file d'attente principale. Mais cela ne signifie pas que vous n'utilisez pas la file d'attente principale. Pour certaines opérations (par exemple les mises à jour l'interface utilisateur), il est essentiel. P>
Le modèle typique est de créer une file d'attente d'opération pour les tâches que vous souhaitez exécuter en arrière-plan, mais si vous avez besoin par la suite de faire quelque chose qui doit courir sur la file d'attente principale (par exemple l'interface utilisateur mise à jour, la mise à jour du modèle, etc.), vous aller de l'avant et le faire, par exemple: p>
NSOperationQueue *queue = [[NSOperationQueue alloc] init]; [queue addOperationWithBlock:^{ // do some time consuming stuff in the background // when done, you might update the UI in the main queue [[NSOperationQueue mainQueue] addOperationWithBlock:^{ // update the UI here }]; ];
Comment les threads de travail diffèrent-ils des fils normaux? Je pensais que les threads étaient très proches du nombre de cœurs sur un processeur. 64 sons très haut. Serait-il prudent de dire "la définir à NsoperationeUserfaultMaxConCurrentOperationCount sauf si vous souhaitez gérer une petite quantité de ressources sur l'appareil, auquel cas l'utilisation, par exemple, <10"? Ou est-ce que Defaultmax est-il trop élevé?
Les threads de travailleurs @Dougsmith sont des fils normaux, mais le système d'exploitation prend en charge toute la gestion du fil compliquée pour vous. En ce qui concerne les threads et les cœurs B / W, je pense que vous pouvez avoir plus de threads que les cœurs, et lorsque cela se produit, je suis sous l'impression qu'il s'engage dans une multi-tâche préventive. En termes de problèmes liés à l'utilisation de trop nombreux threads, dans l'excellent WWDC 2012 vidéo Des motifs de design asynchrones avec des blocs, GCD et XPC touchent cela.
Personnellement, si j'ai une conception qui va entraîner une grande partie d'opérations simultanées, je limite toujours MaxConcurrentOpationCountCompount avec un petit nombre fixe raisonnable. Dans 99% des cas, je fais quelque chose de mémoire intensif (auquel cas je ne veux pas trop d'opérations simultanées ou d'autres que j'aurai une quantité déraisonnable de mémoire) ou un réseau basé (et il n'y a que tant de réseau simultané Les demandes que vous pouvez avoir, de toute façon).
Tout d'abord, vous devrez garder à l'esprit que vous séparez toujours le fil principal avec le fil d'arrière-plan. Seules les opérations qui impliquent la mise à jour de l'interface utilisateur doivent être effectuées dans le fil principal et le reste des opérations doivent être effectuées dans le fil d'arrière-plan. E.g Si vous avez affaire à des téléchargements multiples, vous devez alors prendre soin de toutes les opérations de réseau dans la file d'attente de fond, et vous devrez effectuer la mise à jour de l'interface utilisateur dans la file d'attente principale.
//e.g for updating UI in main thread. [self performSelectorOnMainThread:@selector(updateUI) withObject:nil waitUntilDone:YES];