J'essaie de trouver des fuites dans mon application à l'aide de l'instrument de fuite. Lorsque l'application est lancée, je peux voir 106 fuites et j'ai du mal à les trouver.
Dans l'image, vous pouvez voir une partie de la liste, mais comment puis-je explorer la classe ou la ligne de code qui génère la fuite?
3 Réponses :
Vous pouvez voir le trice de pile sur le côté droit de l'écran. Et après cela, faites défiler jusqu'à la classe et la méthode qui créent la fuite. Il est parfois difficile de comprendre pourquoi vous avez la fuite.
Regardez mon image 
J'ai TermsViewController et j'ai la chaîne NSMuttableAttributed qui crée des fuites de mémoire. De plus, si je sélectionne la ligne avec TermsViewController.setupInfoText (), cela ouvre le code.
Trouver une fuite n'est pas si simple. Vous devez porter la casquette de détective, sortir votre loupe de votre manteau et commencer à trouver la piste. c'est-à-dire
Pour chaque objet divulgué, il existe une bibliothèque responsable. S'il s'agit d'un UIKit, d'une Fondation ou de tout autre élément de bas niveau, vous ne pourrez pas identifier l'emplacement du code à l'origine de la fuite car ces bibliothèques se présentent sous la forme de binaires.
Si la bibliothèque responsable est celle que vous écrivez, vous pouvez accéder au code en cliquant sur la bonne méthode dans le panneau de trace de pile à droite. Un indice est que les méthodes répertoriées dans le panneau de suivi de la pile sont mises en surbrillance si un code correspondant est disponible.
Mais, comme ce n'est pas si simple, votre propre morceau de code provoque souvent une fuite d'une bibliothèque interne, ce qui est difficile à déboguer. Vous devez suivre des didacticiels et du matériel de pratique avant de commencer. Quelque chose ne peut certainement pas répondre sur stackoverflow.
Le problème est que je ne parviens pas à accéder à mon code via le panneau de suivi de la pile, y a-t-il quelque chose que je fais?
Si vous voulez trouver le code allouant la mémoire perdue, passez à l'arborescence des appels en utilisant la barre de saut. Pour trouver votre code dans l'arborescence des appels, inversez l'arborescence des appels et masquez les bibliothèques système.
Double-cliquez sur l'une de vos fonctions dans l'arborescence des appels pour accéder à la ligne de code qui a alloué la mémoire perdue.
Lisez l'article suivant pour des informations plus détaillées sur l'utilisation d'instruments pour trouver des fuites de mémoire:
Mesure de l'utilisation de la mémoire de votre application avec des instruments < / p>
Ok, donc je l'ai fait et j'ai obtenu certaines des pièces du puzzle. Je peux voir que la plupart des fuites proviennent de cocoapodes comme: alamofire, swinjectstoryboard et ainsi de suite. est-ce que cela a du sens? en plus je peux toujours accéder au code réel
Il est possible que les frameworks externes dans CocoaPods aient des fuites de mémoire. Je n'ai pas utilisé d'instruments avec les CocoaPods, donc je ne peux pas vous dire s'il existe un moyen de déterminer quelles fuites se trouvent dans votre code et quelles fuites se trouvent dans les CocoaPods.
Avant toute avancée, utilisez le graphe de mémoire de débogage pour trouver ces
!violets et les résoudre@ E.Coms pouvez-vous élaborer?
rechercher
graphe de mémoire de débogagedans SO. comme ici stackoverflow.com/questions/44803692/…