Android ou Java utilise-t-il plus d'énergie car il s'exécute sur une machine virtuelle?

Étant donné que les applications Android s'exécutent sur une machine virtuelle Java (machine virtuelle Dalvik) qui est essentiellement un processeur virtuel, et que chaque instruction virtuelle doit être mappée à l'instruction native du chipset sous-jacent, ce mappage entraîne-t-il une consommation d'énergie accrue en raison de la surcharge de ce mappage?

Cette question peut être étendue à Java et être également formulée comme "les applications Java utilisent-elles plus de puissance?". Est-ce la raison pour laquelle les téléphones Android ont une durée de vie de la batterie aussi épouvantable que d'autres plateformes / téléphones?

Edit : Sur la base des réponses, j'ai clarifié quelques points parce que j'avais parlé à tort de JVM et Dalvik de manière interchangeable. Dans cette partie, je parle de Java uniquement pour demander s'il utilise plus d'énergie et si oui, cela s'applique-t-il conceptuellement à Android et entraîne-t-il une diminution de la durée de vie de la batterie.

Contexte : cité sur Wikipedia:

1. Le bytecode Java est analogue au langage d'assemblage pour le code C.
2. Du point de vue d'un compilateur, la machine virtuelle Java n'est qu'un autre processeur avec un jeu d'instructions, Java bytecode, pour lequel du code peut être généré.
3. JVM a une architecture de pile. Dalvik est une machine virtuelle de processus qui n'est pas le même type de virtualisation que JVM et possède une architecture de registre.

Étant donné que le langage de programmation Java est compilé en bytecode (de type assembleur) et qu'il s'exécute sur un processeur virtuel, il offre une véritable portabilité du code logiciel. De plus, comme il existe une JVM pour Linux et que Linux a été porté sur du matériel ouvert, la combinaison peut fournir une véritable portabilité des applications sur toute la pile.

Puissance : La question se résume essentiellement à ceci - pour le même ensemble de fonctionnalités de votre code logiciel ou de votre application, quel pourcentage de vos cycles d'horloge CPU est attribué à l'environnement d'exécution. C'est le cas avec l'environnement de compilation Just-In-Time des machines virtuelles Java modernes où si le bytecode est compilé en fonction de l'instruction native du chipset sous-jacent, l'exécution ne devrait être active que pendant la compilation jit. Alors, combien de cycles d'horloge CPU supplémentaires sont utilisés pour avoir l'environnement d'exécution qui devrait entraîner une surcharge de consommation d'énergie. Je ne m'intéresse qu'à l'aspect consommation d'énergie, et non aux performances relatives par rapport aux langages typés et construits statiquement et je comprends les avantages de Java. Sous-questions pouvant être liées:

• Le temps d'exécution Java utilise-t-il la libc pour ses fonctionnalités?
• Certains de ces points liés à la consommation d'énergie se traduisent-ils par la machine virtuelle Dalvik et Android?
• Au lieu de généraliser la faible consommation de batterie d'Android sans parler de l'écran et des chipsets sans fil - parlons de la façon dont l'iPhone 5 possède une batterie de 1440 mAH, ce qui est minuscule par rapport aux téléphones Nexus modernes. Cet ensemble de pensées (Java, processeur virtuel, mappage d'instructions, Android) est né parce qu'un ami fidèle à l'iPhone a affirmé que cela pourrait être la raison probable pour que son iPhone ait une meilleure autonomie de batterie que mon (génial) Nexus.

Dans tous les cas, merci pour les réponses ci-dessous.

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

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

• Vous avez dit "... qui est essentiellement un processeur virtuel". Tout simplement faux. Il n'est pas vrai que, chaque fois que les mots "Virtual Machine" ou acronyme "VM" soient utilisés dans un contexte technique, il soit essentiellement équivalent à VMware Workstation . En effet, des produits comme VMware émulent en fait un ordinateur entier, pas seulement le processeur, et exécutent un système d'exploitation sur un autre système d'exploitation. Dalvik VM ne fonctionne pas comme ça. Pas même près.

• Java n'est qu'un langage de programmation. C'est la syntaxe. Les programmes Android / Dalvik utilisent la même syntaxe ou une syntaxe très similaire à un langage de programmation de bureau / serveur totalement indépendant appelé Java, qui s'exécute sur une machine virtuelle Java. En théorie, vous pourriez écrire du code Java qui est presque à la même vitesse que le code C, car ce sont deux langages de programmation de haut niveau. Le diable réside dans les détails de l'implémentation des appels de bibliothèque et de la façon dont le runtime est conçu, ce qui a très peu à voir avec la syntaxe du langage.

• C'est une généralisation excessive de dire que Dalvik VM, la JVM Sun Java Hotspot ou la syntaxe du langage de programmation Java est responsable d'une forte consommation d'énergie. La raison en est que vous devez comparer tout ce dont vous parlez aux performances de quelque chose d'autre . Dans le cas le plus général, lorsque vous comparez simplement les capacités «optimales» des deux plates-formes, il est en principe possible de créer des applications Dalvik qui sont tout aussi rapides, ou plus rapides, que les programmes sur n'importe quelle autre plate-forme. Hormis la gestion automatique de la mémoire et la compilation JIT - 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 d'Objective-C, .NET, Ruby, le Oracle Hotspot JVM, Python, etc.

• La perception que "Java est lent" est due à un problème avec les anciennes versions de Java, dans la mesure où soit ils n'avaient pas de compilateur Just-In-Time (JIT), soit le JIT qu'ils possédaient était très limité en fonctionnalités. La JVM a un compilateur Just-In Timedepuis très longtemps maintenant. Un compilateur JIT fait partie du runtime (par exemple, la JVM) qui prend un bytecode indépendant du processeur - par exemple Java bytecode - 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 les fonctions ou 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 true chaque fois qu'elle est appelée, mais il n'est pas évident d'après le bytecode d'origine qu'elle le ferait, le compilateur JIT peut reconnaître qu'elle retourne juste true et remplacer l'appel de fonction par un hard- valeur codée de "vrai". Ce n'est qu'un exemple.

• Les techniques de compilation JIT et d'analyse dynamique de 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 décennie ou deux, 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 s'exécuteront plus rapidement à runtime que les langages compilés statiquement comme C et C ++. En effet, les compilateurs statiques sont généralement limités à la compilation de code au moment de la génération et 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 ré-écrire lui - mêmependant l'exécution pour fonctionner plus efficacement, il y a une énorme quantité d'avantages qui peuvent être obtenus en analysant les performances du code et en faisant 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 requis pour effectuer l'analyse est largement compensé par les avantages en termes de performances d'appeler à plusieurs reprises un code plus rapide.

• Il convient de noter que la machine virtuelle Android Dalvik contient également un JIT et qu'elle n'utilise pas le même format de bytecode que la JVM Sun / Oracle. Le JIT de Dalvik est optimisé pour les environnements à faible mémoire, et il est très avancé en ce qui concerne les améliorations des performances d'exécution. C'est donc un peu une coïncidence si la JVM et Dalvik implémentent des optimisations similaires pour leur environnement d'exécution Java respectif, mais sous le capot, elles sont assez différentes.

• N'oubliez pas que Dalvik lui-même; le noyau Linux; processus système de bas niveau; et le cœur des navigateurs Web Android (Firefox et Chrome) sont écrits en C / C ++ natif, et ils n'ont donc aucun des soucis généraux qu'un programme Dalvik aurait. C'est la même chose que iOS. Si vous parlez d' Android pur et non du gonflement de l'opérateur / tiers qui se trouve au-dessus, une très grande proportion de ce qui comprend le cœur d'Android n'est pas écrite à l'aide de 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 estimait que Dalvik agissait comme un goulot d'étranglement dans les performances de son code, ou provoquait une décharge excessive de la batterie, il pouvait simplement écrire C / C ++ ou même du code d'assemblage s'il le souhaitait, sans avoir à obtenir l'approbation de Google pour ce faire, et distribuer leur application comme ça.

Voici quelques raisons réelles pour lesquelles un appareil fonctionnant sur batterie Android, ou tout autre appareil, peut avoir des problèmes avec la durée de vie de la batterie:

• Des applications qui gardent le CPU, l'écran ou la connexion de données éveillés. En particulier, les chipsets 4G tels que le LTE consomment beaucoup d'énergie lorsqu'ils sont allumés, 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 épuisera votre batterie très rapidement. L'écran des smartphones et tablettes modernes est également très énergivore, sauf si vous réduisez la luminosité au minimum.

• "Bloatware" qui doit se trouver sur l'appareil et ne peut pas être désinstallé. Certains opérateurs sans scrupules vous obligent à exécuter un bloatware qui prend des cycles CPU et maintient la connexion de données éveillée. Cela peut être dû à l'incompétence de la part des développeurs de logiciels du bloatware, ou à un objectif intentionnel de surveiller vos activités sur votre smartphone et de les envoyer à un serveur distant pour l'exploration de données, qui est très énergivore pour votre batterie.

Enfin, je ne suis pas d'accord avec votre évaluation selon laquelle Android a des problèmes d'autonomie de batterie plus graves que sur d'autres plates-formes mobiles. Certains téléphones et appareils peuvent en effet avoir des problèmes d'autonomie de la batterie, soit en raison de la capacité de la batterie par rapport à la consommation d'énergie du matériel; paramètres d'alimentation mal optimisés (choisis par l'utilisateur, le transporteur ou le fabricant); ou des applications bloatware qui gardent les puces dans le téléphone éveillées tout le temps. Mais pour chaque exemple d'un appareil qui a des problèmes de batterie, je peux vous donner un contre-exemple d'un appareil avec 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 l'alimentation est un mélange matériel / logiciel complexe de préoccupations concurrentes, y compris les performances, la réactivité, et les attentes des utilisateurs pour la durée de vie de la batterie, avec des avantages et des inconvénients à chaque choix. Pour bien comprendre le profil d'alimentation d'un appareil, vous devez examiner de près la batterie elle-même, tout le matériel et tous les logiciels exécutés sur l'appareil.

Dans cette réponse, je comparerai les performances avec Android et IOS car les deux occupent plus de 80% des parts de marché.

Les applications Java n'utilisent pas plus de puissance. ( http://www.javarants.com/2004/05/04/looks-like-apple-should-switch/ ) La machine virtuelle Java d'Oracle ou en réalité la machine virtuelle Dalvik de Google est considérée comme beaucoup plus efficace que l'Objective-C d'IOS. Java est en mesure d'optimiser le code avant son exécution sur le téléphone, ce qui pourrait entraîner de bien meilleures performances. Les bibliothèques Java sont Open Source et ont donc été optimisées par des centaines de développeurs différents. En revanche, avec IOS, seuls les développeurs Apple sont capables de modifier le code. Moins d'examen = moins de performances potentielles.

Les programmes Android sont également capables d'exécuter du code C natif qui pourrait être contesté aussi rapidement que de nouveau Object-C (le seul langage pris en charge sur IOS).

La raison pour laquelle Google a décidé d'utiliser la machine virtuelle Dalvik est la portabilité. Je connais quatre architectures de processeur différentes sur lesquelles Android peut officiellement fonctionner (ARM, MIPS, x86, I.MX). Alors que tous les autres OS de téléphone ne peuvent en utiliser qu'un (ARM). ( http://en.wikipedia.org/wiki/Comparison_of_mobile_operating_systems ) Il est donc injuste de comparer différents types de CPU avec par exemple IPhone. Si Android était exécuté sur IPhone, Android aurait des performances et une autonomie de batterie supérieures.

"les applications Java utilisent-elles plus de puissance?" Non, tout simplement.
Pourquoi les téléphones Android ont une durée de vie de la batterie aussi épouvantable que d'autres plateformes / téléphones? De nombreux téléphones Android sont construits moins cher que l'IPhone d'Apple, mais regardez la différence de prix. L'iPhone coûte plus cher en raison de la batterie beaucoup plus grande (et c'est en moyenne un processeur plus lent). Mon téléphone Android (Google Galaxy Nexus) a une autonomie de batterie comparable à l'iPhone 4G mais a des spécifications matérielles beaucoup plus rapides (1 GHz contre 1,2 GHz).

EDIT: Java peut optimiser le code à l'insu du programmeur. Parfait, le code C fonctionnera toujours plus rapidement que Java / Objective-C / C #; Cela dit, combien de programmeurs sont parfaits? Au niveau JVM, Java et les bibliothèques seront toujours "plus parfaits" en raison de ses principes de développement open source. ( http://www.infoq.com/news/2012/03/Defects-Open-Source-Commercial )

EDIT 2: Petite information: le nouveau téléphone Android P780 de Lenovo - 42 heures de conversation contre 12 heures sur IPhone.

Oui, cela se rapporte à une consommation d'énergie accrue - des couches d'abstraction le feront. Cela entraîne également une diminution de la vitesse (côté opposé de la même pièce - si quelque chose a un surdébit supérieur, il faudra plus de temps pour effectuer et donc utiliser plus de CPU). Si je comprends bien, c'est l'un des avantages de ce que fait le NDK - permettre des accélérations pour des processeurs spécifiques en écrivant du code spécifique.

Cela dit, pour la plupart des travaux, j'imagine que les frais généraux "liés à l'alimentation" de l'exécution d'une machine virtuelle sont éclipsés par d'autres considérations - pour la plupart des programmes, l'utilisation de l'écran et des radios consommera la plus grande partie de l'énergie.

En ce qui concerne toutes les autres affiches, je crois que ce qui importe le plus ici n'est pas de savoir si C / C ++ / Java existe mais ce que font les applications.

Puisque la consommation d'énergie correspond directement au traitement, je me demanderais quel traitement ferait un programme.

Supposons que vous ajoutez des chiffres. Supposons que vous ajoutez 2 avec 2 sur une boucle infinie jusqu'à ce que vous atteigniez 2.000.000. Deux questions se posent:

1. Comment est-il implémenté: est-ce une boucle for? S'agit-il d'une boucle while? (Est-ce un hack Goto / Label?)
2. Comment le code est-il optimisé?

Ces deux questions définissent en fin de compte combien d'opérations le processeur doit effectuer et, finalement, la quantité d'énergie qu'un périphérique utilise. Cela étant dit, le "surcoût" de l'exécution d'un environnement virtualisé peut être négligeable en raison de l'optimisation précédente effectuée par Java sur l'ensemble du programme, mais là encore, tout dépend de ce que fait l'application.

Oui.

Les machines virtuelles «font tout deux fois», et pas nécessairement efficacement. Ainsi, ils utiliseront au moins deux fois plus d'énergie pour traiter les mêmes instructions qu'une «vraie machine». La présence d'une machine virtuelle ralentit les choses et consomme plus d'énergie. Fondamentalement, les systèmes d'exploitation comme iOS et WIndows feront tout plus rapidement et avec moins de consommation d'énergie.

Cela se traduit par de réelles différences dans les transitions d'écran, le chargement des pages, la navigation, des choses comme ça. Actuellement, je compare Android (VM) et Windows Phone, et même avec un processeur plus lent (1 GHz contre 1,6 GHz), Windows surpasse considérablement Android en effectuant le même type de tâches.

Cependant, ce qui attire l'attention de la plupart des gens, c'est lorsqu'ils installent une application et que leur batterie s'use plus rapidement. Ce n'est pas vraiment dû à la machine virtuelle, mais à une application qui utilise avidement les ressources.

La raison d'être d'un système d'exploitation de machine virtuelle, la portabilité, n'est pas une bonne raison de baser un système d'exploitation. Voyez-vous des gens acheter des téléphones avec leur architecture préférée et utiliser Android parce que c'est portable? Voyez-vous des gens abandonner des performances et une fiabilité supérieures et mettre Android sur leurs téléphones non Android? Les gens achètent un téléphone Android, ou un Windows Phone, ou un IPhone, etc. Il n'est pas pratique de sacrifier les performances pour la portabilité dans les appareils à faible coût. C'était une bonne idée qui est devenue un échec.