GREENSPECTOR, startup nantaise, coup de coeur Business France au Mobile World Congress 2018

Reading Time: 2 minutes

La société nantaise GREENSPECTOR est récompensée pour sa solution d’efficience des services numériques en mobilité, en étant désignée « Coup de Cœur » du jury Business France – Orange Awards lors du Mobile World Congress 2018.

Continue reading « GREENSPECTOR, startup nantaise, coup de coeur Business France au Mobile World Congress 2018 »

Intégrer les résultats Greenspector dans ses tableaux de bord via une API

Reading Time: 2 minutes

Lancer des mesures et avoir des préconisations d’amélioration via le dashboard Greenspector c’est bien, intégrer ces résultats dans son usine logicielle et ses propres dashboards, c’est mieux. C’est maintenant possible via l’API Greenspector.

La documentation de l’API est disponible à l’adresse https://[URL de votre instance Greenspector]/api/ui

Vous pouvez utiliser cette documentation pour tester l’API. Pour cela il est nécessaire de configurer votre token d’accès. Il est disponible dans vos préférences dans l’interface Greenspector.

Dans l’interface Swagger, cliquez sur Authorize.

Vous pouvez alors coller le token :

Une fois validé, vous êtes connecté et pouvez vous déconnecter à tout moment.

Pour tester l’API, vous devez récupérer l’ID du rapport à récupérer. Il est disponible dans l’URL du dashboard (Chiffres derrière /version/)

Vous pouvez alors entrer l’ID dans l’interface Swagger et exécuter la requête.

Le code de retour 200 indique que tout s’est bien passé. Le résultat du JSON est affiché.

La commande curl peut être copiée est mise en place dans votre PIC pour récupérer les résultats. Pour plus d’informations sur les données, le contrat de l’API est disponible dans la même page en cliquant sur model.

Si vous avez des questions supplémentaires, n’hésitez pas à contacter notre service support.

Android 6 améliore-t-il l’autonomie des smartphones?

Reading Time: 4 minutes

À l’heure où l’on parle beaucoup d’Android 8 Oreo, la plupart des utilisateurs de smartphones utilisent encore des versions antérieures. Parmi ceux-ci, des utilisateurs d’Android 5 qui se demandent peut-être s’il est utile de passer à Android 6. En effet, il paraît qu’Android 6 réduit la consommation de batterie. Mais qu’en est-il vraiment ? C’est ce que j’ai voulu vérifier.

N’installez une mise à jour que si vous en avez vraiment besoin

Aujourd’hui nous sommes accros à nos smartphones et je ne fais pas exception. J’utilise mon Fairphone2 depuis maintenant plus d’un an et je dois dire que j’en suis plutôt satisfait. Mis à part les quelques crashes occasionnels (mais pas plus ou moins nombreux que ceux de mon smartphone précédent), il est devenu mon fidèle compagnon du quotidien.

Quand je l’ai eu, il fonctionnait avec Android 5.1 (Lollipop). L’équipe Fairphone propose des mises à jour très régulières, et quelques mois plus tard la version 6 (Marshmallow) était disponible en téléchargement.
Mais bon… je travaille dans l’informatique depuis quelques années déjà, et je l’utilise depuis encore plus longtemps (la preuve : mon premier ordinateur disait « Ready. » sur fond bleu). Et avec le temps j’ai développé une habitude assez saine : ne jamais installer une mise à jour avant de vérifier que j’en ai vraiment besoin.

Qu’en est-il de l’affirmation sur la consommation de batterie ?

Une partie de cette habitude provient de l’approche de bon sens « if it ain’t broke, don’t fix it » (comprendre : « si ce n’est pas cassé, ne le répare pas »). Ok, cette mise à jour apporte des fonctionnalités sympas et peut être même que j’aurai besoin de certaines d’entre elles. Mais à quel prix ? Est-ce que la mise à jour augmentera l’empreinte du logiciel (mémoire ? espace disque ? besoin en CPU ? qu’en sera-t-il de la consommation de batterie ?…).

J’avais déjà jeté un œil aux nouveautés incluses dans Android 6 et m’étais dit qu’aucune n’était assez intéressante pour que je saute le pas de la mise à jour. Mais une affirmation m’a intrigué : Android 6 est supposé diminuer la consommation de batterie de l’OS et donc permettre une meilleure autonomie.
Avant de faire la mise à jour, j’ai décidé de vérifier la véracité de cette affirmation.

Regardons cela de plus près

C’est là où le fait de travailler pour une entreprise spécialisée en mesure de consommation de batterie sur appareils mobiles est plutôt pratique. Les gars du bureau d’à côté ont spontanément accepté de développer une sonde d’énergie pour le Fairphone2, après que je les ai menacés de rejoindre la chorale de l’entreprise. Ils m’ont même laissé jouer avec une version brute mais très simple d’une application de monitoring de batterie. (Avant qu’on me pose la question : non, cette appli n’est pas disponible à la vente, c’est seulement un truc de lab en interne. Pour le moment.)

Pendant quelques jours j’ai pu analyser la consommation de batterie de mon Fairphone2 lorsque je passais des appels, quand j’utilisais mes applis du quotidien, mais aussi certaines applis juste pour l’expérimentation: K9-Mail, Twitter, Météo France… plus quelques parties de Hearthstone (“ work hard, play hard ”, qu’ils disaient) et enfin j’ai écouté la radio via l’antenne et l’appli FM, et aussi via un appli radio internet choisie au hasard sur le store.

J’ai commencé par les mesures sur Android 5.1. Puis ai mis à jour l’OS, passant donc sur Android 6, et j’ai conduit une seconde série de mesures. Attention, il est important de noter que les applications n’ont pas été mises à jour, seulement l’OS.

Ces mesures m’ont conduit à des résultats intéressants. J’ai donc pu vérifier si Marshmallow abaissait réellement la consommation de batterie ou non ; j’ai aussi pu obtenir des informations sur le comportement individuel des applications.

Classement de mes applis du quotidien

La première série de mesures faites sous Android 5.1 a conduit aux résultats ci-dessous.

Toutes les valeurs sont données en µAh/s, ce sont des « microAmpère heure par seconde ». Le Fairphone2 ayant une capacité de batterie de 2 400 mAh, cela signifie qu’une appli avec un taux de décharge de 300 µah/s videra la batterie en un peu plus de deux heures environ.

• La vitesse de décharge pour mon cas d’usage varie entre 146 et 305 µah/s
• Quelques valeurs à noter :

  • Hearthstone : 305
  • Twitter : 247
  • Appel téléphonique : 191
  • Radio (FM intégrée): 160
  • Idle (ne rien faire mais sans être en veille, l’écran est allumé): environ 150

La liste complète de cas de tests est comme ci-dessous, sur le graphique :

Résultats anecdotiques : Twitter et la radio FM

En regardant ces valeurs, on trouve quelques informations inattendues :
• Twitter en mode Nuit ne consomme pas moins d’énergie que Twitter avec l’arrière-plan blanc des paramètres par défaut. OK, c’est cohérent avec la technologie de l’écran du Fairphone2plus d’informations ici.
• Ecouter la radio via la FM intégrée consomme 20% moins de batterie que l’appli Radio internet choisie au hasard. Evidemment on n’a accès qu’aux stations FM locales, mais selon votre besoin, il peut donc être plus intéressant de passer par la FM intégrée.

Est-ce qu’Android 6 améliore l’autonomie de mon téléphone ?

Eh bien, il est temps de répondre à la question. Mettons à jour le téléphone et lançons les mesures à nouveau. Voici ce que nous obtenons cette fois :

• La vitesse de décharge moyenne varie entre 102 et 313 µah/s
• Quelques valeurs à noter :

  • Hearthstone : 313
  • Twitter : 208
  • Appel téléphonique : 163
  • Radio (FM intégrée) : 143
  • Idle : entre 102 et 134 suivant la connectivité

En jetant un œil aux autres métriques, il semble que le processeur soit mieux maîtrisé. On se retrouve avec 9 % moins de CPU utilisé par le système quand le téléphone est en idle. Les applis requérant le plus de CPU présentent aussi de meilleures performances. J’obtiens un score de test à 1 058 sur 3DMark Slingshot avec Android 6 (contre 912 avec Android 5.1), mais cela se paie par une augmentation de la consommation énergétique : +10 % de taux de décharge pour 3DMark.

Conclusion

Dans la plupart des cas, Android 6 amène un gain en énergie important : entre 5% et 15% par rapport à Android 5.1. Cependant, attention avec les applications qui demandent beaucoup de CPU : les performances seront améliorées, mais au détriment de la consommation de batterie.
Pour conclure, vais-je garder la version Marshmallow sur mon mobile ? Oui.

Mobile Efficiency Index, le premier outil en ligne pour mesurer la consommation énergétique réelle de vos applications et sites web.

Reading Time: 3 minutes

Mobile Efficiency Index est le premier outil en ligne qui permet de mesurer sur mobile, la consommation en énergie et en ressources (mémoire, CPU, data…) d’un site web ou d’une application mobile.

Continue reading « Mobile Efficiency Index, le premier outil en ligne pour mesurer la consommation énergétique réelle de vos applications et sites web. »

L’obsolescence programmée par Apple expliquée (pour les nuls et plus)

Reading Time: 3 minutes

Fin de l’année 2017, Apple subit un bad buzz en étant accusé de ralentir intentionnellement les vieux Iphone. Et cela relance le débat sur l’obsolescence programmée. Un débat souvent manichéen : méchant constructeur versus gentil consommateur. Ou même l’inverse (ce qui est surprenant pour ma part) : concept de l’obsolescence qui est crée par les ONG.

Reprenons depuis le début :

Les batteries de nos téléphones sont principalement basées maintenant sur la technologie Litthium-Ion. Le comportement chimique de la batterie se dégrade en fonction du nombre de cycle de charge/décharge. Après 500 cycles, la batterie n’a plus que 80% de sa capacité batterie (l’OS du téléphone recalcule cependant un niveau pour afficher 100%). Cela veut dire que si vous aviez une batterie de 3000mAh, après 500 cycles, vous n’avez plus que 2400mAh.

Le vieillissement de la batterie s’accompagne d’une perte de puissance de la batterie surtout sur la gestion des pics de charge. Vous avez peut être vécu cela, votre téléphone ou PC est à 10% et tout d’un coup le niveau dégringole. Et comme souvent, cela arrive vers le niveau de batterie bas, le téléphone s’éteint rapidement sans vous avertir. C’est ce qu’Apple explique dans son blog.

Pour limiter cela, Apple essaye de limiter les pics de charge en limitant la fréquence du CPU. Il y a normalement moins de pics de charge. Cependant, sur le téléphone, il y a aussi d’autres gros consommateurs (GPS, Cellule radio…). On peut se poser la question si Apple ne ralentit pas d’autres choses.

Mais avant cela, il faut revenir sur cette histoire de cycle. Est-ce une fatalité ? Un cycle est directement lié au niveau de consommation du téléphone qui va lui être dépendant de plusieurs choses :

  • La consommation du matériel
  • La consommation de l’OS
  • Votre usage (nombre d’appel, vidéo…)
  • La consommation des applications

Sur les deux premiers points, les constructeurs font généralement des efforts. Sur l’usage, vous êtes le maître. Cependant il y a peu de communication. Sur la consommation des applications, il n’y a pas de fatalité (c’est d’ailleurs l’objectif de GREENSPECTOR)

Avec cela en tête est-ce qu’Apple est responsable de l’obsolescence ? Et si oui, est-ce de l’obsolescence programmée ? Tout d’abord, la cause de l’obsolescence est répartie : Est-ce qu’Apple est responsable de la surconsommation de certaines applications ? Certains constructeurs tentent de résoudre cela en pointant du doigt les applications consommatrices. Sur ce point, Apple ne fait pas vraiment de zèle. 0 pour les concepteurs d’application, 0 pour Apple.

Sur l’usage, Apple fait le strict minimum sur la communication. C’est plus hype de communiquer sur le fait de pouvoir animer un émoticon que cela. En même temps, les utilisateurs préfèrent cela. Les médias aussi : c’est plus intéressant de sortir le marronnier des files d’attente interminables à chaque sortie de nouvelles versions. 0 pour Apple, 0 pour les médias, 0 pour les utilisateurs.

0 pour tout le monde, donc plutôt obsolescence partagée ! Cependant, ce qui est très critiquable dans la prise en compte par Apple du vieillissement de la batterie (qui est bien réel), ce n’est pas le ralentissement, c’est la non communication. L’utilisateur est assez intelligent pour comprendre un message du type « votre batterie devient vieille, nous conseillons un ralentissement de votre téléphone: Oui, Non (je préfère changer de batterie) ». Mais là encore, cela ne va pas dans le sens du « hype » et d’un produit qui pourrait paraitre un peu trop technique (ce qui est la réalité). Et sur ce point, Apple en n’avertissant pas l’utilisateur sur le ralentissement, l’utilisateur ne peut pas être responsable et agir en tout état de cause. Il n’a pas tous les éléments en main pour évaluer la situation. Et probablement, c’est un manque de paramètre qui va le faire potentiellement basculer vers un renouvellement. Et dans ce cas oui, Apple fait de l’obsolescence programmée.

Pourquoi se préoccuper de la consommation de batterie d’une application ?

Reading Time: 5 minutes

L’autonomie des smartphones stagne depuis plusieurs années. Les fabricants proposent des batteries de plus grande capacité, les utilisateurs indiquent que l’autonomie est un de leurs tout premiers critères d’achat, et pourtant l’autonomie moyenne des appareils n’augmente pas. Pourquoi ? Parce que le matériel lui-même est plus puissant donc plus gourmand ; mais aussi parce que les applications consomment toujours plus de ressources.

Alors, pour améliorer la perception que les utilisateurs ont de leur appareil, les fabricants pointent du doigt les applications les plus gourmandes, afin d’inciter les développeurs à plus de vertu. Google suit le même raisonnement sur le Play Store en favorisant le référencement des applications les plus légères.

Alors oui, même une application « grand public » utilisée de temps en temps doit être optimisée pour consommer le moins de batterie possible. En évitant que votre application apparaisse comme consommatrice d’énergie, vous améliorerez son référencement, sa rétention et in fine l’expérience utilisateurs. Autant de points vitaux pour son succès.

L’autonomie, critère de choix du matériel

Tout utilisateur de smartphone a déjà été en situation critique à cause d’un niveau de batterie très faible : plus moyen d’être contacté, impossibilité de trouver une adresse avant un rendez-vous, pas de billet de train ou d’avion à montrer au contrôle… Le besoin presque vital de maintenir sa batterie chargée est devenu une réelle préoccupation pour la moitié de l’humanité.

Il n’est pas étonnant donc que l’’autonomie soit un des premiers critères de choix des acheteurs. Les constructeurs travaillent continuellement sur l’amélioration de l’efficacité des batteries et du matériel. Et la presse technologique suit attentivement ce sujet.
En attendant une hypothétique nouvelle technologie idéale, des solutions apparaissent régulièrement. L’offre de « solutions » applicatives permettant de d’optimiser sa consommation de batterie est foisonnante sur les stores, cependant sans fort impact sur l’amélioration de l’autonomie. Alors les utilisateurs se rabattent sur des palliatifs : extensions de batterie (« power bank ») USB, mini-panneaux solaires… autant d’accessoires à ajouter au budget de l’utilisateur et qui encombrent ses sacs.

Malgré cela, l’anxiété liée à la batterie vide continue d’augmenter

Que font les constructeurs ?

Cette problématique est évidemment bien connue des constructeurs. En effet, l’amélioration de l’autonomie est un challenge qui s’opère à l’échelle de chaque composant : les batteries bien sûr mais aussi la taille et la technologie de l’écran, le choix des composants électroniques, leur intégration globale, mais aussi les couches logicielles. En effet, les constructeurs intègrent des OS (comme Android), développent des drivers pour les composants électroniques mais aussi développent des applications pour les utilisateurs, en les créant ou en adaptant des applications AOSP Android.

Mais pourquoi travailler sur les applications ?

Simplement parce que la plate-forme matérielle n’est pas la seule cause de la décharge de batterie. Les couches logicielles ne sont pas innocentes dans ce problème, loin de là. Et en y réfléchissant un peu, c’est normal ! Voici par exemple une courbe simplifiée de consommation d’énergie lors du chargement d’une application:

On voit la surconsommation causée par le lancement de l’application.

Vous vous en doutez, toutes les applications ne vont pas avoir le même impact sur l’autonomie globale du téléphone. Voici par exemple une comparaison de la consommation du lancement d’applications de e-commerce, qui varie environ du simple au double :

L’usage de fonctions comme le GPS, le Bluetooth ou la vidéo (ou demain les fonctionnalités d’AR ou de VR) ont un impact qui n’est pas que l’unique raison de ces inégalités. En effet, en fonction de sa conception, de son usage, des services externes, des capteurs qu’elle va solliciter… une application va consommer plus ou moins.

Malheureusement (ou heureusement), les applications ont bien un impact fort sur l’autonomie de nos smartphones.

L’impact des applications, un critère primordial

Les constructeurs sont conscients de cet impact des applications. Ils travaillent à l’optimisation de leurs propres applications, mais ils n’ont aucune prise sur les applications qui sont installées après la sortie de l’usine… Cela commence par les opérateurs téléphoniques ou les intégrateurs, qui ajoutent leurs propres applications. Puis les utilisateurs installent… ce qu’ils veulent.

Toutes ces applications vont avoir un impact plus ou moins fort sur l’autonomie. Et au final, même si le constructeur n’est pas directement responsable, l’utilisateur associera la faible autonomie de son appareil avec la marque et le modèle du téléphone : « 71% des utilisateurs considèrent que la qualité d’une application peut influencer sur l’image de la marque » (Source : baromètre des usages mobiles ,Juin 2017, EBG)

Il est donc de l’intérêt des constructeurs d’encourager les éditeurs d’applications à maîtriser la consommation de batterie de leurs apps. De même, il est de l’intérêt de Google de promouvoir des applications vertueuses sur le Play Store, afin de donner une image positive de l’écosystème Android face à celui d’Apple… et réciproquement.

Que font les constructeurs ? Ils vous dénoncent aux utilisateurs.

Les constructeurs ont intérêt à sensibiliser les utilisateurs sur ce complexe problème de l’autonomie et surtout à reporter la faute sur les concepteurs d’applications.

Citons par exemple Huawei, qui désormais adresse des alertes explicites à ses utilisateurs en cas de surconsommation détectée :

Cette même volonté de promouvoir les applications économes se retrouve intégrée dans les écosystèmes de Google et Apple. Depuis longtemps, les plates-formes n’hésitent pas à pointer du doigt les applications consommatrices. Le système liste pour cela la part de consommation de chaque application:

La dernière version d’Android 8.1 Oreo renforce cette fonctionnalité en ajoutant une notification des applications consommatrices.

Mais cette logique ne se limite pas au téléphone de l’utilisateur, on la retrouve aussi sur les stores. Ainsi, Google prend en compte l’énergie consommée dans ses critères de référencement ASO des applications.
Vous saviez probablement déjà que l’efficience était indispensable pour un bon référencement web, Google nous confirme ici qu’elle l’est également pour les applications (ASO). C’est un critère à ne pas négliger puisque 80% des utilisateurs utilisent le store comme point d’entrée de leur recherche d’applications (Source baromètre des usages mobiles, Juin 2017,EBG).

Un exemple ? Google explique l’expérience de Busun qui est passé d’une notre de 4.1 à 4.5 en améliorant sa performance.

Que fait l’utilisateur ?

Supposons que l’utilisateur a trouvé votre application sur le store, qu’il a été convaincu de l’installer, il reste maintenant à le conserver.
Et là… Soit votre appli fais partie de la douzaine d’applications « critiques », incontournables et sans équivalent réel (Google Maps, Facebook…) : dans ce cas l’utilisateur acceptera la consommation de batterie comme un mal nécessaire, il râlera dans son coin mais conservera votre application.

Soit votre application fait partie du million d’autres applications, considérées comme non essentielles ou disposant de nombreuses alternatives (banque en ligne, voyagiste, informations…) : dans ce cas l’utilisateur aura tôt fait de désinstaller votre appli pour passer à la concurrence… Non sans avoir laissé au préalable un commentaire désagréable sur le store.

Conclusion

Les propriétaires d’applications grand public pensent parfois que l’impact de leur appli sur l’autonomie de l’appareil n’est pas un problème. Après tout, elle n’est utilisée que de temps en temps, ce n’est pas elle qui va vider la batterie, n’est-ce-pas ? Nous avons vu qu’il n’en est rien. Même une application grand public peut souffrir fortement d’un défaut de comportement en la matière. Les utilisateurs s’en rendront compte : référencement dégradé, rétention faible, avis négatifs… Le succès d’une application passe – aussi – par une bonne maîtrise de son efficience.

Android Memory: the Ultimate Metric Guide

Reading Time: 6 minutes

Nous portons de l’importance à l’efficience de vos applications, c’est pourquoi nous vous présentons cet *Ultimate Metric Guide: le glossaire pour mieux gérer la mémoire de vos applications sur appareils Android.**

Syllabus de la mémoire

Pages: Blocs utilisés pour récupérer des données du disque à la mémoire. C’est la partie principale de la gestion de mémoire virtuelle. En général, la taille de la page est de 4kb.

Mémoire privée / partagée (Private / Shared memory): La mémoire privée est composée de pages qui sont utilisées par le processus seulement. La mémoire partagée, quant à elle, est faite de pages utilisées par d’autres processus. Il est possible qu’une page passe de Privée à Partagée si un processus référence la page en question.

Clean / Dirty memory: Les pages “dirty” sont celles sorties du disque. Par conséquence, les pages “clean” sont celles qui ont été lues.

VSS (Virtual Set Size): C’est le nombre total de pages accessibles par un processus. Cela inclut à la fois les pages privées et partagées, mais aussi d’autres espaces de mémoire comme malloc. Cela est peu, voir pas, utilisé.

RSS (Resident Set Size): Total des bibliothèques partagées. Pas d’information sur le nombre de processus utilisant la page. Par conséquent, cela n’est pas une information très utile (La PSS est plus importants).

Pss (proportional set size): Le nombre de pages un processus a en mémoire, dans lequel les pages privées et pages partagées sont additionnées et divisées par le nombre de processus les partageant. Si un processus a 2 pages privées et 6 autres pages privées utilisées par 2 autres processus, le « pss » en nombre de pages est de 2+6/3=4.

Uss (Unique set size): Le nombre de pages uniques associées à un processus, et donc de pages privées ! Généralement VSS > RSS > PSS > USS

Java / native memory: La mémoire Java est la mémoire gérée par le système Android (Dalvik ou ART). Principalement pour vos objets Kotlin ou Java ! La mémoire native est quant à elle plutôt pour les objets générés. Même sans application C/C++, le framework Android utilise parfois la méthode native.

ZRam: Android n’a pas de partition swap, Zram est la RAM mais une compression est utilisée pour stocker les données inutiles. Sur meminfo, « swapped dirty » paraît être équivalent.

Stack / heap: Heap est l’espace mémoire objet, et les variables locales sont allouées à Stack. Par conséquent, les objets sont créés sur Heap. Chaque thread a un espace Stack.
Allocated Heap Size : Android est un système multitâche ; afin de garder de l’espace mémoire pour d’autres processus, il affecte une taille de la mémoire dans la mémoire globale. Cette taille varie selon le smartphone. Si votre application requiert davantage de mémoire, vous obtiendrez la célèbre erreur « mémoire insuffisante » (« out of memory »).

MMAP: Dénommé “map file to memory” par le système. Sur Android, il y des mmap pour chaque type de dossier (Dex, APK, ART. Peut être nommé “Code” dans certains outils.

Graphics Buffer: Mémoire utilisée pour stocker les objets graphiques.

User/Kernal memory: Le processus tourne dans l’espace utilisateur. L’espace Kernel est dédié aux calls du système Android.

Organisation mémoire

La mémoire Android est organisée par un système d’adresses virtuelles. Le mapping est le suivant: (adresses ascendantes)

  • User Space
  • Data space (texte, données, instructions…)
  • Heap
  • libs (bibliothèques partagées, .jar…)
  • Stack
  • Kernel Space

La mémoire utilisée par votre application se trouve dans le user space (principalement en heap et stack).

Outils

Paramètre système Android: Les données dans l’interface utilisateur Android fournissent deux informations : la consommation maximale et la moyenne d’information (3 heures). La moyenne est relativement compliquée à analyser et la consommation maximale est une première indication intéressante pour l’utilisateur.

Top: Parce que l’on utilise déjà les RSS et VSS, les informations Top ne sont pas particulièrement significatives.

Memory Profiler in Android Studio (>3.0): Uniquement la mémoire privée est mesurée et se divise en différents domaines:

  • Native / Java
  • Code
  • Graphics Buffer

Android Monitor in Android Studio (<3.0): Uniquement la mémoire privée est mesurée . Moins de domaines sont mesurés que dans Android Memory > 3.

Dumpsys: Dumpsys mesure la mémoire PSS (à la fois privée et partagée) mais aussi le SWAP dirty.

Android MemInfo API: La mémoire PSS ets utilisée (privée et partagée)

/proc/meminfo: C’est la mémoire globale de la plateforme, pas d’information sur votre processus.

Quelles métriques doit-on utiliser ?

Mémoire privée/USS: Cette mémoire est dédiée à votre processus. Il est donc intéressant d’analyser précisément l’objet dédié à votre application. Par exemple, si vous tuez votre processus, la mémoire dédiée doit être de zéro, cela vous permet donc de détecter une potentielle fuite de mémoire. Néanmoins, votre application a utilisé des bibliothèques et des codes partagés, par conséquent vous ne verrez pas de mémoire qui pourra être partagée avec d’autre processus.

PSS/Mémoire privée et partagée: C’est plus compliqué d’analyser cette mémoire car elle intègre la mémoire de différents processus (avec un facteur de correction). Cependant, pendant vos mesures, si vous fermez les autres apps en cours d’exécution en arrière-plan, cet impact sera minimisé.

VSS/RSS: Trop de pages de mémoire sont prises en compte dans cette métrique, elle n’est donc pas intéressante à analyser.

Comment tester la mémoire ?

Statique: Vous avez seulement à exécuter votre application et lancer les outils de mémoire. Cela permet d’avoir une vue globale de la consommation en mémoire de votre application. Vous pouvez utiliser cette technique pour réduire la mémoire totale utilisée : code, java heap,…

En longueur: Vous laissez les outils s’exécuter et observez les évolutions en matière de mémoire. Par ce moyen, vous pouvez identifier une fuite de mémoire potentielle ; la mémoire augmente régulièrement : s’il y a un « garbage collector » réduisant fréquemment la mémoire à sa valeur initiale, il n’y a pas de problème, si non, il y a une fuite.

Passer d’une activité à une autre: Vous pouvez aller entre les pages et voir si la mémoire est libérée à chaque fois. Cela est possible avec des tests Monkey.

Ecran rotateur: Si vous tourner votre écran, l’activité de votre application créera potentiellement une fuite de mémoire.

Mettre l’application en arrière-plan: Si votre application est en arrière-plan, une partie de la mémoire sera libérée (par exemple la graphique). Vous pouvez aussi libérer davantage de mémoire (objet, bibliothèque…).

Comment réduire la mémoire?

Optimiser l’image: Les images sont une cause de consommation de mémoire assez importante. Vous pouvez utiliser la Bibliothèque Glide pour vous aider à les gérer ou encore à en optimiser la gestion avec Android API.

Libérer de la mémoire quand Android requiert advantage de mémoire : Comme le système est pauvre en mémoire, une notification est envoyée à toutes les applications pour libérer de la mémoire. Dans ce cas-là, passez outre onTrimMemory() pour libérer de la mémoire.

Utiliser une structure spécifique: Les collections génériques comme hashmap ne sont pas dédiées à Android, certaines structures sont plus adaptées, comme SparseArray.

Réduire la taille de votre APK: La taille de votre APK (particulièrement les ressources et bibliothèques) peuvent augmenter la consommation de mémoire.

Réduire le nombre de threads: Android fournit des services pour faire des petites tâches et éviter la surconsommation de mémoire, comme AsyncTask.

Préférer les classes internes statiques : Les classes internes non-statiques créent des références étrangères à cette activité. C’est une cause de fuite de mémoire. Vous devriez choisir celles statiques.

FAQ

Comment connaître la taille limite du heap?: La taille limite du heap d’Android dépend de l’appareil (de 15Mb à quelques centaines). Afin de connaître la taille limite, vous pouvez utiliser l’API de getMemoryClass() du service ActivityManager.

Les informations de mémoire ne sont pas identiques selon les différents outils. Pourquoi ?: Les outils peuvent utiliser des APIs de différents systèmes ou simplement ne pas prendre en compte les mêmes données (par exemple ne pas prendre le MMAP). Dans la plupart des cas : Android monitor < Android Profiler in Android Studio < dumpsys < System Meminfo api < top info and VSS > RSS > PSS > USS

Android libérera-t-il la mémoire de processus pendant le mode arrière-plan ?: Quand l’utilisateur change l’app, le système « cache » l’app dans le cache utilisé le moins récemment (LRU – least recently used cache). Le système fonctionnant avec peu de mémoire, il va tuez (kill) les applications consommatrices. Si votre app consomme peu de mémoire, elle a ses chances de ne pas être tuée (ou du moins, seulement après les apps consommant davantage).

Est-il possible d’augmenter la taille limite du heap ?: Oui, avec l’option android:largeHeap=true dans le manifeste. Cela n’est cependant pas recommandé.

Qu’est-ce que “OutOfMemoryError” ?: Votre application a besoin de plus d’espace et vous avez atteint la taille limite du heap.

Sources

https://en.wikipedia.org/wiki/Paging

https://stackoverflow.com/questions/2298208/how-do-i-discover-memory-usage-of-my-application-in-android/2299813#2299813

https://developer.android.com/topic/performance/memory-overview.html

https://forum.xda-developers.com/showthread.php?p=34877656#post34877656

http://javarevisited.blogspot.fr/2013/01/difference-between-stack-and-heap-java.html

https://developer.android.com/studio/profile/memory-profiler.html

https://developer.android.com/topic/performance/memory.html