Discussion :

[alex_vino]

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?

[Hizin]

Tu n'as que ça ?
Pas les traces du crash lui-même ?

[alex_vino]

Tu n'as que ça ?
Pas les traces du crash lui-même ?

L'application crash au 5eme chargement de page.

Je recois pleins de messages comme ceci pendant le crash:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
09-28 16:44:56.057 D/dalvikvm( 3140): GC_EXPLICIT freed 2K, 4% free 20533K/21191K, paused 5ms+21ms
09-28 16:44:56.137 I/monodroid-gc( 3140): 1822 outstanding GREFs. Performing a full GC!
09-28 16:44:57.957 D/dalvikvm( 3140): GC_EXPLICIT freed 5K, 3% free 20556K/21191K, paused 177ms+21ms
09-28 16:44:58.057 I/monodroid-gc( 3140): 1823 outstanding GREFs. Performing a full GC!

Puis le debugger est détaché et je me retrouve a la page d'accueil Android.

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.

[Hizin]

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.

[alex_vino]

Merci pour ton aide précieuse Hizin, je sais qu'analyser les traces d'un debug n'est pas marrant

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.

Tu utilises bien Mono, je ne me trompe pas ?

Oui, mais Mono génere du Java qu'avec Eclipse ou autre donc il est externe a mon probleme.

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.

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.

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.

La boucle infinie je n'y crois pas trop, car pour charger les 5 pages je faisais comme ceci:
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.

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.

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.

[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".

La boucle infinie je n'y crois pas trop, car pour charger les 5 pages je faisais comme ceci:
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.

Avec cette info, ça me fait plutôt penser à un contexte qui n'est pas libéré.
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.

[alex_vino]

Je subit les noms de processus

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?

[nicroman]

Je me dois de donner une réponse vu qu'on a mentionné mon nom ^^

Voilà ma réponse: aucune idée !

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:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
9-28 16:44:36.478: D/dalvikvm(3140): GC_EXPLICIT freed 28K, 5% free 20335K/21191K, paused 4ms+15ms
09-28 16:44:36.547: I/monodroid-gc(3140): 1814 outstanding GREFs. Performing a full GC!
09-28 16:44:37.447: D/dalvikvm(3140): GC_EXPLICIT freed 25K, 4% free 20352K/21191K, paused 4ms+15ms
09-28 16:44:37.547: I/monodroid-gc(3140): 1815 outstanding GREFs. Performing a full GC!
09-28 16:44:38.487: D/dalvikvm(3140): GC_EXPLICIT freed 26K, 4% free 20368K/21191K, paused 5ms+30ms
09-28 16:44:38.587: I/monodroid-gc(3140): 1816 outstanding GREFs. Performing a full GC!

La question qui me tarabuste, est "pourquoi utiliser mono" ?
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

[alex_vino]

Je me dois de donner une réponse vu qu'on a mentionné mon nom ^^

Oui haha

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() ).

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.

La question qui me tarabuste, est "pourquoi utiliser mono" ?
Faire du .Net sur Android c'est un peu comme vouloir faire du Anrdroid sur iOS, ou du iOS sur RIM ^^

En fait c'est relativement simple: "Write once, run everywhere", le code C# que tu ecrit te permettra de generer des applications pour:
- 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.

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:

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.

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

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.