iPhone interface utilisateur addSubview provoquant exception concurrency

Question

C'est vraiment bizarre ...

je lance mon application, et pendant son ouverture et les vues sont en train de construire je reçois:

Collection <CALayerArray: 0x124650> was mutated while being enumerated. 

La trace de code passe par ce qui suit:

main 
UIApplicationMain 
-[UIApplication _run] 
CFRunLoopRunInMode 
CFRunLoopRunSpecific 
_UIApplicationHandleEvent 
-[UIApplication sendEvent:] 
-[UIApplication handleEvent:withNewEvent:] 
-[UIApplication _runWithURL:sourceBundleID:] 
-[UIApplication _performInitilizationWithURL:sourceBundleID:] 
-[AppDelegate applicationDidFinishLaunching:] 
+[Controller initializeController] //This is my own function 
    [window addSubview: pauseMenuController.view] //This is the last point of my code it goes through 
-[UIView(Hierarchy) addSubview:] 
-[UIView(Internal) _addSubview:positioned:relativeTo:] 
-[UIView(Hierarchy) _makeSubtreePerformSelector:withObject:] 
-[UIView(Hierarchy) _makeSubtreePerformSelector:withObject:withObject:copySublayers:] 
-[UIView(Hierarchy) _makeSubtreePerformSelector:withObject:withObject:copySublayers:] 
_NSFastEnumerationMutationHandler 
objc_exception_throw 

J'ai couru les lots de jeu et beaucoup, beaucoup de fois et je ne l'ai jamais vu cela, puis tout à coup, il surgit. La chose étrange est que je ne crée pas d'autres threads (que je connais) jusqu'à après ce code est appelé. Ce sera plus facile pour moi de déboguer ceci si quelqu'un peut me donner une explication de ce qui pourrait être modifié pendant qu'il est accédé dans un UIView. Cela a-t-il quelque chose à voir avec l'ajout de quelque chose à la vue alors qu'il ajoute déjà quelque chose, peut-être? Des idées?

Answer 1

Ce n'est pas une exception de concurrence. Les exceptions de mutation d'énumération se produisent lorsque quelque chose (éventuellement à l'intérieur d'une boucle dans le même thread) change le tableau/ensemble/dictionnaire que la boucle est en train d'itérer.

Étant donné que addSubview: est sur la pile, je suppose que quelque chose essaie de supprimer l'une des sous-vues de UIView pendant la construction.

Êtes-vous en train de surcharger les méthodes qui peuvent être lancées? Comme addSubview ou éventuellement layoutSubviews? Si l'un d'entre eux supprime des sous-vues, cela entraînera le problème.

Answer 2

Est-il possible que votre vue possède une sous-couche dans laquelle vous avez affecté le délégué à la vue? Cela entraînerait normalement la vue à se récurser infiniment (bien, jusqu'à ce qu'il atteigne la limite de la pile) lors de l'appel _makeSubtreePerformSelector:withObject:withObject:copySublayers:, mais je suppose qu'il est possible que tout ce qu'il essaie de faire ici implique une mutation. La raison en est que UIView suppose que si le délégué d'un CALayer est un UIView, alors ce CALayer appartient à l'UIView et l'UIView fait partie de la hiérarchie. Toutefois, si vous créez votre propre CALayer et affectez le délégué à UIView, l'UIView finira par s'appeler lui-même dans le cadre de la récursivité.

Answer 3

De la documentation:

Enumeration est « sûr » -le recenseur a un garde de mutation de sorte que si vous essayez de modifier la collection lors de l'énumération, une exception est levée. Fondamentalement, cela signifie que vous n'êtes pas autorisé à ajouter/supprimer des objets à une collection (disons un tableau) pendant que vous l'énumérez en utilisant l'énumération rapide introduite dans Objective-C 2.0. car cela rendrait le gardien de mutation invalide.

Dans votre cas, la collection est liée à une hiérarchie de vues. Si vous souhaitez ajouter et/ou supprimer des vues à cette collection particulière, n'utilisez pas l'énumération rapide.

Answer 4

J'ai vu cela se produire dans CALayers lorsque vous essayez d'effacer une propriété pendant la méthode -dealloc de CALayer, seule la modification de cette propriété altère par inadvertance une propriété visible de la couche. Vous pouvez vérifier et voir si vous faites quelque chose qui change les propriétés de l'une de vos vues pendant le -dealloc de cette même vue.

Answer 5

J'ai rencontré le même bug. Je faisais muter la hiérarchie de vue sur un thread non principal. Assurez-vous que toutes les modifications apportées à la vue sont effectuées sur le thread principal.