Clermont'ech API Hour 7: Java World, Android World, Et Les Performances Dans Tout Ça ?

Android, la plateforme mobile leader du marché, utilise comme langage de programmation le Java. Cela le rend compatible Android avec tout un ensemble de bibliothèques et de concepts Java. Mais une plateforme mobile n’a pas les mêmes performances qu’un serveur d’application. Android fournit donc tout un framework spécifique optimisé. Quelles sont les améliorations à attendre et est-ce que cela vaut le coup d’apprendre un nouveau framework ? Cette présentation montrera quelques optimisations à utiliser et passera en revue les différences importantes de performances entre un ORM et les composants BDD d’Android.

Lien vers la vidéo : https://www.youtube.com/watch?v=mbjP_iLFZ8M

Transcript

1. Java World / Android World Et les performances dans tout ça ? Clermont'ech Olivier Goutet 26 février 2014 1 / 20
2. Introduction • Android est la plate-forme no 1 ◦ Devant iOS ◦ Devant Blackberry ◦ Devant Windows Phone • Utilisation de Java ◦ Beaucoup de développeurs déjà formés ◦ Nombreuses bibliothèques ◦ Forte communauté ◦ Pas (ou peu) de gestion mémoire Mais attention : Android != Java 2 / 20
3. Introduction • Sur une application mobile, le confort d'utilisation est la priorité no 1 ◦ Réactivité ◦ Fluidité ◦ Performance ◦ Économisation de batterie 3 / 20
4. Introduction • Sur une application mobile, le confort d'utilisation est la priorité no 1 ◦ Réactivité ◦ Fluidité ◦ Performance ◦ Économisation de batterie  Maximiser le taux d'adoption de l'application 3 / 20
5. Plan Comparatif de performances Performances avec Android Persistance avec un ORM 4 / 20
6. Parc de terminaux hétérogènes Comparaison entre un desktop et Android Chargement de 36568 communes 1, traitement, et GC 1. parsing d'un chier CSV avec 29 champs 5 / 20
7. Points critiques • Chargement disque ou réseau • Allocation de mémoire • Taille et volume des objets en mémoire • Libération mémoire • Achage 6 / 20
8. Plan Comparatif de performances Performances avec Android Persistance avec un ORM 7 / 20
9. Objectif : performance ! (1/2) • Attention aux bibliothèques ◦ Bibliothèques externes non conçues pour le mobile • Utilisation inadéquate des ressources (I/O, mémoire) • Intégrations de multiples JARs dans l'application ◦ Injection de dépendances • Temps de lancement de l'application • Utilisation mémoire  Minimiser le nombre de bibliothèques incluses dans le projet 8 / 20
10. Objectif : performance ! (2/2) • Attention au langage Java ◦ Derrière les enum • 2x plus de mémoire que des constantes 2 ◦ Une classe • 500 octets de code • Idem pour les anonymous inner class • 1 instance : 1216 octets • Privilégier les variables final et attributs public • Éviter les abstractions 2. http://developer.android.com/training/articles/memory.html 9 / 20
11. HashMap vs. SparseArray (1/2) Justication du besoin HashMap <Integer ,String > map = new HashMap <Integer ,String >(); map.put(12,"text data"); • Un Integer inutile a été créé. . . • Utilisation d'une classe dédiée pour éviter l'auto-boxing et l'unboxing SparseArray <String > sa = new SparseArray <String >(); // equivalent HashMap <int , String > sa.put(12, "text data"); • SparseIntArray, SparseBooleanArray, SparseLongArray 10 / 20
12. HashMap vs. SparseArray (2/2) Comparatif d'utilisation mémoire Moins d'allocations / désalocations : plus de performance ! 11 / 20
13. Plan Comparatif de performances Performances avec Android Persistance avec un ORM 12 / 20
14. ORMLite • ORM léger, modié pour Android • Mapping entre les objets Java et la base de donnée relationnelle • Méthodes utilitaires simpliant le CRUD 13 / 20
15. ORMLite • ORM léger, modié pour Android • Mapping entre les objets Java et la base de donnée relationnelle • Méthodes utilitaires simpliant le CRUD ! Works automagically 13 / 20
16. Performances insertion 5000 éléments 3 L'ORM fournit des méthodes performantes, mais avec un peu d'huile de coude : 31% de gain 3. Plateforme de test : Nexus 4 Android 4.3 14 / 20
17. Performances lecture 5000 éléments 4 4. Plateforme de test : Nexus 4 Android 4.3 15 / 20
19. Bilan insertion / lecture • ORMLite 2470 + 290 = 2760ms • Android native 1885 + 116 = 2001ms 17 / 20
20. Bilan insertion / lecture 40% En utilisant les API Android plutôt que ORMLite 37,9% pour être précis 18 / 20
21. Informations complémentaires Intégration avec Android • Composants fournis par le SDK : ◦ Adapter ◦ ContentProvider ◦ Loader  ORM inadaptés pour exploiter ces mécanismes ◦ Améliorations en cours sur ces points 19 / 20
22. Conclusion • Performances sous Android ◦ Nécéssité avec le parc hétérogène de terminaux • Attention au code ◦ Utiliser Java intelligemment ◦ Maîtriser et vérier les bibliothèques intégrées ◦ Minimiser les allocations / désalocations de mémoire ◦ Utiliser les API Android • Pour y arriver le développeur doit s'adapter au SDK + de temps de développement + de code + de temps de mise au point (quoique...) • Bénéces ◦ Avoir une application utilisée ◦ Retour sur investissement 20 / 20