Comment résoudre le crash de la mémoire

Vérifiez simplement dans votre code que vous faites une erreur en ajoutant une nouvelle vue à chaque fois, mais j'ai oublié de le libérer ...

Vous devez regarder (et peut-être poster) la trace de la pile lorsque vous vous écrasez. Et le code qui change l'image. Cela ressemble à la mémoire de la mémoire (pas une vraie fuite dans laquelle quelqu'un fait toujours référence à la mémoire). L'élément de menu Analyser peut attraper quelque chose (et vous devez certainement l'exécuter), mais vous devrez peut-être exécuter l'instrument d'allocation et regarder des chèques de tas. Voir http://www.friday.com/bbum/2010/10/17/when-is-a-leak-not-a-leak-utilisant-heapshot-analysis-a -find-indésirable-mémoire-croissance / pour plus.

Cela ressemble à un débordement de pile pour moi. Dans la section "Autres drapeaux C" des paramètres de langue C / C ++ du projet, ajoutez un drapeau "-Fstack-check" et voyez si cela provoque une récursion indésirable.

Signal 0 est généralement dû à la mémoire faible comme l'application utilisant trop de mémoire. Vérifiez si la méthode d'avertissement de la mémoire est appelée ou non.

La fonction de formateur de données n'a pas pu être chargée d'être due à une mémoire suffisante pour le charger ..

50 vues comme si vous décrivez des sons comme un gros porc de mémoire. Je soupçonne donc que la gestion de la mémoire décharge des vues. Ensuite, lorsque votre programme a besoin des points de vue, ils ne sont pas là et votre programme se bloque. Le message d'erreur ne correspond pas tout à fait ceci, mais cela ne vous dit peut-être pas exactement quel est le problème.

Considérez le scénario possible suivant et voyez s'il correspond à la manière dont vous avez codé ce programme.

Pour que le système d'exploitation gère la mémoire, il peut décharger des vues et les recharger au besoin. Lorsque cela est fait, les méthodes viewDInLoad, LoadView et ViewDidLoad sont appelées.

ViewDidunload:

Cette méthode est appelée contrepartie à la méthode ViewDidLoad. Il est appelé pendant les conditions de mémoire faible lorsque le contrôleur d'affichage doit libérer sa vue et tous les objets associés à cette vue pour libérer la mémoire. Étant donné que les contrôleurs d'affichage stockent souvent des références à des vues et d'autres objets liés à la vue, vous devez utiliser cette méthode pour renoncer à la propriété de ces objets afin que la mémoire puisse être récupérée. Vous devez le faire uniquement pour les objets que vous pouvez facilement recréer ultérieurement, que ce soit dans votre méthode ViewDidLoad ou à partir d'autres parties de votre application. Vous ne devez pas utiliser cette méthode pour libérer des données utilisateur ou d'autres informations qui ne peuvent pas être facilement recréées.

LOADVIEW:

Le contrôleur d'affichage appelle cette méthode lorsque la propriété View est demandée mais est actuellement nulle. Si vous créez vos vues manuellement, vous devez remplacer cette méthode et l'utiliser pour créer vos points de vue. Si vous utilisez l'interface Builder pour créer vos vues et initialiser le contrôleur d'affichage, vous initialisez la vue à l'aide de l'initwithnibname: Bundle: méthode, définissez directement les propriétés NIBNAME et NIBBUNDLE, ou créez votre contrôleur de vues et affichage dans l'interface Builder- Ensuite, vous ne devez pas remplacer cette méthode.

Vérifiez la référence de la classe UIView -

ViewDidLoad:

Cette méthode est appelée après que le contrôleur d'affichage a chargé ses vues associées dans la mémoire. Cette méthode est appelée si les vues ont été stockées dans un fichier NIB ou créé par programme dans la méthode LoadView. Cette méthode est la plus couramment utilisée pour effectuer des étapes d'initialisation supplémentaires sur des vues chargées à partir de fichiers NIB.

Vous pouvez avoir initialement initialisé ces points de vue dans vos méthodes init plutôt que dans vos méthodes LoadView. Si vous l'avez fait, alors lorsque le système d'exploitation décharge une vue (vous verrez ViewDiDunload est appelé) La mémoire associée à la vue et à toutes les sous-étapes (toutes les images et animations) seront déchargées. Cela permet de sauve la mémoire, mais lorsque vous avez besoin d'une de ces vues non chargées pour réapparaître, LockView sera appelé en premier si la vue avait déjà été déchargée. Si votre configuration de visualisation est effectuée dans les méthodes init plutôt que dans LoadView, la vue ne sera plus configurée. Mais si la configuration de la vue est effectuée dans la méthode LoadView, elle peut être récupérée après la décharge de la gestion de la mémoire.

Il y a un moyen facile de trouver des fuites difficiles à trouver via des instruments de fuite et ainsi de suite - analyseur de zombies. Il affiche chaque mémoire non liée dans votre programme et vous pouvez facilement détecter des fuites et optimiser le code en minutes.

Si vous utilisez beaucoup d'images pour une seule animation, vous le faites mal. Vous devez en avoir un, ou plusieurs très grandes images, puis montrer une partie de cette image. De cette façon, vous pouvez charger très peu d'images, mais avoir le même affect d'avoir de nombreuses images.

Regardez dans Cocos2D ou dans d'autres cadres populaires pour faire des jeux, car ils seront beaucoup plus efficaces pour les animations que l'UIKIT.

Découvrez la raison du crash de mémoire à l'aide de l'outil Instrument, puis refactorisez le code avec les meilleures pratiques avec le modèle de conception recommandé. Il n'y a pas de solution unique pour cela. Merci.