Un point sympa dans le développement d’application iPhone, c’est que la mémoire est très limitée. Il faut donc être rigoureux car sur l’iPhone, il n’y a pas de ramasse miettes (le fameux éboueur qui ramasse vos objets). Chaque objet alloué doit être libéré proprement sans quoi l’application tournera pas très longtemps (le système n’aime pas les gourmands).
Deux possibilités s’offre à nous.
- Instruments : Apple propose un outil permettant de vérifier les objets qui ne sont pas libérés. Pour ce faire, il faut lancer l’application (ça marche avec le simulateur, mais sur l’iPhone, c’est mieux) depuis le menu Run -> Run with Performance Tool -> Leaks. L’application se lance, et Instruments vérifie toutes les 10 secondes les objets qui n’ont pas été libérés.
Plus que pratique, l’application liste les fuites mémoires, et vous montre même quelle bibliothèque, quel objet est fautif. Dans la vue étendue (View -> Extended details), on a même la pile d’appel. On voit ainsi à quel endroit est alloué l’objet en question :
Cette solution n’est pas si pratique que cela car l’application est très fortement ratlentie. Donc tester les fuites mémoire de cette manière devient long et souvent impossible (lecture audio, vidéo, utilisation de l’accéléromètre…). - Une autre solution consiste à demander l’analyse du code par Clang. Dans les options de compilation du projet se trouve une case intéressante :
Cette analyse met le doigt sur les fuites potentielles, et plus encore. Voici un extrait des résultats que vous pourriez avoir avec votre projet :
La deuxième méthode est vraiment plus efficace, même si des “faux positifs” seront levés (comme le singleton ci dessus). Cela évitera de lancer l’application et d’attendre de longs instants que les traitements soient réalisés.
