Je suis à la partie de mon processus de développement pour traquer les fuites de mémoire et qui se brisent. En tant que stratégie, ne vous mettez des messages NSLog ou notifications de certains comme dans didReceiveMemoryWarning:? La documentation de cette méthode est plutôt clairsemée. Est - il exact de dire que , avant un accident se produira, le UIViewController déclenchera cette méthode? Est - ce un point de départ avant même aller de l' avant avec des instruments?
iOS: serviabilité didReceiveMemoryWarning:
voix
12
4 réponses
voix 28
28
OK, plusieurs choses à noter:
- didReceiveMemoryWarning sera appelé avant un accident hors mémoire. Pas d'autres accidents. Si vous gérez correctement l'avertissement et libérer de la mémoire, vous pouvez éviter la condition hors de la mémoire et de ne pas tomber en panne.
- Vous pouvez déclencher manuellement un avertissement de mémoire dans le simulateur dans le menu Hardware. Je recommande vivement le faire pour tester votre manipulation de didReceiveMemoryWarning.
- Instruments vous permet de déboguer les fuites (mais pas tous) - ce n'est pas vraiment utile pour les accidents.
- Non, je ne l'utilise personnellement NSLog - Je viens de les avertissements de point d'arrêt mémoire quand je suis débogage.
voix 5
5
Si l'utilisateur a laissé quelques applications que vous aurez ouvert très peu de mémoire à votre disposition. Alors parfois , didReceiveMemoryWarningpeut être appelé par le système seulement après 1 Mo d'utilisation.
Le système appelle cette méthode sur tous vos contrôleurs de vue, si vous placez un NSLog dans chacun de vos contrôleurs de vue, vous remarquerez que.
Ensuite automatiquement la méthode viewDidUnloadsera appelée par le système sur tous vos contrôleurs de vue (non dealloc). Donc , vous devez mettre toutes les instructions de votre désallocation là - dedans.
Vous devez faire beaucoup d'expériences parce que si votre application est complexe, vous faites face à beaucoup d'accidents avant bien la gérer.
voix 4
4
MISE À JOUR
Au iOS 6, des UIViewControllervues ne sont plus déchargés en réponse aux avertissements de mémoire. Au lieu de cela faire de votre mieux pour libérer les ressources que vous pouvez raisonnablement recréer (par exemple les données mises en cache) lorsque l' didReceiveMemoryWarningon appelle.
Mise à jour
je l' ai écrit ma première réponse quand j'étais un jeune homme en colère; les temps ont changé et au fond, ce qui ne va pas.
Si vous avez une application avec un seul contrôleur de vue et que vous recevez un avertissement de mémoire, il n'y a pas grand - chose que vous pouvez faire. Mais les choses changent considérablement si vous avez plusieurs contrôleurs de vue, parce que vous pouvez décharger tout l'état associé aux contrôleurs non au premier plan. En fait [UIViewController didReceiveMemoryWarning]vous aiguillonner dans la bonne direction en déchargeant vos vues non visibles pour vous (surprise!). Lorsque le contrôleur de vue est rejeté en avant, la vue sous - jacente est rechargée et au plus l'utilisateur ne doit être au courant d'un retard , même si votre application interne peut avoir fait un redémarrage complet.
Ce n'est pas certains détails , vous pouvez facilement modifier, vous devez garder utilisation de la mémoire à l' esprit dès le début et la conception de votre application proprement MultiView dans déchargeables UIViewControllerpièces. En fait , il vaut la peine de garder votre code compatible avec le simulateur juste pour utiliser sa fonction d'avertissement de mémoire.
Lorsque la mémoire est abondante, rien et tout est à vide est douce et soyeuse, et quand la mémoire est faible les choses continuer à travailler, bien que plus lentement. Maintenant, je dirais que cette solution au problème de la mémoire finie est idéale.
Pour profiter de ce tour de passe-mémoire, surcharge les UIViewControllerméthodes
viewDidLoad, viewDidUnloadet
viewWillUnload(iOS5, utile si le déchargement Etat exige votre point de vue d'exister encore, par exemple , si vous ne voulez pas fuir vos textures OpenGL et rendu tampon, sur iOS4 vous pouvez simuler cela en surcharge didReceiveMemoryWarninget le suivi de la visibilité de votre point de vue).
ORIGINAL, PLUS RÉPONSE bilieux
didReceiveMemoryWarning est tout à fait inutile.
Il n'y a aucune garantie que si vous libérer de la mémoire (même la totalité) que vous ne serez pas tué.
Dans mon expérience amère il travaille habituellement comme celui-ci sur 2.x / 3.0:
mediaserverd fuit un tas de mémoire
mon application est tué
Malheureusement, le moissonneur ne pense jamais à tuer mediaserverd.
Donc, si l'utilisation de la mémoire est pas votre faute, vous avez vraiment seulement deux choix:
demander à l'utilisateur de redémarrer (l'utilisateur suppose qu'il est de votre faute, écrit une critique acerbe)
espère que le coupable plante (mediaserverd oblige souvent!)
voix 3
3
Le but de didReceiveMemoryWarning est de vous donner une chance de libérer de la mémoire ou de la pop vue d'éviter un accident. Vous ne recevrez pas à tout moment prévisible car cela dépend de ce que l'utilisateur est en train de faire. Par exemple, si l'utilisateur écoute l'iPod, il y a moins de mémoire disponible et vous recevrez plus tôt.
La règle générale est que vous avez environ 8 Mo de RAM pour travailler avec. Lorsque vous approchez de ce que vous pouvez vous attendre l'événement à soulever. Si vous prenez jusqu'à ce que beaucoup de RAM délibérément vous devriez avoir un plan pour faire quelque chose à ce sujet.