Petit barcamp deviendra grand !

En cette soirée du jeudi 24 mars de l’an 2011, le barcamp Android organisé par Excilys et pour Excilys s’est tenu dans la taverne du trappiste…

Le programme de la soirée

Alors, qu’est-ce qu’on fait pendant un barcamp ? Si vous ne connaissez pas, déjà, il faut savoir que le barcamp est aussi appelé une non-conférence. Pourquoi ? Et bien simplement parce que le but d’un barcamp n’est pas de faire circuler les connaissances d’une personne vers un groupe d’autres personnes, mais de les faire tourner entre tous les membres présents au barcamp. Ainsi, on fait un tour de table (ou de salle quand il y a beaucoup de monde) et on demande les sujets dont veulent parler les personnes présentes, en rapport avec le thème de la rencontre bien sûr. Une fois les sujets proposés, on décide ceux qui seront abordés pendant la soirée et on définit le temps que l’on passera sur ces sujets. La soirée se déroule ainsi au fil de petites sessions de discussion, de boisson et de partage avec, dans la mesure du possible, un compte-rendu de ce qui a été dit, soulevé, partagé, montré, etc. Hier soir, nous avions donc comme thème Android et nous avons choisi de parler des sujets suivants :

  • Comment faire de jolies applications ?
  • Comment faire des tests unitaires ?
  • Comment éviter les erreurs de type Out of Memory ?
  • Comment améliorer les performances de son application ?
  • Quel avenir pour la plateforme ?
  • Existe-t-il des frameworks intéressants pour faire des jeux vidéos ?

Compte rendu de la soirée

Éviter les erreur Out of Memory

Il n’est pas rare, lorsqu’on développe une application Android, de se retrouver face à cette vilaine erreur qui nous dit OutOfMemoryError.

Trouver le coupable…

Après de nombreuses discussions et pintes de leffe, nous avons retenu une solution permettant de connaitre l’état de l’application qui s’exécute, il s’agit de MAT (Memory Analyzer Tool). En effet, il suffit d’utiliser DDMS (fourni par le SDK Android) afin de faire un heap dump puis de l’analyser avec MAT pour découvrir où se cache la classe qui a mangé toutes les frites la mémoire. Un post du blog officiel des développeurs d’Android est paru hier à ce propos d’ailleurs, nous vous invitons à le consulter, il explique en détail la marche à suivre.

Éviter cette erreur…

Hormis les solutions de debugging, une astuce a été donnée pour éviter de consommer trop de mémoire lorsque, par exemple, on voudrait faire lire un PDF par Android. Il s’agit d’utiliser une fenêtre sur le fichier, c’est a dire ne charger que les 2 ou 3 pages autour de la page vue par l’utilisateur, et lorsque celui-ci change de page, de décharger celles qui sont alors hors de cette fenêtre. Les weak references ont aussi été abordées. Pour faire simple, ces références sont dites faibles car, si l’application approche de son quota de mémoire, alors le Garbage collector peut décider de supprimer les objets référencés par ces weak references.

Performance des applications Android

La suite logique au sujet précédent était bien sûr la question des performances des applications Android. Comment la définir ? Et aussi, comment l’améliorer ? Au delà de la performance technique qui vise a réduire la quantité de mémoire consommée et le temps d’exécution de la moindre méthode, une description de la performance d’une application a été proposée, elle s’oriente utilisateur et repose sur deux questions :

Est-ce que l’utilisateur trouve l’application lente ? Est-ce que la durée de vie de la batterie est trop fortement impactée par l’application ?

Même si cette définition est certainement ce qu’il faut ne pas oublier lorsque l’on crée une application, il reste important d’optimiser au mieux son code. Lorsqu’une application utilise trop d’objets, on remarque souvent une baisse de performance, en effet, d’une part ces objets consomment beaucoup de mémoire, de plus, le Garbage Collector devient alors rapidement lent (on remarquera l’oxymore). Pour pallier ces soucis de performance, on peut utiliser le design pattern Object Pooling. Ce design pattern consiste à créer un pool d’objets (ie: un nombre prédéfini d’objets d’un certain type) et ensuite d’utiliser, et ré-utiliser ces objets lorsque cela est nécessaire. Cela évite l’intervention (souvent coûteuse) du Garbage Collector et la création d’un nombre trop important d’objets de ce type.

Tests sous Android

Les tests sous Android sont gérés nativement par le SDK Android qui fourni une application test en parallèle de l’application que vous développez. Cette solution fonctionne, mais peut se révéler très lente et ne permet en aucun cas de faire du Test Driven Developement.

Une solution a ce problème a été présentée hier soir, il s’agit de Robolectric, un framework de tests pour Android qui permet de lancer les tests directement dans Eclipse, sans avoir à lancer l’émulateur.

Futur de la plateforme Android

Android est un OS mobile qui se veut plus ouvert que ses concurrents (Windows Phone 7 et iOS4.X), il propose une API Java, ce qui l’a rendu très vite très populaire au sein de la communauté de développeurs. Aujourd’hui, Android est installé sur plus d’un tiers des smartphones aux USA, il a su prendre sa place et il semble la garder pour l’instant. Mais qu’en sera-t-il plus tard ?

A l’heure actuelle, la plateforme Android souffre de son ouverture et de ses mises à jour qui ne sont pas toujours backward compatible. Il n’est pas rare qu’une application se comporte différemment entre deux téléphones (couleurs, erreurs, etc.) et l’arrivée de HoneyComb, bien que portant Android vers les tablettes, n’arrange pas forcément le problème.

De plus, contrairement à son concurrent iOS, Android ne peut pas être optimisé pour chaque type de terminal mobile existant, ce qui nuit à ses performances. Mais bon, après, comme dit plus haut, qu’est-ce que la performance, et qu’attendent réellement les utilisateurs de leur téléphone ?

Malgré ces problèmes (qui finiront, on l’espère, par s’arranger), Android reste une plateforme intéressante et certains d’entre nous voient Android s’inviter dans divers équipements : télévisions, voitures, maisons automatisées, montres, etc.

En vrac…

Comme un barcamp n’est pas super strict et que parfois les discussions dévient du sujet principal (avant d’être redirigées ;)), voici une liste de choses diverses qui pourraient vous intéresser :

  • Visual VM. Cette application permet de faire du profiling d’applications Java, et d’avoir des informations sur la mémoire utilisée par exemple. (cité lors de la discussion sur les OutOfMemoryError).
  • Google n’utilise pas Maven par défaut dans ses SDK et ses projets, il préfère Ant. Bon à savoir, il existe un plugin maven-android-plugin par exemple pour gérer des projets Android avec Maven.
  • Le Paris Android User Group se réunira la prochaine fois le 14 avril 2011, notez-le dans vos calendriers si Android vous intéresse ;)
  • Enfin, un petit rappel sur la gestion de la mémoire en Java. Il existe trois deux types de mémoires : le permgen qui contient les définitions des classes Java, le heap qui contient les instances des objets (ainsi que le permgen, zone de la mémoire qui contient la définition des classes) et la stack qui contient les appels de méthodes, les variables locales, …

En conclusion

La bière a coulé, mais pas à flots comme prévu, nous ferons en sorte d’y remédier bien sûr lors du prochain barcamp ! La soirée était intéressante, j’ai, pour ma part, appris beaucoup de choses et j’invite les néophytes comme les experts à venir aux prochaines rencontres, car c’est un moment idéal pour échanger des connaissances sans prise de tête et autour d’une bonne bière (ou autre boisson si vous préférez :p)

Merci à tous ceux qui sont venus, en espérant refaire beaucoup de soirées comme ça ;)

VN:R_U [1.9.22_1171]
Rating: 0 (from 0 votes)
Share

À propos de Romain Sertelon

Vous pouvez me suivre sur Twitter et sur Google+ et voir mes débuts sur Github
Ce contenu a été publié dans Non classé, avec comme mot(s)-clef(s) , , . Vous pouvez le mettre en favoris avec ce permalien.

2 réponses à Petit barcamp deviendra grand !

  1. Joan Zapata dit :

    Merci de t’être dévoué pour résumer la soirée ! J’ai également appris beaucoup de choses et je remercie tous ceux qui étaient là !

    Et juste un détail, PY s’est emporté il n’y a que deux types de mémoire, le PermGen étant une partie du Heap. Il s’est auto-rectifié ce matin ! :p

    VN:R_U [1.9.22_1171]
    Rating: 0 (from 0 votes)
  2. Excellent compte rendu ! Et oui, après quelques bières j’ai parfois dis quelques bêtises ;-) .

    Soyez sûr qu’on retentera l’expérience, et peut-être même que la prochaine fois c’est vous qui l’organiserez !

    Des sujets au hasard : GWT, Java, Spring, Javascript côté serveur, Groovy, Grails, Play, etc ;-)

    VN:R_U [1.9.22_1171]
    Rating: 0 (from 0 votes)

Laisser un commentaire