Les applications Android sont interprétées plutôt que compilées. Cela les rend-elles plus lentes que les applications iOS au moment de l'exécution ?
Réponses
Trop de publicités?Java n'est pas interprété sur Android. Les applications Android sont compilées en bytecode par le développeur. Le bytecode est une représentation compacte du programme : plus petit que le code source écrit par le programmeur, mais toujours pas directement exécutable par le CPU. Certaines optimisations, telles que la suppression du code mort, peuvent être effectuées à ce stade.
Lorsque vous chargez l'application sur un appareil, la JVM Dalvik compile le bytecode en code exécutable natif, juste au moment où elle est sur le point de s'exécuter. Il s'agit juste à temps compilation. Cela provoque un bref ralentissement pendant que le programme attend d'être compilé, mais après cela, il n'y a pas de surcharge de performance, car le code a été compilé en code exécutable natif.
Il y a quelques avantages en termes de performances à procéder de cette manière plutôt que de compiler en amont sur l'ordinateur du développeur. L'application peut être compilée pour le processeur particulier du téléphone, en tirant parti de ses fonctions matérielles et en utilisant ses caractéristiques de performance. Par exemple, elle peut utiliser les opérations matérielles à virgule flottante si le processeur le prend en charge. En outre, un compilateur JIT intelligent (il est vrai que Dalvik n'est pas aussi intelligent) peut surveiller la façon dont le programme s'exécute et effectuer des optimisations en fonction de la façon dont le programme est utilisé en situation réelle. Il peut recompiler le code avec de meilleures indications de branchement après avoir vu quelles options sont activées et désactivées dans votre environnement, sur votre téléphone. Un compilateur initial ne dispose pas de ces informations pour les utiliser.
Dalvik utilise le Cache Dalvik et d'autres techniques pour atténuer les inconvénients de la compilation JIT. La nouvelle JVM pour Android L et les versions ultérieures, ART, remplace entièrement la JIT par une en avance sur le temps compilateur. Celui-ci compile le bytecode en code exécutable natif lorsque l'application est installée, afin de bénéficier de la plupart des avantages du JIT sans le délai de chargement de l'application.
N'oubliez pas que les applications Android ne sont pas entièrement constituées de Java. Les développeurs ont le NDK d'écrire tout ou partie de leurs applications en C ou C++, pour les parties de l'application dont les performances sont critiques, notamment pour les jeux. Les interfaces spécialisées comme OpenGL et Renderscript permettent aux programmeurs de tirer parti de matériel spécial comme le GPU et le coprocesseur SIMD pour certains types de calcul.
Il n'y a donc pas de réponse simple à votre question. L'utilisation du JIT au lieu de la compilation initiale rend certaines choses plus rapides, d'autres plus lentes. Ce n'est qu'une partie des performances globales du système d'exploitation.
Comme il s'agit d'une question générale, voici une réponse générale.
"Les applications iOS sont-elles plus rapides que les applications Android puisque ces dernières sont interprétées ?"
Tout d'abord, les applications iOS ne sont pas "plus rapides" que les applications Android.
Deuxièmement, concernant la question "Les applications Android sont interprétées". C'est quelque chose que l'on dirait à propos de l'informatique, comme "il y a 15 ans" : comme vous pouvez le voir dans la discussion ci-dessus, la situation est beaucoup plus compliquée aujourd'hui ; des technologies entièrement nouvelles sont apparues. Le concept "le compilé est plus rapide que l'interprété !" était pertinent pour comparer, par exemple, perl au code machine il y a 20 ans ; les choses ont tellement évolué que la question ne peut pas vraiment être appliquée clairement à "iOS V Android" aujourd'hui.
Troisièmement, il existe d'autres problèmes dans la programmation mobile qui éclipsent totalement ces considérations. Pour ne citer qu'un exemple sur le terrain, les programmeurs mobiles s'épuisent à gérer de grandes listes d'images défilantes, le chargement paresseux et d'autres problèmes similaires. La façon dont les deux systèmes d'exploitation, et les diverses bibliothèques populaires, gèrent ces problèmes critiques éclipse souvent les autres questions.
Quatrièmement, les problèmes liés aux puces graphiques et à leurs relations complexes avec les logiciels, OpenGL, etc. constituent un autre problème majeur des téléphones mobiles. Par exemple, Apple est en train de sortir un système qu'ils appellent "Metal" en relation avec ces problèmes, et Android est en train de sortir son propre "bidule" dans ce domaine. Ces questions autour du pipeline graphique sont extrêmement importantes pour la façon dont les applications se sentent dans votre main.
La réponse très courte à votre question est que "compilé contre interprété" est un point de discussion obsolète, vous savez ?
(De plus, je ne trouve pas particulièrement le Note3 "plus lent" qu'un iPhone. Par ailleurs, une partie de ces résultats est un pur artefact - il existe bel et bien des téléphones Android bon marché : il n'y a tout simplement pas d'iPhones à faible performance fabriqués, donc certaines personnes peuvent avoir des idées erronées à partir de cela).
Le fait que les applications interprétées ne signifient pas qu'elles sont toujours lentes. Elles sont parfois plus puissantes et dynamiques que les applications compilées. Comme tous les codes dans les applications compilées sont compilés une fois et la sortie est conservée sous forme de bibliothèques ou d'exécutables, tandis que dans le langage interprété, une fois peut changer aléatoirement la séquence d'exécution. Je peux donc dire que cela dépend du développeur et de sa façon de programmer.
Cependant, Java (le langage de programmation d'Android) n'est pas interprété mais compilé en JIT. Cela signifie que les programmes Android sont compilés juste avant d'être exécutés, ce qui donne des performances raisonnablement similaires à celles de l'Objective C d'iOS.
Plus récemment, le cadre ART d'Android précompile les applications, de sorte qu'elles sont exécutées de la même manière que les applications iOS. En d'autres termes, la prochaine version d'Android sera vraisemblablement aussi rapide qu'iOS.
更新情報
Les langages de programmation appartiennent généralement à l'une des deux catégories suivantes : Compilé ou Interprété. Avec un langage compilé, le code que vous saisissez est réduit à un ensemble d'instructions spécifiques à la machine avant d'être enregistré sous forme de fichier exécutable. Avec les langages interprétés, le code est enregistré dans le même format que celui que vous avez saisi. Les programmes compilés s'exécutent généralement plus rapidement que les programmes interprétés, car ces derniers doivent être réduits en instructions machine au moment de l'exécution. Cependant, avec un langage interprété, vous pouvez faire des choses qui ne peuvent pas être faites dans un langage compilé. Par exemple, les programmes interprétés peuvent se modifier eux-mêmes en ajoutant ou en modifiant des fonctions au moment de l'exécution. Il est aussi généralement plus facile de développer des applications dans un environnement interprété parce que vous n'avez pas à recompiler votre application chaque fois que vous voulez tester une petite section.