Version imprimable
Bonjour,
Mon application Android est assez lente et "crash" apres avoir navigué dans plusieurs pages.
Ci-joint les détails du Debug réalisé sur le simulateur.
La mémoire de mon application chute de 77% a 3% libre au lancement de l'application, alors que l'UI n'a pas encore été chargée.
Ensuite la mémoire libre oscille entre 7 et 9% jusqu'au "crash".
J'utilise l'API 14.
Quelqu'un aurait une idée de la cause?
Tu n'as que ça ?
Pas les traces du crash lui-même ?
L'application crash au 5eme chargement de page.Citation:
Envoyé par Hizin
Je recois pleins de messages comme ceci pendant le crash:
Puis le debugger est détaché et je me retrouve a la page d'accueil Android.Code:
2
3
4
J'ai mis le log complet ci-joint (3 fichiers texte).
PS: "FileUpload" est le nom de l'application, mais pour le moment je ne fais que générer un formulaire. Dans les log il y a des messages d'erreur avec SQLLite et des services Google mais je n'utilise rien de tout cela.
Tu utilises bien Mono, je ne me trompe pas ?
En lisant les traces, je vois que l'application est lancée à 16:43:25, puis que l'activité FileUpload.ViewContainer est successivement lancée à 16:43:50, 16:43:59, 16:44:06 et 16:44:15. Ensuite vient le GC. J'imagine donc que ce sont les 5 pages.
Les libérations du GC peuvent être normales, mais peuvent indiquer d'autres choses (là, cette phrase aide beaucoup :) ). Après que le GC ait bien bouclé, je lis à 16:45:15 le fatidique "Application Not Responding" pour FileUpload.ViewContainer => 5 secondes de wait.
Alors, à priori, je dirai que tu as une boucle infinie quelque part avec de nombreuses créations d'objets, d'où le GC qui libère à fond. Par contre, quelle est cette boucle ? Là, je ne sais pas.
Ce qui est sûr, c'est que ton application freeze totalement, et est tuée suite à ça.
Pour les autres erreurs, c'est Android qui tente de faire sa tambouille, mais il n'a pas accès à ce qu'il faut sur l'émulateur, d'où les erreurs polluantes.
Merci pour ton aide précieuse Hizin, je sais qu'analyser les traces d'un debug n'est pas marrant :ccool:
Je t'explique brievement le fonctionnement de mon application comme ca ca t'aidera peut-etre a mieux comprendre.
J'ai une seule Activity dans mon application qui est responsable d'afficher la vue (style MVC en quelque sorte). Quand l'Activity se lance, j'affiche une animation de chargement (avec une WebView) puis je charge la vue dans un autre thread. Mes vues sont de simples classes qui déclarent et positionnent les controles. La déclaration de ces controles est faites manuellement, c'est a dire que j'ai créer mes propres classes Bouton, Label, etc.
Une fois que mon Activity a charger les controles de la Vue, je les convertis en controles Android grace a mon moteur de rendu (par exemple le controle "Image de ma vue sera rendu en "ImageView" Android). A chaque navigation entre page je rapelle mon Activity donc regénere tout ce qui permet un premier nettoyage de la mémoire.
Oui, mais Mono génere du Java qu'avec Eclipse ou autre donc il est externe a mon probleme.Citation:
Envoyé par Hizin
Tout a fait, j'ai une seule "Activity" dans mon application que j'apelle a chaque fois, je lui passe un parametre qui est le nom de la vue a charger.Citation:
Envoyé par Hizin
La boucle infinie je n'y crois pas trop, car pour charger les 5 pages je faisais comme ceci:Citation:
Envoyé par Hizin
Page accueil => Page 1 + (boutton Back simulateur): 5 fois consécutives pour obtenir le crash.
Donc si la page 1 avait une boucle infinie le crash surviendrait au 1er chargement, ce qui n'est pas le cas.
Mais le passage de 77% de mémoire libre au démarrage a 7%, tu en penses quoi? N'est-ce pas a ce niveau le grand probleme, car je ne sais pas ce qui peux consommer 70%? Peut-etre que je n'alloue pas assez de mémoire a mon simulateur aussi.Citation:
Envoyé par Hizin
Pour Mono, vu que je ne l'ai jamais utilisé, c'était uniquement pour confirmer ce que je lisais ^^
Au passage, je trouve marrant de nommer un processus "Sepuku".
Les erreurs de mémoires sont assez caractéristiques, avec un message du style "je tente d'allouer 33 Mo, alors que je n'ai que 32 Mo, je dépasse la limite et je crash".
De plus, tu ne devrais pas avoir un crash selon ce que je lis des logs, mais un pop-up disant "l'application ne répond pas".
Avec cette info, ça me fait plutôt penser à un contexte qui n'est pas libéré.Citation:
Envoyé par alex_vino
1er lancement : standard, mise en mémoire, normal
2ème lancement : garde en mémoire le tout du premier, lance une seconde fois
3ème lancement : garde en mémoire le 1er et le 2ème, lance une troisième fois.
4ème lancement : garde en mémoire le 1er, le 2ème et le 3ème, lance une quatrième fois
5ème lancement : garde en mémoire le 1er, le 2ème, le 3ème et le 4ème, lance une 5ème fois, puis plante.
Avec cette configuration, tu garderais en mémoire, au cinquième lancement, 23 fois l'activité (si je ne me trompe pas dans le compte).
Là, je passerai plutôt la main à Nicroman, qui a plus l'habitude que moi des soucis de garde en mémoire de contextes succexssifs, mais à mon avis, c'est le souci.
Pour la mémoire elle-même (77, 7), ça ne me paraît pas aberrant. Le lancement utilise beaucoup avec les objets temporaires, et une fois fait, les objets finaux restent en place.
Je dis ça, je ne sais pas véritablement non plus, je n'ai pas fait ce type de mesure pour mes soucis de mémoires.
Je subit les noms de processus :mrgreen:
J'ai eu une pop-up sur mon simulateur me demandant d'attendre l'application ou de l'arreter comme elle ne semblait pas repondre, j'ai choisis "attendre" pour continuer les logs.
En effet la gestion memoire n'est pas simple et tres importante, je ne m'en suis presque jamais soucier dans ma carriere avant de faire du developpement pour OS mobile.
Du coup si j'ai bien compris ton raisonnement il me faudrait forcer l'evenement onDestroy() de chaque Activity lorsque je lance une nouvelle Activity?
Si c'est le cas alors ca risque d'etre problematique si l'utilisateur appuie sur le bouton "Retour" de son smartphone, car cela signifierais que tu decide d'afficher une page qui devrait etre censee etre en memoire.
Quel est ton processus de liberation memoire lors d'appel d'une nouvelle Activity?
Pour eviter justement les problemes memoire j'evite de declarer statiquement mes controles.
PS: Pourquoi dans ton raisonnement l'activite est chargee 23 fois en memoire, et non pas 5 fois?
Je me dois de donner une réponse vu qu'on a mentionné mon nom ^^
Voilà ma réponse: aucune idée ! :mouarf:
A première vue, je dirais un problème de mono lui même... d'autant que monodroid semble faire des GC explicites (GC_EXPLICIT veut dire qu'on a appelé System.gc() ).
Sachant qu'un gc peut potentiellement faire un stall complet (de tous les threads) pendant 100ms... l'appeler toutes les secondes est un non-sens complet:
La question qui me tarabuste, est "pourquoi utiliser mono" ?Code:
2
3
4
5
6
7
Faire du .Net sur Android c'est un peu comme vouloir faire du Anrdroid sur iOS, ou du iOS sur RIM ^^
Par contre il y a beaucoup d'allocations de 1429408 bytes (1.4Mo c'est pas rien)
Une solution serait de faire un snapshot de la mémoire après 3/4 lancements, et l'analyser dans Eclipse
Oui haha :zoubi:Citation:
Envoyé par nicroman
Je doute quand meme que Mono montre ses limites si rapidement dans mon cas pour le moment plutot simpliste, d'autant plus que Mono est une solution fiable depuis quelques temps maintenant et genere le meme code Java qu'un utilisateur ecrirais en Java.Citation:
Envoyé par nicroman
En fait c'est relativement simple: "Write once, run everywhere", le code C# que tu ecrit te permettra de generer des applications pour:Citation:
Envoyé par nicroman
- Android
- iOS
- Windows Phone
- HTML (ASP.Net)
Le tout sans la moindre modification necessaire entre chaque plateforme (les specificites de chaque plateforme seront gerees par des templates). Quand le client te demande de gerer un nouveau OS mobile tu n'a rien a faire, et encore moins apprendre un nouveau language ni meme redevelopper une enieme fois toutes tes classes.
Je suis d'accord, mais dans le cas present c'est parce que la memoire est saturee, les GC se font automatiquement car c'est l'unique chance d'eviter le crash, c'est un peu le cri du desespoir.Citation:
Envoyé par nicroman
Je n'ai pas vraiment de notion de ce que ca peux representer pour ce type de peripherique. J'ai utiliser les outils du SDK pour essayer de trouver et comprendre les fuites memoires mais ca ne m'aide pas vraiment, peut-etre que c'est parce que je l'utilise mal aussi, mais je n'arrive pas a trouver quel objet consomme autant.Citation:
Envoyé par nicroman
Alors, l'outil dans eclipse est simple: le DDMS ;)
1. Le SDK est-il à jour ?
(20.2: Fixed memory leak in the emulator. )
2. Ouvrir le DDMS.
a. Sélectionner le processus qu'on veut "débugger" dans la liste
b. Vérifier les threads en cours, et ce qu'ils font (il est possible de les arrêter et regarder leur 'stack' pour peu qu'on ai les sources).
c. Un bouton doit alors être disponible avec une flèche rouge vers le bas (dans la barre des device/process): "dump hprof file".
Et voilà...
Ensuite il faut un outil pour "lire" le hprof... perosnnellement, j'ai installé MAT dans Eclipse (http://www.eclipse.org/mat/) du coup, le dump hprof ouvre MAT automatiquement avec toutes les traductions nécessaires.
Une fois un hprof ouvert dans MAT, LA valeur intéressante est "retained heap" c'est la taille mémoire conservée pour un objet (ce qui inclut les objets indirectement référencés par cet objet).
A noter: le dump de hprof est assez long et 'bloque' le process, le device va certainement râler pour une application "not responding", c'est normal et juste demander "d'attendre" la fin du hprof.
Juste une addition: les GREFs (global JNI references) sont limité à 2000 dans une application android.
Mono, s’apercevant qu'on se rapproche de cette limite doit certainement forcer un gc() à chaque allocation (ce qui est inutile, mais bon... pourquoi pas) JNI.
Je ne sais pas du tout comment fonctionne Mono sur android, mais il semble que chaque objet .Net se retrouve dans le JNI, 2000 objets max du coup, ça fait un peu léger...
Merci beaucoup @Hizin et @microman, ces informations me seront tres utiles :ccool:
Oui mon SDK est a jour.
Je vais chercher un systeme similaire a MAT pour Visual Studio et étudier de plus pres ce qui se passe grace au hprof.
Je posterais de nouveau lorsque j'aurais davantage avancé sur le sujet.