Suggestion d'amélioration du code

[CoreFloDev]

Bonjour,

J'ai lu votre étude ici https://hal.science/hal-04230937v1. Et après quelques recherches dans votre exemple de code, j'ai trouvé quelques erreurs assez courante chez les développeurs peu expérimenté:

• Les requêtes réseaux sont faites dans le Thread principal
• Il y a les logs d'activé pour chaque requête, j'ai déjà eu des cas ou l'impact énergétique de cette action était surprenamment élevée.
• Utilisation de gson pour le parsage des requêtes, il se trouve que c'est la librairie la moins efficace https://github.com/Kotlin/kotlinx.serialization est bien plus efficace
• Idéalement, il faudrait partager votre instance de okhttp entre votre réseau et le chargement des images https://coil-kt.github.io/coil/recipes/#using-a-custom-okhttpclient

En conclusion, je trouve que votre étude montre juste qu'il est plus difficile de produire une application native que react native ou flutter.

[zippy1978]

Bonjour @CoreFloDev,

Et merci pour tes remarques.

Comme cela est expliqué dans l'article, le but de l'expérimentation n'était de faire l'application la plus optimisée sur chaque plateforme, mais la plus standard: le but n'étant pas de mesurer la performance d'une lib par rapport à une autre, mais d'évaluer la performance d'une plateforme avec un minimum de complexité et une approche assez naive du développement (encore une fois: on veut évaluer la plateforme, pas les choix d'archi et d'optim du dev).

C'est pour cela que nous n'avons pas cherché à optimiser okhttp, ou fait du tuning de logs... Pour le parsing JSON: nous avons volontairement pris Gson car c'est encore la lib la plus populaire sur les apps Android (donc plus représentative), et il y'a plein d'autres choix comme ceux là dans le code.

Je suis par contre étonné concernant ta remarque sur le dispatch des requêtes réseau sur le main thread. Pourrais-tu me dire à quel endroit du code tu as vu cela ?

[CoreFloDev]

Bonjour @zippy1978,

Ouais pas de soucis, je comprends, je voulais juste donner un exemple plus proche de ce qu'on retrouve sur une application professionnelle sérieuse.

Je reviens sur l'histoire de log okhttp, mais c'est pas que okhttp. Laisser des logs dans une app en production ça tue les performances surtout sur les appareils d’entrée de gamme, donc ce n'est pas étonnant d'avoir une moins bonne efficacité énergétique pour le natif. Après vous pouvez garder les logs mais dans ce cas, il faudrait également les ajouter sur les autres plateformes.

Pour les requêtes sur le thread principal en fait c'est toutes les requêtes comme ici https://github.com/TurnipOffApp/turnipoff-android/blob/main/app/src/main/java/fr/insideapp/turnipoff/ui/screens/credit/PersonScreenViewModel.kt#L25. Elles sont exécutées avec le viewModelScope qui utilise le main thread il faudrait faire un withContext(Dispatchers.IO) {} comme mieux expliqué ici https://stackoverflow.com/questions/62166878/why-does-viewmodelscope-launch-run-on-the-main-thread-by-default. Je sais qu'il est sensé y avoir un crash Android quand c'est le cas, mais ça ne fonctionne pas avec les coroutines.

Voila, si vous avez d'autres questions il y a pas de soucis !

[zippy1978]

@CoreFloDev,

Ok, du coup je confirme que les requêtes ne s'exécutent pas sur le thread principal, puisque Retrofit implémente la main-safety auto (comme Room et d'autres) et donc le withContext est inutile.