Les applications iOS sont-elles plus rapides que les applications Android puisque les applications Android sont interprétées?

Les applications Android sont interprétées plutôt que compilées. Cela les rend-ils plus lents que les applications iOS au moment de l'exécution?

applications ios

— Armon Safai
source

Ce n'est pas une bonne question car les applications Android ne sont pas interprétées, tout comme la bonne réponse le fait remarquer.

— Aaronaught

Normalement, la réponse acceptée n'étant pas la meilleure réponse n'est pas trop un problème, car le but est d'aider la personne qui a posé la question (voir ce méta-post). Mais c'est un cas assez extrême @ArmonSafai La réponse que vous avez choisie comme correcte est pleine de désinformation et est au-delà du point d'être récupérable avec des modifications. Veuillez envisager de sélectionner une autre réponse.

— Selali Adobor

Notez que certaines grandes sociétés - IBM inclus - écrivent de nos jours de grandes applications en Java. Étant donné un compilateur Just-In-Time (JIT), qui est une partie standard d'une machine virtuelle Java moderne, les performances sont vraiment comparables à tout autre langage de haut niveau. Java n'est pas seulement "un langage interprété" depuis de nombreuses années.

— keshlam

Les compilateurs JIT ne sont pas du tout liés au concept de JVM. Il existe des JVM qui n'utilisent pas de compilateurs JIT, même commerciaux. Certaines variantes de la machine virtuelle Java d'IBM n'activent pas JIT par défaut, par défaut à la compilation AOT. Aussi, petite note, "les applications majeures de Java ces jours-ci" étaient probablement un peu plus adaptées il y a une décennie et demie (IBM ajoutait à Java avant 1997)

— Selali Adobor

La question est quelque peu trompeuse. Une application iOS «native» est écrite en Objective-C (ou Swift) et compilée, tandis qu'une application Android «standard» est écrite en Java et compilée en bytecode. Voir la réponse de @ DanHulme. Mais il est possible d'écrire des applications pour l'une ou l'autre plate-forme en HTML et JavaScript en utilisant par exemple PhoneGap / Cordova. Une application HTML est généralement perçue comme s'exécutant plus lentement qu'une application native sur la même plate-forme. Donc, si une application similaire pour la «autre» plate-forme semble plus lente, c'est peut-être parce qu'elle a été créée en utilisant une technologie différente.

— David

Réponses:

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 de code mort, peuvent être effectuées à ce stade.

Lorsque vous chargez l'application sur un appareil, la machine virtuelle Java Dalvik compile le bytecode en code exécutable natif, juste au moment où il est sur le point de s'exécuter. Il s'agit d' une compilation juste à temps . Il provoque un bref ralentissement pendant que le programme attend d'être compilé, mais après cela, il n'y a pas de surcharge de performances, car le code a été compilé en code exécutable natif.

Il existe certains avantages en termes de performances à le faire de cette façon au lieu de compiler d'avance 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 fonctionnalités matérielles et en utilisant ses caractéristiques de performance. Par exemple, il peut utiliser des opérations matérielles en virgule flottante si le processeur le prend en charge. De plus, un compilateur JIT intelligent (certes, Dalvik n'est pas tout à fait 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 utilisation réelle. Il pourrait recompiler le code avec une meilleure indication de branche une fois qu'il a vu quelles options sont activées et désactivées dans votre environnement, sur votre téléphone. Un compilateur initial n'a pas ces informations à 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 versions ultérieures, ART, remplace entièrement le JIT par un compilateur avancé . Cela compile le bytecode en code exécutable natif lorsque l'application est installée, pour obtenir la plupart des avantages de JIT sans retarder le 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 pour écrire tout ou partie de leurs applications en C ou C ++, pour les parties critiques de la performance de l'application, en particulier pour les jeux. Les interfaces à usage spécial comme OpenGL et Renderscript permettent aux programmeurs de profiter de matériel spécial comme le coprocesseur GPU et SIMD pour certains types de calcul.

Donc vraiment, il n'y a pas de réponse simple à votre question. L'utilisation de JIT au lieu de la compilation initiale accélère certaines choses, d'autres plus lentement. Ce n'est qu'une partie des performances globales du système d'exploitation.

— Dan Hulme
source

+1 pour une grande explication. J'attendais en fait une réponse comme celle-ci.

— MANI

Pas vraiment différent du vieux débat fatigué sur les performances ".NET / Java contre C ++" sur PC Ce sont des pommes et des oranges.

— Aaronaught

@ArmonSafai Tout à fait.

— Dan Hulme

@MTilsted: C'est un peu vrai, mais il met en cache presque tout, donc ce dont vous parlez ne se produira probablement que la toute première fois que vous exécutez une application.

— Aaronaught

Le principal problème ici est que Dalvik est considéré comme une machine virtuelle Java "normale". Entre être basé sur un registre, par opposition à une pile basée sur HotSpot (en raison de la nature des processeurs ARM par rapport à ceux ciblés par HotSpot [comme IA32]), c'est l'utilisation de Zygote et le concept de fichiers odex (c'est-à-dire toute l'idée de ne pas [plus ou moins] passer directement du fichier de classe au chargeur de classe), traiter Dalvik comme une machine virtuelle Java normale est susceptible de conduire à des idées fausses. D'autant plus que de nombreux détails de l'implémentation HotSpot sont souvent associés par erreur aux machines virtuelles Java en général (comme c'est le compilateur JIT).

— Selali Adobor du

Puisqu'il s'agit d'une question large, voici une réponse large.

"Les applications iOS sont-elles plus rapides que les applications Android puisque les applications Android sont interprétées?"

Tout d'abord, les applications iOS ne sont pas "plus rapides que" les applications Android.

Deuxièmement, concernant le problème "Les applications Android sont interprétées". C'est quelque chose que vous diriez sur 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 "compilé est plus rapide qu'interprété!" était pertinent en comparant, vous savez, perl au code machine il y a 20 ans; les choses ont tellement évolué que ce problème ne peut pas être vraiment clairement appliqué à "iOS V Android" aujourd'hui.

Troisièmement, il y a d'autres problèmes dans la programmation mobile qui submergent totalement ces considérations. Juste un exemple sur le terrain, les programmeurs mobiles se font passer pour gérer de grandes listes d'images défilantes, le chargement paresseux et des 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 submerge souvent d'autres problèmes.

Quatrièmement, un autre problème majeur sur les mobiles est celui du chipset graphique et des diverses relations compliquées de celui-ci avec les logiciels, OpenGL, etc. Par exemple, Apple sort avec un système qu'ils appellent "Metal" par rapport à ces problèmes, et Android sort avec son propre "machin" dans ce domaine. Ces problèmes autour du pipeline graphique sont extrêmement importants pour la façon dont les applications "se sentent" dans votre main.

La réponse très courte à votre question est "compilé V. interprété" est fondamentalement un point de discussion obsolète, vous savez?

(De plus, je ne trouve pas particulièrement une Note3 "plus lente" qu'un iPhone. De plus, il s'agit en partie d'artefacts purs - il existe des téléphones Android bon marché: il n'y a tout simplement pas d'iPhone à faible performance, donc certaines personnes peuvent avoir des erreurs idées de cela.)

— Fattie
source

-3

Parce que les applications interprétées ne signifient pas qu'elles sont toujours lentes. Parfois, ils sont plus puissants et dynamiques que ceux compilés. Comme tous les codes de l'application compilée sont compilés une fois et que la sortie est conservée sous forme de bibliothèques ou d'exécutables, tandis qu'en langage interprété, une fois peut changer aléatoirement la séquence d'exécution. Je peux donc dire que cela dépend de développeur à développeur et de la manière de programmation.

Cependant, Java (langage de programmation Android) n'est pas interprété mais est compilé en JIT. Cela signifie que les programmes Android se compilent juste avant de les exécuter, donnant des performances raisonnablement similaires à l'objectif C. d'iOS.

Plus récemment, le framework ART d'Android précompile les applications, elles sont donc exécutées de la même manière que les applications iOS. En d'autres termes, la prochaine version d'Android sera probablement aussi rapide qu'iOS.

Mise à jour

Les langages de programmation entrent généralement dans l'une des deux catégories suivantes: compilés ou interprétés. Avec un langage compilé, le code que vous entrez est réduit à un ensemble d'instructions spécifiques à la machine avant d'être enregistré en tant que fichier exécutable. Avec les langues interprétées, le code est enregistré dans le même format que vous avez entré. Les programmes compilés s'exécutent généralement plus rapidement que les programmes interprétés car les programmes interprétés doivent être réduits aux instructions machine lors 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 lors de l'exécution. Il est également généralement plus facile de développer des applications dans un environnement interprété car vous n'avez pas à recompiler votre application chaque fois que vous souhaitez tester une petite section.

— See-Sharp
source

que voulez-vous dire "une fois peut changer aléatoirement la séquence d'exécution? Et comment sont-ils plus puissants et dynamiques? Je ne dis pas non plus qu'ils sont lents, juste qu'ils sont plus lents, même légèrement.

— Armon Safai

Ce n'est pas tout à fait vrai. Il est trompeur de dire que ne pas avoir à recompiler est un avantage, car vous devez toujours créer un fichier APK et le déployer sur l'appareil de test. Google n'a pas décidé d'utiliser Java: Android était déjà basé sur Java avant que Google ne l'achète. Les fichiers APK ne contiennent pas le code "au même format que [le programmeur] a entré".

— Dan Hulme,

Microsoft .NET est compilé en code IL qui est également interprété comme java est compilé en bytecode.

— Esben Skov Pedersen

Beaucoup d'informations dans cette réponse ne sont vraiment pas pertinentes ou techniquement correctes. Je suggère honnêtement que cette réponse soit totalement révisée pour plus de précision technique.

— Aza

Java n'est généralement pas un langage interprété , sauf si vous avez affaire à une implémentation JVM inhabituelle. La compilation JIT n'est pas la même chose qu'un interprète, donc la plupart de cette réponse est honnêtement peu pertinente dans le contexte des performances d'Android car elle utilise JIT.

— eldarerathis