problème de mémoire ?
alain777
Membre
Bonjour,
J'ai fait une app simple pour iPhone.
Le problème, c'est qu'elle "mange" pas mal de mémoire,il y a un tableau de type c de taille 2500 et je ne sais pas comment l'annuler pour annuler cette mémoire à la fin de son utilisation. Quand je lance l app sur mon iPhone 4S, elle marche super bien pendant un moment puis au fur et a mesure que je la lance, elle se ralentit au point de ne plus être utilisable à la fin car presque bloquée. Le problème c'est que l'image de lancement se relance de temps en temps seulement et alors là oui ça remarche mais comme cette image ne se lance pas systématiquement, ça bloque vite fait. Mes questions sont :
-comment vider de la mémoire mon tableau de type C (qui n'est pas un NSArray ni NSMutableArray mais un tableau comme on en déclare en C) ,quand j'ai fini de l'utiliser
-comment faire pour que l'image de lancement se lance à chaque démarrage de mon app ?
Merci beaucoup de m'avoir lu et d'éventuellement pouvoir m'aider. ::)
Réponses
Ton application utilise ARC ?? (c'est un garbage collector)
Si oui c'est très bizarre
oui, elle utilise ARC....d'où mon malaise....
Comment créées-tu ton tableau ?
Pourquoi utiliser un tableau C ? As-tu réellement besoin constamment de ces 2500 cases ?
As-tu un Memory Warning ?
en fait je crée deux tableaux :
mais subview je le vide par un nil lorsque j ai fini de l utiliser....
quant à rectangle, je ne sais comment faire, nil ne marche pas car ce n'est pas un pointer...
je ne suis pas un pro lil
en fait j ai résolu le problème de la mémoire du aux tableaux (je n utilise plus de tableaux et ça marche aussi bien lol)
par contre, je suis intéressé de savoir comment faire pour que l image de lancement se lance à chaque démarrage de l app, quelqu un a t il déjà rencontré un tel problème ? Merci beaucoup.
Tu crée un tableau de plus de 2500 vues :OOOOOOOOOOO
oui mea culpa ;D
par contre je cherche à savoir pour le lancement de l image de l app...
Ca ???
MAJ : C'est la façon la plus simple et correcte que j'ai trouvé
Apres elle ne répondra pas forcement à tes attentes
Pas du tout... Contrairement au Garbage Collector, ARC effectue sa tambouille à la compilation en plaçant des release de façon invisible pour le développeur. D'où l'intérêt de tout de même connaitre les principes de base du MRC afin de correctement déclarer ses propriétés.
Pour revenir au sujet principal : c'est du grand n'importe quoi ce que tu as fait..
Essaie de nous expliquer ce que tu veux faire et on t'orienteras vers une solution beaucoup plus simple et rapide...
Bah de toute façon, les tableaux C ont une taille fixée à la compilation, donc au démarrage du programme, les tableaux consomment déjà un espace mémoire de 2500 * sizeof(CGRect) + 2500 * sizeof(UIView *).
C'est déjà une aberration en soit, mais ça n'explique en rien le fait que le programme se met à ramer. Par contre instancier 2500 UIView ou dérivés, ça, ça peut faire ramer à terme puisque ça consomme petit à petit de la mémoire sur le tas.
Oui mais au fond l'ARC rejoint le principe de garbage collector comme celui du Java sauf qu'Apple a zigouillé puis appelé ARC
Pas du tout... -.- Y'a une grande différence entre un gros bouzin qui balaye ton app en permanence pendant qu'elle tourne histoire de voir si y'a pas des objets que t'utilises plus et un système qui agit intelligemment à la compilation de ton app en plaçant des release là où il faut et ainsi éviter l'erreur humaine le plus possible et aussi optimiser les appels de release...
Bon bah j'ai rien dit alors
La seule similitude c'est que pour celui qui code dans les faits dans les 2 cas il n'a plus à libérer la mémoire lui-même via des instructions de code, mais ça s'arrête là . ARC est bien plus puissant que du GC et est implémenté de manière totalement différente. Ce n'est pas un ramasse-miette qui fait le ménage quand il a le temps et seulement après un petit moment comme le GC, c'est une gestion à la compilation qui rajoute les instructions nécessaire au plus tôt dans le code compilé ; ce qui rend le système ARC carrément plus efficace. Du coup en terme de performance, d'empreinte mémoire et d'implémentation les 2 ne sont pas comparables, ARC étant bien plus optimal dans tous ces cas.
Oui. Mais uniquement du point de vue du novice (en dév) qui ne sait pas ce qui se passe derrière et n'a aucune notion de libération de la mémoire et surtout de quand elle va se faire, parce que dans les faits...
Vu que je suis novice ;D c'est pour ca que je disais ca
Etonné par la réponse d'Aligator merci : c'est complet directe et précis
Alors qu'avec un GC comme en Java, y'a pas de détection a la compilation, donc s'il y a un de ces problèmes bon courage pour faire du stress-test de ton appli pendant des heures pour t'en apercevoir, et pire encore, du coup y'a un ramasse-miette qui tourne en permanence à l'exécution et qui examine régulièrement tous les objets crées depuis le début de l'appli pour voir s'il y en a qui pourraient être libérés, en devant vérifier à chaque passé que personne les utilise... donc ça prend du temps et du CPU à l'exécution, ça ne relâche les objets que quand le ramasse-miette décide de passer (pas forcément à tous les cycles), laissant potentiellement la mémoire grimper haut avant qu'elle soit nettoyée que plus tard pour enfin redescendre... tu m'étonnes que l'empreinte mémoire grimpe et que les perfs soient ralenties par l'exécution de cette analyse de la mémoire régulière quand tu utilises un GC... alors qu'avec ARC, rien de tous ces inconvénients, et aucune dégradation au Runtime. Au contraire même, plutôt une accélération d'ailleurs, car les balancements entre retain et release sont optimisés et "collapsed across methods calls and returns" comme expliqué en long, en large et en travers dans les vidéos de la WWDC de l'an dernier où tout ça est très vin expliqué dans les moindres détails.