Aller au contenu

Architecture Android


Infernus

Recommended Posts

Bien qu'ayant un rapport avec Android je n'ai pas posté cette question dans Android : Fonctionnement..., car c'est une section plus appropriée aux petits problèmes quotidiens.

De ce que j'ai compris Android est composé de plusieurs couches.

A la base on a un noyau Linux qui gère le matos, et dessus on a un interpreteur Java qui se nomme Dalvik VM.

Ma question est la suivante, pourquoi avoir choisi de passer par un interpreteur sachant que cela implique une perte de performance non négligeable comparé à du code natif ?

Ok le java est très agréable a coder. Mais l'interet premier du Java est de pouvoir lancer n'importe quelle application sur n'importe quel système en ayant "simplement" à réecrire un interpreteur pour ce système.

Alors peut être que Google a prévu depuis le début de conquérir les plates-formes x86, ce qui expliquerai ce choix.

Mais en attendant je suis presque sûr que c'est cette structure qui fait que le système n'a jamais été très fluide sur les machines "peu" puissantes.

Je peux me planter totalement ! C'est l'analyse que j'en ai fait. C'est pour ca que je vous demande ce que vous en pensez, et si vous avez d'autres explications ;)

Merci de votre lecture

Lien vers le commentaire
Partager sur d’autres sites

*mode fraise*

Crounch crounch crounch ... manger ... crounch ...

*fin mode fraise*

(Je vais stoper le HS sinon je vais encore me faire engueuler ... ;) )

Mais je vais suivre ce sujet c'est intéressant de,savoir les motivations de google sur le choix des composants de la plateforme android.

Lien vers le commentaire
Partager sur d’autres sites

Moi je m'y connais pas trop non plus mais je pense comme vous : c'est en java pour que "Mr. Tout le monde" puisse codé dessus.. par contre si on arrivait à passer que par le noyau Linux sans l'interpréteur java on gagnerait énormément de perfs mais je sais pas si c'est possible ou si ça a déjà été fait..

Message envoyé avec l'application Forum Frandroid

Lien vers le commentaire
Partager sur d’autres sites

@lolo7438 : le probleme du java c'est qu'il n'est pas directement comprehensible par le systeme. Les .jar ( me semble que c'est la meme pour les apk, c'est ce dont j'aimerai avoir la confirmation entre autre ) sont du bytescode, totalement inconnu du processeur. Et c'est la que l'interpreteur arrive pour traduire ca en assembleur ( seule chose que le proco comprenne )

Mais on peut chinter l'interpreteur en codant directement en C/C++ avec le ndk. C'est le meilleur moyen d'obtenir des performances parfaites !

@meel : rien de pire que le flash niveau perfs ( meme si je pense que tu blaguais ;) )

@Mikawelll : on perds des perfs a cause du fait que l'interpreteur doivent tout le temps retraduire en asm. Tandis que sur un langage natif, le programme est directement compilé en asm. En terme d'efficacité le pixi plus d'un ami ( telephone naze niveau perf ) tourne totalement parfaitement meme en multi tache, comparé a mon milestone.

De ce que j'ai en tête la perte de perfs est de l'ordre de 15-20% (peut etre faux !)

Par exemple a l'epoque des HTC magic/dream, je suis "sûr" que ca aurait mieux tourné !

Lien vers le commentaire
Partager sur d’autres sites

Et ça serait possible de ré-encoder tout le système en C ou C++? Parce que si j'ai bien compris le fait de passer par un interpréteur "ralenti" le téléphone (même si comme l'a dit Mikawell on est pas à la ramasse) et donc si on passe par du C/C++ ça serait encore plus rapide? (Le pied ^^)

Message envoyé avec l'application Forum Frandroid

Lien vers le commentaire
Partager sur d’autres sites

De ce que je crois comprendre, faudrait pouvoir recoder un home en C/C++ pour que ce soit bien fluide ( je ne sais pas si c'est possible, mais surement )

Le système étant composé d'un noyau linux, il est déjà codé en natif ( pas forcement C/C++ mais on s'en tape ).

Pour que tout soit plus efficace il faudrait que chaque développeur code avec le NDK.

Si cela se trouve j'ai loupé un truc, si c'est le cas merci de me le faire remarquer ;)

Lien vers le commentaire
Partager sur d’autres sites

Ca parle un peu dans le vide ici !

Du C/C++ dans Android, il y en a déjà beaucoup, rien que pour le noyau linux. Et vous pouvez ajouter les drivers et les codecs audio vidéo.

Une home en C/C++ avec le NDK et JNI, je crois qu'il y en a déjà mais je sais plus lesquelles.

Le choix du java ? Je ne sais pas vraiment.

Le truc c'est que je ne sais pas si le choix date de Android Inc, la boite à l'origine d'Android et rachetée par Google en 2005, ou si c'est un changement de cap opéré par Google par la suite.

Dans la première hypothèse, ce serait pour partir des bases offertes par J2ME (le java pour mobile) ou au moins de ses concepts.

La deuxième hypothèse, c'est que Google croit en Java (il suffit de voir GWT) et a imposé un langage qu'il affection.

J'ai pas le réponse mais ce sont mes idées.

@Mikawell:

Tu rentres dans le fanboyisme/haterisme de plus en plus ridicule. Parler de iOS dès qu'on parle des performances de Android c'est idiot.

Là on te parle de performances propre au système. De sa capacité à être plus rapide si tu compares deux versions de Android.

Tu vas avoir une place d'or dans Fanboy Fact à coté des mecs de iGénération si tu continues...

Lien vers le commentaire
Partager sur d’autres sites

Le fait de ne pas tout mettre en code natif permet aussi de ne pas avoir à s’inquiéter du matos sur lequel tournera l'application.

Il ne faut pas oublier qu'au-delà de certaines caractéristiques communes les téléphones équipés d'android sont aussi très variés en terme de CPU, GPU, etc

Avoir un truc performant en natif reviendrait à coder des appli propres à chaque hardware et/ou combinaison hardware. Donc si on se retrouve à devoir faire du C++ "générique" c'est à dire qui ne sait pas tirer partie des spécificités de chaque puces, alors autant faire du code managés, au moins ça a le mérite d'être plus facile à faire pour le développeur qui ne perd son temps à pondre des lignes et des lignes en C++ alors que ça n'apporterai rien de spécial à l'usage (la plupart des appli n'ont que faire d'être exécutée en natif)

Reste le cas des applis telles que les jeux qui sont forcément dépendant des performances du hardware. Là il me semble qu'on a déjà des cas codés en natif... à confirmer.

Mais bon, le code mangés n'est pas forcément une mauvaise chose.

Autre chose: cela permet de mieux isoler l’exécution d'une application et cela evite les fuites de mémoire, et/ou qu'une appli mal codée plante tout le système. En natif une application pourrait prendre le dessus et empêcher de recevoir un appel téléphonique (balot pour téléphone non ?)

Lien vers le commentaire
Partager sur d’autres sites

@ Jorodan : C'est ce que je disais pour le noyau ça je le savais.

Effectivement c'est bien ce que je pense pour la 2ème hypothèse.

Si tu retrouves une home en natif ca m'interesse !

@Le_Poilu : Oui oui il y a des jeux codés en natif. D'ailleurs Firefox est aussi codé en C++ ( c'était d'ailleurs leur condition pour développer sur Android )

Certes pour les fuites de mémoire, c'est la m****.

Je ne sais pas ce que tu en penses, ou ce que tu sais. Mais je pense qu'une appli en natif est plus efficace qu'une appli en java, même sans être optimisé, non ?

Lien vers le commentaire
Partager sur d’autres sites

Archivé

Ce sujet est désormais archivé et ne peut plus recevoir de nouvelles réponses.

×
×
  • Créer...