Quand OS X décide-t-il de donner à votre application un ballon de plage tournant? Que pouvez-vous faire lorsque vous programmez une application pour éviter cela?Mac OS X: qu'est-ce qui cause la rotation du ballon de plage?
Le serveur de fenêtre affichera le curseur d'attente en rotation lorsque l'application la plus en avant, ou l'application qui a une fenêtre sous le pointeur de la souris, n'a pas répondu aux événements du serveur de fenêtre dans une certaine fenêtre. Pour éviter le curseur d'attente en rotation, une application doit gérer les événements en temps voulu. Il n'y a aucun moyen de contourner ce comportement de serveur de fenêtre, et pour cause: les applications sur Mac OS X ne sont jamais censées ne pas répondre à l'utilisateur.
Il convient de noter que Apple [Spin Control] (http://developer.apple.com/library/mac/documentation/Performance/Conceptual/PerformanceOverview/InitialEvaluation/InitialEvaluation.html#//apple_ref/doc/uid/TP40001410- CH206-SW10) est un outil potentiellement utile pour déboguer ces événements. –
En supposant que votre application dispose de suffisamment de ressources matérielles (ce qui ne sera pas toujours le cas dans la réalité), il n'y a vraiment aucune raison pour que votre application fasse du beachball. Si c'est le cas, déterminez quelle section du code bloque l'interface utilisateur (si ce n'est pas intuitif, Shark.app vous sera utile) et déplacez-le vers un thread d'arrière-plan (ou utilisez une autre stratégie pour éliminer la pause). Heureusement, Cocoa et Objective-C ont d'assez bons outils pour le threading, voir NSOperationQueue pour commencer. Apple a également quelques bons documents sur l'optimisation des performances, voir this question pour les liens pertinents.
La raison en est que votre application bloque l'interface utilisateur. Comme l'ont dit les autres affiches, le gestionnaire de fenêtres peut remarquer que vous n'avez pas traité les événements depuis un certain temps et afficher cette interface utilisateur.
Très probablement, vous effectuez des E/S (telles que lire ou écrire sur le disque ou effectuer des requêtes réseau) de manière synchrone sur le thread UI (par défaut). Une bonne règle pour garder votre application sensible (et donc éviter le beachball) est de ne jamais faire d'E/S synchrones sur le thread de l'interface utilisateur. Vous pouvez soit utiliser des E/S asynchrones (API qui effectuent un rappel, travailler sur un thread d'arrière-plan, puis vous notifier sur le thread UI une fois terminé), soit utiliser un thread d'arrière-plan distinct pour effectuer le travail.
Si vous ne faites pas d'E/S, vous êtes probablement dans une sorte de longue boucle sur le thread d'interface utilisateur qui vous empêche de répondre. Dans ce cas, optimisez ou supprimez la boucle ou déplacez-la dans un thread d'arrière-plan.
Pourquoi les gens ont-ils signalé cette fermeture? Il s'agit d'une question entièrement liée à la programmation (et plutôt intéressante à ce sujet). – dbr
Marc Charbonneau a corrigé ma formulation pour préciser que je posais une question liée à la programmation. Espérons que cela empêche les gens proches d'être heureux. Merci Marc !! –