Existe-t-il un moyen, lors de l'envoi de ce message, de spécifier que je préfère que mon sélecteur soit exécuté après tous les événements de l'interface utilisateur en attente, le cas échéant? C'est à dire. donner à ma minuterie aterDelay une priorité inférieure dans la file d'attente des événements.perfomSelector: withObject: afterDelay: puis-je demander une priorité basse?
Pas directement. Si vous utilisez performSelector:withObject:afterDelay: le sélecteur est effectué sur le thread principal , donc par définition, il se produira après que tous les événements de l'interface utilisateur en attente "en cours" ont été effectués, mais cela pourrait être au milieu d'un défilement ou d'une animation considérer comme un événement continu, mais est en réalité des centaines d'événements distincts.
Cependant, vous pouvez obtenir quelque chose de similaire en utilisant performSelectorInBackground:withObject:, puis en appelant [NSThread setThreadPriority:0.01] dans la méthode appelée. Soyez prudent: vous ouvrez un thread d'arrière-plan, vous ne pouvez donc pas faire d'appels d'interface utilisateur. Toutefois, cela vous permettra de faire le travail sur un thread d'arrière-plan avec une priorité inférieure à celle du thread principal de l'interface utilisateur. (N'oubliez pas de mettre en place un pool d'autorelease car il est dans son propre thread!)
En réalité, performSelector:withObject:afterDelay: ne doit pas nécessairement apparaître sur le filetage principal; c'est pourquoi il existe une méthode distincte performSelectorOnMainThread:withObject:waitUntilDone:. La documentation pour performSelector:withObject:afterDelay: dit
une méthode Invoque du récepteur sur le thread courant en utilisant le mode par défaut après un délai.
Si vous souhaitez effectuer une tâche en arrière-plan, vous pouvez regarder dans +[NSThread detachNewThreadSelector:toTarget:withObject:], qui va lancer un nouveau thread pour effectuer votre tâche, et laisser l'interface utilisateur réactive. L'utilisation d'un thread distinct pour exécuter une tâche de longue durée qui pourrait autrement bloquer votre interface utilisateur est généralement une bonne idée, mais elle ajoute de la complexité. Si vous n'êtes pas familier avec le threading, vous pouvez vous retrouver avec des bugs qui n'auront aucun sens. Dans un commentaire ci-dessus, vous avez mentionné que vous pensez que l'animation est peut-être responsable de l'absence de réponse de votre interface utilisateur. Si vous utilisez la prise en charge intégrée de l'animation (Core Animation ou l'un des wrappers Cocoa), l'animation ne doit pas empêcher votre interface utilisateur de répondre. Une interface utilisateur qui ne répond pas signifie généralement que votre programme fait beaucoup de travail sur le thread principal avant de laisser la boucle d'exécution revenir aux événements de l'interface utilisateur du service.
Merci. Au moins je sais maintenant ne pas chasser un hareng rouge. Je vais regarder dans la suppression de l'animation car j'ai un soupçon qui fait que mon interface ne répond pas parfois. –