Discussion :

[Xavi_bgsec]

Hello,

Je suis débutant en programmation Android, et je compte m'y mettre pour réaliser quelques applications. Je fais des tutos, je progresse, je rage contre le Java (venant du C++..), mais mon principal souci actuel se trouve au niveau des outils.

J'ai commencé sous Eclipse, puis Aptana, avant de passer sur Android Studio. Dans les 3 cas, je me suis retrouvé confronté à quelques problèmes et j'espère que vous pourrez me donner quelques solutions pour réduire le temps perdu :

-Debugger : J'utilise beaucoup les breakpoints pour faire du pas à pas sur certains blocks : Android Studio met un temps fou à afficher le contexte en mode pas à pas. Ca peut durer jusqu'à 5 secondes par step alors que le contexte ne change pas. Y-a-t-il un moyen de faire du pas à pas plus rapidement ? Je m'y prend mal ? mon PC est-il la cause ? J'en viendrais presque à ne plus utiliser de breakpoints pour gagner du temps. Et je parle de breakpoints simples (pas de conditionnel ou de data breakpoins, je ne sais même pas si il y en a!)

-Log : Pour le log, je n'ai pas l'impression que ce soit un problème de config, mais Logcat me logge des centaines de lignes à l'execution, si bien que j'en suis à mettre une clé dans mes log pour pouvoir filtrer. Quand je crashe, il faut aller retrouver la dernière ligne ou l'application a crashé, car le log continue à tourner même après un crash. J'ai beau essayer de filtrer .v, .i, .d, impossible d'avoir un log cohérent et clair. Le log m'annonce aussi des erreurs, qui n'ont absolument aucun impact sur l'application. Il y a d'autres alternatives à logcat pour récupérer le contexte d'un crash ?

-Lenteur de l'émulateur : J'utilise AVD, comme beaucoup je suppose. D'une part l'émulateur met un sacré temps à se lancer, mais il est surtout très lent à l'execution en debug. Pour l'instant je fais des appli toutes betes, des formulaires, j'ai peur pour la suite. L'émulateur prend aussi beaucoup de mémoire, est il possible que j'émule un appareil trop puissant pour mon PC ?

Ce sont les 3 premiers problèmes qui me plombent un peu la programmation. Est ce que je m'y prends mal ? Est ce que tous les IDE Android sont des usines à gaz ? Est ce que j'ai mal configuré le logiciel ? d'autres IDE revolutionnaires ?

Ca ne se voit peut être pas dans mon post mais je suis vraiment motivé pour travailler sur Android. J'essaye juste d'optimiser un peu les outils utilisés parceque pour le moment, j'ai vraiment l'impression de passer plus de temps à attendre que le logiciel réponde que de l'utiliser.

Merci pour vos réponses

[plawyx]

Hello,

-Lenteur de l'émulateur : J'utilise AVD, comme beaucoup je suppose. D'une part l'émulateur met un sacré temps à se lancer, mais il est surtout très lent à l'execution en debug. Pour l'instant je fais des appli toutes betes, des formulaires, j'ai peur pour la suite. L'émulateur prend aussi beaucoup de mémoire, est il possible que j'émule un appareil trop puissant pour mon PC ?

C'est vrai que l'émulateur est un peu lent, mais cela reste tout à fait acceptable. A prioiri, le point commun dans la liste de tes problèmes semble être ton pc.

config perso: core i7, 12 Go de ram, debian wheezy 7.0 64 bits, eclipse 4.3

[Xavi_bgsec]

Mon PC n'est pas une foudre de guerre, mais concernant Visual Studio ou pour des jeux vidéos récents, il n'y a pas de problèmes. C'est justement la différence qui est assez frappante.

Android Studio et AVD sollicitent peut être beaucoup la RAM ? (si l'emulateur réserve un slot de Ram correspondant à l'appareil émulé ?) ou bien beaucoup d'accès disque ?(vu l'explorer de projet)

[Hizin]

Android Studio, je ne sais pas, mais l'IDE sur lequel il est basé (IntelliJ IDEA) demande moins de ressources qu'Eclipse, donc je suppute qu'Android Studio aussi.

En mode debug, l'application est plus lente. Ca, c'est normal (demander à un langage de garder des objets en mémoire, d'inspecter le code et de faire attention aux optimisations JIT, je pense que ça ralentit tout les langages). De mon coté, je n'ai pas une aussi grosse lenteur (sauf sur du parsing massif de JSON/XML).

Pour les logs : bienvenu dans le monde d'Android. Tu n'es pas le seul à utiliser Dalvik, et quand tu n'es pas le seul à utiliser une ressource, tu as les traces des autres. C'est pour cette raison (entre autre) que le premier paramètre du Log est un tag. Tu peux aussi filtrer par niveau de log.
Après, cela dépend des terminaux. Les Samsungs ont la très mauvaise habitude de sortir des kilomètres de log totalement inutile par exemple.

Pour l'émulateur, le créer avec l'architecture armeabi est plus rapide. Il y a une autre solution à base de machine virtuelle qui fait pas mal parler d'elle en ce moment : GenyMotion. Je l'utilise et à part une instabilité notable vis-à-vis d'ADB sous Linux, pas grand chose à signaler. Le problème que j'ai avec est que les images sont plus rapides que les terminaux réels. L'image du Nexus S est plus rapide que le mien x)

Après, vu que tu viens du C++, tu peux peut-être t'intéresser au NDK. Google préconise de faire plutôt les applications en Java mais bon... j'ai quelques connaissances qui se sont amusées à faire des jeux en C++ pour Android avec un léger wrapper en Java, et ça a l'air de bien fonctionner.
Par contre, je le dis de suite, je n'ai jamais approché le NDK. Je sais qu'il existe, je sais pour quelle raison, mais sans plus.

[Xavi_bgsec]

Merci pour la réponse.

Bien entendu, le debug ralentit l'application. Sur n'importe quel environnement. Mais je ne me souviens pas avoir vu d'IDE aussi lent depuis un moment, à tel point que je me demande si c'est normal ou pas. Le 'confort' de programmation est très important, surtout quand c'est pour des projets perso.

Le log ne sert donc à rien en l'état ? Je pense que je vais bricoler un log perso en dehors de logcat si j'ai vraiment besoin de quelque chose d'utile. J'ai beau filtrer les niveau de log, aucun filtre ne répond à ce que je voudrais voir.Un log trop bavard, c'est jamais bon

Je vais m'intéresser à Armeabi et Genymotion.

Et evidemment, si il y a moyen de faire du C++, je vais m'y intéresser. J'ai quand même quelques réticences à traduire du code en Java mais ça ne coute rien de regarder.

Globalement, je reste quand même un peu déçu des outils qui sont offert pour la programmation su rmobile. Ca passera peut être avec le temps.

[Hizin]

Le temps de réponse de l'IDE me surprends, vraiment.
J'ai les lenteurs normales dues au debug, mais l'IDE est toujours très fluide. Il faudra que je teste sérieusement Android Studio un de ces quatre matins...
Sous IntelliJ IDEA, je n'ai jamais constaté ce problème, donc cela me surprends.

Concernant les Logs, non, ils ne servent absolument pas à rien. C'est juste qu'il faut s'habituer à avoir du bruit. Si tu n'en veux pas, tu peux, par exemple, tous les faire précéder de "monapplication". Ainsi, un filtre là-dessus ne te montrera que les tiens.
Dans Android Studio, regarde dans les options, sous "live templates", crée t'en correspondants à Log.w/d/i/v/e (et wtf si tu veux) avec un template du style Log.d($TAG$.$APPEND$, $END$); avec $TAG$ ayant le nom de ton projet en valeur par défaut et coche "skip if defined". $APPEND$ est optionnelle... au cas où tu voudrais rajouter un truc après. Enfin, tu vois l'idée.

Le mieux serait de juste insérer une constante en TAG... et ce n'est pas très compliqué suite à ça

Ainsi, en faisant logw suivi de l'appui sur tab, tu auras directement un Log.w("MonProjet.maMethode", #position curseur#);

[grunk]

Le log ne sert donc à rien en l'état ? Je pense que je vais bricoler un log perso en dehors de logcat si j'ai vraiment besoin de quelque chose d'utile..

Pour les logs tu défini un TAG qui permet d'isoler tes message et ensuite éventuellement un filtre sur la sévérité du Log.

Je ne sais pas ce qu'il en ai dans android studio mais dans Eclipse par défaut tu as deux option de visualisation des log :
Tous et ceux propre à ton application , ce qui aide pas mal.
Si tu sélectionne ton application et "error" en filtre tu ne verras que les exception lié à ton application.

Bref c'est à mon avis juste un problème de configuration / compréhension de l'outil.

En mode débuggage effectivement l'IDE est un peu plus lent qu'en mode normal mais rien de choquant chez moi , les breakpoint sont réactif.
En mode développement normal je vois pas de différence entre visual et Eclipse en terme de performance (Core i5 , 8Go de ram).

L'émulateur est merdique , c'est un fait. Comparé à l'émulateur IOS par exemple, il est ridicule. Mais il à le mérite d'être multi plateforme. Je pense honnetement qu'il faut développé avec un téléphone et ne garder les émulateur que pour des test très particulier (résolution à la con par exemple).