Android ou Java consomment-ils plus d'énergie puisqu'ils fonctionnent sur une machine virtuelle ?

Votre question est basée sur beaucoup de des hypothèses erronées. Permettez-moi d'essayer de les clarifier :

• Vous avez dit "JVM (Dalvik VM)". C'est comme dire "Avion (Bicyclette)". Ces deux choses n'ont absolument rien à voir l'une avec l'autre.

• Vous avez dit "...qui est en fait un processeur virtuel". C'est tout simplement faux. Il est no que, chaque fois que les mots "machine virtuelle" ou l'acronyme "VM" sont utilisés dans un contexte technique, cela équivaut essentiellement à VMware Workstation . En effet, des produits comme VMware font en effet émulent un ordinateur entier, et pas seulement le CPU, et exécutent un système d'exploitation au-dessus d'un autre système d'exploitation. Dalvik VM fait no travailler comme ça. Pas du tout.

• Java n'est qu'un langage de programmation. C'est une syntaxe. Il se trouve que les programmes Android/Dalvik utilisent la même syntaxe ou une syntaxe très similaire à celle d'un langage de programmation de bureau/serveur totalement indépendant appelé Java, qui fonctionne sur une machine virtuelle Java. En théorie, vous pouvez écrire du code Java qui est presque aussi rapide que du code C, puisqu'il s'agit de deux langages de programmation de haut niveau. Le problème réside dans les détails de la mise en œuvre des appels de bibliothèque et dans la manière dont le moteur d'exécution est conçu, ce qui a très peu à voir avec la syntaxe du langage.

• C'est une généralisation excessive que de dire que Dalvik VM, la JVM de Sun Java Hotspot ou la syntaxe du langage de programmation Java sont responsables d'une consommation d'énergie élevée. La raison en est que vous devez comparer ce dont vous parlez aux performances de autre chose . Dans le cas le plus général, lorsque vous ne faites que comparer les capacités "optimales" des deux plates-formes, il est en principe possible de créer des applications Dalvik qui sont aussi rapides, voire plus rapides, que les programmes sur n'importe quelle autre plate-forme. En dehors de la gestion automatique de la mémoire et de la compilation JIT - des fonctionnalités qui sont standard dans presque tous les environnements de programmation de nos jours, y compris sur iOS et en JavaScript / HTML5 - il y a très peu de choses qui séparent Dalvik de Objective-C, .NET, Ruby, la JVM Oracle Hotspot, Python, et ainsi de suite.

• La perception selon laquelle "Java est lent" est due à un problème avec les anciennes versions de Java, en ce sens qu'elles ne disposaient pas d'un compilateur juste-à-temps (JIT) ou que le JIT dont elles disposaient avait des fonctionnalités très limitées. La JVM a eu un Compilateur juste-à-temps depuis très longtemps. Un compilateur JIT est une partie du moteur d'exécution (par exemple, la JVM) qui prend le bytecode indépendant du processeur -- par exemple le bytecode Java -- et le compile en instructions natives pour le CPU. Ce processus est effectué au lancement du programme Java, et les compilateurs JIT avancés peuvent optimiser des fonctions ou des instructions individuelles au moment de l'exécution pour améliorer leurs performances en fonction des résultats observés. Par exemple, si une méthode renvoie vrai à chaque fois qu'elle est appelée, mais qu'il n'est pas évident, d'après le bytecode d'origine, qu'elle le fasse, le compilateur JIT peut reconnaître qu'elle renvoie juste vrai, et remplacer l'appel de fonction par une valeur codée en dur de "vrai". Ceci n'est qu'un exemple.

• Les techniques de compilation JIT et d'analyse dynamique du code d'exécution ont fait d'énormes progrès ces dernières années. De nombreux membres de la communauté informatique pensent que, dans une ou deux décennies, l'analyse sophistiquée disponible dans les langages interprétés/compilés dynamiquement, tels que Java, C# et Ruby, sera si avancée que, dans la plupart des cas, ces langages exécuteront plus rapide à l'exécution que les langages à compilation statique comme C et C++. Cela s'explique par le fait que les compilateurs statiques se limitent généralement à compiler le code au moment de la construction, et que le code n'est pas modifié au moment de l'exécution. Mais dans un environnement d'exécution où le code du programme peut se réécrire lui-même pendant l'exécution pour qu'il soit plus efficace, il est possible de réaliser un énorme gain en analysant les performances du code et en effectuant des ajustements pour réduire la complexité du code ou le nombre d'instructions qui sont exécutées sur le CPU. Pour le code fréquemment appelé, l'investissement en temps nécessaire pour effectuer l'analyse est largement compensé par les avantages en termes de performance de l'appel répété de code plus rapide.

• Il convient de noter que la VM Dalvik d'Android contient également un JIT et qu'elle n'utilise pas le même format de bytecode que la JVM de Sun/Oracle. Le JIT de Dalvik est optimisé pour les environnements à faible mémoire, et il est très avancé en termes d'amélioration des performances d'exécution. C'est donc un peu une coïncidence que la JVM et Dalvik implémentent le JIT de Sun/Ocle. similaire pour leur environnement d'exécution Java respectif, mais sous le capot, ils sont très différents.

• N'oubliez pas que Dalvik lui-même, le noyau Linux, les processus système de bas niveau et le cœur des navigateurs Web d'Android (Firefox et Chrome) sont écrits en C/C++ natif et ne présentent donc aucun des problèmes de surcharge que connaîtrait un programme Dalvik. C'est la même chose pour iOS. Si vous parlez de Android pur et non pas le bloat des opérateurs et des tiers qui se trouve au-dessus, une très grande partie de ce qui compose le noyau d'Android est no écrit en utilisant Dalvik.

• Les développeurs d'applications sur Android peuvent également, à leur gré, écrire du code natif, en contournant Dalvik. Si un développeur d'applications estime que Dalvik constitue un goulot d'étranglement pour les performances de son code ou qu'il entraîne une consommation excessive de la batterie, il peut simplement écrire du code C/C++ ou même du code assembleur s'il le souhaite, sans avoir à obtenir l'autorisation de Google, et distribuer son application de cette manière.

Voici quelques réel raisons pour lesquelles un appareil Android fonctionnant sur batterie, ou tout peut avoir des problèmes d'autonomie de la batterie :

• Les applications qui maintiennent le processeur, l'écran ou la connexion de données en veille. En particulier, les puces 4G telles que LTE consomment beaucoup d'énergie lorsqu'elles sont allumées, donc si vous avez des programmes d'arrière-plan qui réveillent continuellement la puce LTE pour transférer quelques kilo-octets de données, cela va vider votre batterie très rapidement. L'écran des smartphones et des tablettes modernes est également très énergivore, à moins que vous ne réduisiez la luminosité au minimum.

• Les "bloatware" qui doivent être présents sur l'appareil et qui ne peuvent pas être désinstallés. Certains opérateurs peu scrupuleux exigent que vous exécutiez un bloatware qui consomme des cycles de l'unité centrale et maintient la connexion de données éveillée. Cela peut être dû soit à l'incompétence des développeurs du bloatware, soit à un objectif intentionnel de surveiller vos activités sur votre smartphone et de les envoyer à un serveur distant pour l'exploitation des données, ce qui est très gourmand en énergie pour votre batterie.

Enfin, je ne suis pas d'accord avec votre évaluation selon laquelle Android présente des problèmes d'autonomie de batterie plus graves que sur les autres plateformes mobiles. Certains téléphones et appareils peuvent en effet avoir des problèmes d'autonomie, soit en raison de la capacité de la batterie par rapport à la consommation d'énergie du matériel, soit en raison de paramètres d'alimentation mal optimisés (choisis par l'utilisateur, l'opérateur ou le fabricant), soit en raison d'applications bloatware qui maintiennent les puces du téléphone éveillées en permanence. Mais pour chaque exemple d'appareil ayant des problèmes de batterie, je peux vous donner un contre-exemple d'appareil ayant une excellente autonomie. Il n'y a pas de moyen simple de généraliser que "c'est Dalvik" ou "c'est Linux" ou "c'est Java". L'optimisation de la consommation d'énergie est un méli-mélo matériel/logiciel complexe de préoccupations concurrentes, notamment les performances, la réactivité et les attentes de l'utilisateur en matière d'autonomie de la batterie, avec des avantages et des inconvénients pour chaque choix. Pour bien comprendre le profil énergétique d'un appareil, il faut examiner de près la batterie elle-même, tout le matériel et tous les logiciels qui fonctionnent sur l'appareil.