Pourquoi Android utilise-t-il Java? [fermé]

114

OK, cela devrait vraiment être demandé à quelqu'un de Google, mais je veux juste d'autres opinions.

Même Android prend en charge les applications de code natif, le principal outil de développement est Java. Mais pourquoi? Je veux dire, n'est-ce pas trop lent pour interpréter le code sur un appareil mobile? Lors de l'introduction de Froyo, Google a déclaré que le nouveau compilateur JIT peut réaliser des applications 2 à 5 fois plus rapides. Cela signifie que l'utilisation de Java sur du code natif est 2 fois plus lente.

Oui, je sais que l'utilisation d'applications de code managé est plus sûre en termes de stabilité du système, car la machine virtuelle a un meilleur contrôle du programme, mais malgré tout, cette baisse de performances est énorme, et je ne vois pas pourquoi l'utiliser.

B.Gen.Jack.O.Neill
la source
12
Le code Java n'est pas interprété, du moins pas sur Android - il est compilé et exécuté sur une machine virtuelle.
Radomir Dopieralski
4
Je pensais que Sun prouvait que Java pouvait être (dans quelques domaines, mais assez souvent presque) aussi rapide que le code natif? De plus, les gars de Google sont un pack intelligent - je suis convaincu que le JIT qu'ils ont récemment introduit produira tôt ou tard un très bon code.
1
@ b-gen-jack-o-neill La réponse est en fait non, car la VM peut dire quel code est exécuté à l'exécution et comment il est exécuté. Par exemple, Apple utilise LLVM sous OS X dans le but explicite d'optimiser les fonctions graphiques essentielles aux performances lors de l'exécution. Ceci est fait spécifiquement parce que c'est plus rapide que les techniques de code natif.
PeterAllenWebb
1
@ b-gen-jack-o-neill, le bytecode Java peut être compilé en code natif au moment de l'exécution.
Mike Daniels
1
@ b-gen-jack-o-neill - la VM a accès à plus d'informations sur l'environnement d'exécution qu'un compilateur classique ne le fait, elle peut donc faire des choix plus intelligents. Dans quelle mesure cela compense les frais généraux supplémentaires variera d'une application à l'autre.
CurtainDog

Réponses:

98

Des points:

  1. Java est un langage connu, les développeurs le savent et n'ont pas besoin de l'apprendre

  2. il est plus difficile de se tirer une balle avec Java qu'avec du code C / C ++ car il n'a pas d'arithmétique de pointeur

  3. il fonctionne dans une machine virtuelle, donc pas besoin de le recompiler pour chaque téléphone et facile à sécuriser

  4. grand nombre d'outils de développement pour Java (voir point 1)

  5. plusieurs téléphones portables utilisaient déjà Java ME, Java était donc connu dans l'industrie

  6. la différence de vitesse n'est pas un problème pour la plupart des applications; si c'était le cas, vous devriez coder dans un langage de bas niveau

josefx
la source
5
L'exécution sur une VM (donc pas de recompilation) est un énorme plus. En outre, il sépare facilement les processus les uns des autres, empêchant une application
malveillante
1
À propos de l'application malveillante - cela semble intéressant. Corrigez-moi si je me trompe, mais les processeurs x86 ont un biult en protection via les modes de pagination et de sonnerie, par conséquent, l'application ne peut pas changer sa page en mémoire et ne peut donc pas interférer avec une autre application que l'utilisation de l'API du système d'exploitation. Mais cette fonctionnalité a-t-elle des processeurs ARM? Je n'en ai aucune idée. Sinon, ce serait génial + pour Java sur cette plate-forme.
B.Gen.Jack.O.Neill
Le processeur n'a rien à voir avec une application malveillante faisant des choses néfastes
Falmarri
4
La protection de la mémoire fait partie de certaines architectures de processeurs. Il empêche une application malveillante d'accéder à la mémoire attribuée à une autre application. en.wikipedia.org/wiki/Memory_protection
josefx
1
@Falmarri: Oui, c'est vrai. Fondamentalement, c'est très simple. Votre application a attribué son propre espace d'adresse. Toutes les adresses auxquelles vous souhaitez accéder sont traduites par MMU. Vous voulez accéder à l'adresse 0x0000 et MMU la traduit par exemple en 0x0E21. Et pour vous empêcher de changer l'adresse de base, son instruction privilégiée et votre programme lorsqu'il est lancé par l'OS a attribué le niveau de privilège le plus bas. Sinon, une seule instruction CLI (désactiver les interruptions) planterait le système ...
B.Gen.Jack.O.Neill
39

Au niveau de l'octet-code, Android n'utilise pas Java. La source est Java, mais elle n'utilise pas de JVM.

David Thornley
la source
7
Oui. Java est la source, mais elle n'est pas compilée en code d'octet compatible avec la machine virtuelle Java. C'est pourquoi ils seront probablement la plupart / tous les litiges de brevet avec sun / oracle. Ils n'utilisent que la syntaxe du langage.
John Gardner
1
Il doit encore prendre en charge la plupart des fonctions de java vm. Ils ne peuvent donc pas les optimiser.
josefx
1
Alors pourquoi la nécessité d'installer le JDK lors du développement sous Android? Est-ce juste pour l'émulateur?
jiggunjer
@jiggunjer Android Studio est en fait développé en Java. Et l'émulateur aussi.
Rudra B. Saraswat le
20

L'amélioration de la stabilité du système est très importante sur un appareil comme un téléphone portable.

La sécurité est encore plus importante. L'environnement Android permet aux utilisateurs d'exécuter des applications semi-fiables qui pourraient exploiter le téléphone de manière vraiment désagréable sans une excellente sécurité. En exécutant toutes les applications dans une machine virtuelle, vous garantissez qu'aucune application ne peut exploiter le noyau du système d'exploitation à moins qu'il n'y ait une faille dans l'implémentation de la VM. L'implémentation de la VM, quant à elle, est vraisemblablement petite et possède une petite surface de sécurité bien définie.

Peut-être le plus important, lorsque les programmes sont compilés pour coder pour une machine virtuelle, ils n'ont pas besoin d'être recompilés pour un nouveau matériel. Le marché des puces téléphoniques est diversifié et en évolution rapide, c'est donc un gros problème.

De plus, l'utilisation de Java réduit la probabilité que les applications que les gens écrivent soient elles-mêmes exploitables. Pas de dépassements de tampon, d'erreurs avec les pointeurs, etc ...

PeterAllenWebb
la source
Une autre réponse de David dit qu'Android n'utilise pas jvm
Ssenyonjo
13

Le code natif n'est pas nécessairement plus rapide que le code Java. Où sont vos données de profil montrant que le code natif pourrait s'exécuter plus rapidement?

Pourquoi Java?

  • Android fonctionne sur de nombreuses plates-formes matérielles différentes. Vous auriez besoin de compiler et d'optimiser votre code natif pour chacune de ces différentes plates-formes pour voir les avantages réels.

  • Il existe un grand nombre de développeurs maîtrisant déjà Java.

  • Java a un énorme support open source, avec de nombreuses bibliothèques et outils disponibles pour faciliter la vie des développeurs.

  • Java vous protège de nombreux problèmes inhérents au code natif, tels que les fuites de mémoire, la mauvaise utilisation du pointeur, etc.

  • Java leur permet de créer des applications sandbox et de créer un meilleur modèle de sécurité afin qu'une application défectueuse ne puisse pas détruire tout votre système d'exploitation.

Cheryl Simon
la source
7

Tout d'abord, selon Google, Android n'utilise pas Java. C'est pourquoi Oracle poursuit Google. Oracle prétend qu'Android enfreint certaines technologies Java, mais Google dit que c'est Dalvik.

Deuxièmement, je n'ai pas vu d'interpréteur de code d'octet Java depuis 1995.

Pouvez-vous étayer votre conjecture de performance avec des points de repère réels? La portée de vos présomptions ne semble pas justifiée étant donné les informations de base inexactes que vous fournissez.

Erickson
la source
4

Java a un argument assez convaincant pour que Google l'utilise dans Android: il dispose d'une énorme base de développeurs. Tous ces développeurs sont (en quelque sorte) prêts à développer pour leur plate-forme mobile.

Gardez à l'esprit que, techniquement parlant, Android n'utilise pas de Java pur .

Pablo Santa Cruz
la source
2
Je pense que toutes les personnes intéressées par le développement mobile sont également intéressées par des langages «plus cool» que Java.
Earlz
4

Comme évoqué ailleurs, le principal problème est qu'Android est conçu comme un système d'exploitation portable, pour fonctionner sur une grande variété de matériels. Il s'appuie également sur un cadre et un langage familiers à de nombreux développeurs mobiles existants.

Enfin, je dirais que c'est un pari contre l'avenir - quels que soient les problèmes de performances qui existent deviendront sans importance à mesure que le matériel s'améliorera - également en amenant les développeurs à coder contre une abstraction, Google peut déchirer et changer le système d'exploitation sous-jacent beaucoup plus facilement que si les développeurs codaient avec les API POSIX / Unix.

Pour la plupart des applications, la surcharge liée à l'utilisation d'un langage basé sur une machine virtuelle par rapport au langage natif n'est pas significative (le goulot d'étranglement pour les applications consommant des services Web, comme Twitter, est principalement la mise en réseau). Palm WebOS le démontre également - et utilise JavaScript plutôt que Java comme langage principal.

Étant donné que presque toutes les machines virtuelles JIT se compilent jusqu'au code natif, la vitesse du code brut est souvent comparable à la vitesse native. Un grand nombre de retards attribués aux langages de niveau supérieur sont moins liés à la surcharge de la VM que d'autres facteurs (un runtime d'objet complexe, une vérification de «sécurité» de l'accès à la mémoire en vérifiant les limites, etc.).

N'oubliez pas que quel que soit le langage utilisé pour écrire une application, une grande partie du travail réel est effectuée dans les API de niveau inférieur. Le langage de niveau supérieur enchaîne souvent simplement les appels d'API.

Il existe, bien sûr, de nombreuses exceptions à cette règle - des jeux, des applications audio et graphiques qui repoussent les limites du matériel téléphonique. Même sur iOS, les développeurs se tournent souvent vers C / C ++ pour accélérer dans ces domaines.

JulesLt
la source
1

Le nouveau JIT exécute les applications 2 à 5 fois plus vite que l'ancien dalvikVM (tous deux JAVA). La comparaison n'est donc pas C sur JAVA, mais JIT sur dalvikVM.

claviériste
la source
1

Tout d'abord, c'est à peu près la même chose avec Windows Mobile ou l'iPhone, le framework .net a besoin de sa propre VM ainsi que du cacao.

Et même si les performances ne sont pas au mieux, car il s'agit d'une interprétation de byte code, Android amène toute la communauté Java en tant que développeurs potentiels. Plus d'applications, plus de clients, etc.

Pour finir, aucune performance n'est pas si mauvaise, c'est pourquoi java est utilisé même sur des appareils plus petits (voir JavaMe).

Colin Hebert
la source
Cocoa n'est pas basé sur une machine virtuelle - c'est tout du code natif compilé - mais contrairement au C / C ++ pur, il a un runtime dynamique (similaire à Smalltalk / Ruby / Python) - qui a ses propres problèmes de performances et optimisations. Il est à noter que la plupart des jeux iPhone sont en grande partie C ++ plutôt qu'Obj-C.
JulesLt