Photo de Gary Woodland
Le développement d'une application mobile diffère fortement du développement d'un client lourd ou d'un site web. Des problématiques peuvent apparaître pour les jeunes développeurs mobile qui auraient gardé certaines mauvaises habitudes de leurs précédents projets.
Avec l’expérience, on finit par comprendre qu’un téléphone est toujours moins puissant qu’un ordinateur ou un serveur. Les erreurs sont bien moins pardonnées sur cette plateforme, et celles-ci peuvent être très nombreuses. Elles impactent les performances de l’application et peuvent la ralentir fortement jusqu'à provoquer un arrêt brutal.
Les erreurs courantes
Le réseau
Pour commencer, une des erreurs les plus courante est la mauvaise gestion des appels clients HTTP. En effet, bien souvent les développeurs ne feront pas attention aux nombreux appels réseaux et ne se méfieront pas de savoir s’il faut ou non libérer les ressources après les avoir utilisées. Il ne faut d’ailleurs pas oublier de faire les traitements en arrière-plan, pour ne pas bloquer l’application.
Les images
Cette erreur fait également écho à une autre avec la gestion des images, dont les ressources sont souvent utilisées mais jamais libérées pouvant créer des fuites mémoire très importantes. Il ne s’agit là que de la base, mais elle est source de beaucoup, voire de la majorité, des problèmes et faire attention permettra à l’application de beaucoup mieux s’en sortir, même si le reste n’est pas parfait. Dans le même registre au niveau des images, il faut avoir une taille adaptée pour alléger les traitements du téléphone et au passage réduire le poids de l'application. Cette remarque est surtout valable sur Android qui risque de faire des OutOfMemoryException dans cette situation.
Les évènements
Une autre erreur fréquente est liée cette fois-ci aux évènements. En effet, bien souvent après avoir appris à utiliser des "expressions lambdas", un développeur aura tendance à beaucoup en utiliser pour s’abonner à aux évènements. Dès lors qu’il utilise une lambda, il perd le réflexe de se désabonner de l’événement car c’est compliqué à faire.
Si l’impact d’une telle pratique sur un client lourd n’est pas très élevé, une application avec moins de ressources pourra finir par avoir de forts ralentissements ou pire. Cela est dû au fait que les expressions lambdas créent une classe qui capture les références des objets dont elle a besoin. Si ces objets ont une durée de vie trop grande, il y a un risque de fuite de mémoire car l'expression lambda ne sera alors pas détruite non plus. L’abonnement à une méthode lors de la création d’une page a d’ailleurs le même effet si celle-ci n’est pas désabonnée lors de la navigation et impact donc les performances de votre application à plus ou moins long terme.
Le matériel
Un autre point important concerne le matériel. Il ne dispose pas d’une puissance illimitée, si bien qu’au bout de quelques centaines de Mo utilisés, l’application pourra être détruite par le système pour libérer de la mémoire vive. Un développeur vigilant fera donc toujours en sorte que les traitements de son application ne prennent pas trop de ressources ou alors que ceux-ci soit découpés en sous-traitements plus courts.
De plus, chacun de ceux qui n’ont pas trait à l’interface utilisateur (Gui) doivent être exécutés en arrière-plan afin que l’application puisse toujours réagir aux interactions du système ou de l’utilisateur. En effet, il n’y a rien de plus frustrant que d’utiliser une application qui bloque sans raison apparente. Enfin s’il n’est pas possible de faire autrement, un indicateur de chargement peut être une option sérieusement viable… pour la moindre attente.
Conclusion
Comme souvent le plus grand problème se situe entre la chaise et le clavier alors profitez de l’été pour méditer là-dessus et, pour le bien de tous, revenez de vacances en faisant attention à vos ressources, mais aussi à celles de vos appareils. Nous avons tous besoin de vous !
