Android : Google remplace officiellement Dalvik par son Android Runtime

Android : Google remplace officiellement Dalvik par son Android Runtime

Developers ! Developers ! Ah non...

Avatar de l'auteur
Vincent Hermann

Publié dans

Logiciel

20/06/2014 5 minutes
87

Android : Google remplace officiellement Dalvik par son Android Runtime

Il y a désormais de fortes chances que la prochaine version d’Android  soit fournie avec une nouvelle machine virtuelle par défaut. ART, pour Android Runtime, devrait ainsi remplacer Dalvik et fournir aux applications un gain bienvenu de performances.

android dalvik art

Des applications compilées jusqu'ici à la volée 

Sous Android, la très grande majorité des applications sont écrites en Java. Comme tout développement utilisant ce langage, elles ont besoin d’une machine virtuelle qui va s’occuper de les compiler avant qu’elles ne s’exécutent. Dans le système mobile de Google, ce rôle est attribué à Dalvik, qui est donc chargé de récupérer des fichiers DEX qui contiennent du bytecode. Ce dernier est en fait un langage intermédiaire, conçu pour être compilé à la volée (compilation JIT).

 

Quand un utilisateur d’Android récupère une application depuis la boutique Google Play, il télécharge en fait un code intermédiaire. Quand l’application se lance, le bytecode est alors compilé en langage machine qui devient dès lors directement exécutable par le processeur de l’appareil. On retrouve ici les avantages du langage intermédiaire, qui n’a rien de spécifique à Java (Microsoft utilise un modèle équivalent pour .NET), mais les applications sont en revanche plus lentes à démarrer et certains soucis de performances peuvent voir le jour.

« Dalvik is dead, long live Dalvik! » 

Ce problème de performances des applications Android est un vieux sujet, et Google travaille sur la question depuis un certain temps. Mais au cours de la nuit de mercredi à jeudi, un changement très important a été réalisé par la firme dans la branche principale de développement d’AOSP (Android Open Source Project). Deux « commits », numérotés 98553 et 98618, changent en effet la donne. Comme le signale XDA-Developers, le premier supprime Dalvik tandis que le second proclame ART comme machine virtuelle par défaut.

 

ART, pour Android Runtime, n’est pas nouveau. Il est en fait en test depuis l’année dernière et il était tout à fait possible de l’utiliser via les options dédiées aux développeurs. Cependant, son fonctionnement rendait une bonne partie des applications tierces instables à cause d’un fonctionnement très différent. Mais l’objectif global est bien l’amélioration des performances. Explications.

Google veut améliorer les performances des applications 

Le plus gros changement introduit par ART est la compilation dite AOT, pour « Ahead-Of-time » (là encore, comme Microsoft procèdera bientôt avec .NET). Si la compilation JIT s’occupe de transcrire à la volée, AOT s’en occupe « avant ». Plus précisément, le code intermédiaire va être compilé dès sa récupération depuis Google Play pour réellement « installer » l’application, qui sera enregistrée telle quelle dans le téléphone, en code natif. Son lancement sera donc beaucoup plus rapide car le code ne sera pas recompilé à chaque exécution. Du moins en théorie.

 

Parmi les autres changements, ART fournit également un « garbage collector » (ramasse-miettes) amélioré. Dans sa documentation technique, Google explique en effet que celui-ci a souvent un impact sur les performances. Dans ART, plusieurs aspects ont été optimisés et une fonction de compactage doit arriver plus tard. Toujours pour les développeurs, Android Runtime propose également de nouvelles fonctionnalités pour le débogage ainsi que des outils d’analyse spécifiques, notamment pour la gestion des exceptions et des crashs.

Les travaux ne sont pas terminés

Dans la pratique, de nombreux problèmes devront être résolus. Il existe en effet une différence de taille entre proposer une machine virtuelle non finalisée aux développeurs et l’utiliser en standard pour tous les utilisateurs. Car le remplacement de Dalvik par ART va directement impacter les constructeurs qui devront procéder à de nombreux réglages dans les ROM fournies avec les smartphones et tablettes. À travers les discussions des testeurs, on trouve assez facilement des constats de soucis de ce type.

 

Mais les constructeurs ne seront pas les seuls à devoir s’adapter. Les applications tierces vont devoir elles aussi procéder à des changements. Les développeurs ont cependant déjà adapté une bonne partie d’entre elles et les utilisateurs ne devraient pas rencontrer de difficultés majeures lorsqu’ART entrera effectivement en piste. On peut d’ailleurs déjà vérifier si les applications que l’on utilise sont compatibles via un site dédié.

 

Mais justement, quand cette arrivée est-elle prévue ? La réponse devrait en fait arriver la semaine prochaine durant la Google I/O. La firme va sans doute procéder à de nombreuses annonces, les rumeurs de renouvellement visuel étant particulièrement nombreuses. Elle pourrait d'ailleurs présenter Android 5.0, dont ART serait alors l’une des nouveautés majeures puisque mettant l’accent sur les performances, voire à terme une amélioration de l’autonomie.

87

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Des applications compilées jusqu'ici à la volée 

« Dalvik is dead, long live Dalvik! » 

Google veut améliorer les performances des applications 

Les travaux ne sont pas terminés

Commentaires (87)


Ya une coquille : ça se dit pas “long live to “, on dit “long live ”

Comme dans “The king is dead, long live the king!” ou même dans le screenshot de merge dans la news : « Dalvik is dead, long live Dalvik! »








karim.s a écrit :



Ya une coquille : ça se dit pas “long live to “, on dit “long live ”

Comme dans “The king is dead, long live the king!” ou même dans le screenshot de merge dans la news : « Dalvik is dead, long live Dalvik! »







Y a un bouton “Signaler” en bas de la news <img data-src=" />



Bon, gungho devrait se grouiller car puzzle & dragons marche pas avec ART :(









Tetedeiench a écrit :



Y a un bouton “Signaler” en bas de la news <img data-src=" />



Bon, gungho devrait se grouiller car puzzle & dragons marche pas avec ART :(







C’est déjà corrigé en fait <img data-src=" />









Tetedeiench a écrit :



Y a un bouton “Signaler” en bas de la news <img data-src=" />



Bon, gungho devrait se grouiller car puzzle & dragons marche pas avec ART :(





Ya une version traduite en anglais ou français de puzzle & dragons?!





Son lancement sera donc beaucoup plus rapide car le code ne sera pas recompilé à chaque exécution. Du moins en théorie.





Dans la pratique, y’a quand même peu de chance qu’il n’y ai pas d’amélioration si ? (Même si elles ne sont pas perceptible)




Cependant, son fonctionnement rendait une bonne partie des applications tierces instables à cause d’un fonctionnement très différent.





Là pour le coup, l’article est carrément faux. J’ai activé ART assez rapidement et je n’ai pas constaté de problèmes sur les applications tierces (je dois en avoir une bonne 40aine d’installées). J’ai bien eu quelques plantages d’applis mais impossible de savoir qu’elle en était la raison.



Bref, ART n’a pas rendue la majorité des applications tierces instables, c’est faux.








Virtual_Spirit a écrit :



Dans la pratique, y’a quand même peu de chance qu’il n’y ai pas d’amélioration si ? (Même si elles ne sont pas perceptible)







Ca a eu un effet positif notamment sur la batterie. Le gain se fait au moment de l’ouverture de l’appli. Si ton téléphone est rapide, effectivement ca ne sent pas énormément.









flagos_ a écrit :



Là pour le coup, l’article est carrément faux. J’ai activé ART assez rapidement et je n’ai pas constaté de problèmes sur les applications tierces (je dois en avoir une bonne 40aine d’installées). J’ai bien eu quelques plantages d’applis mais impossible de savoir qu’elle en était la raison.



Bref, ART n’a pas rendue la majorité des applications tierces instables, c’est faux.







ha, le fameux : ça marche pour moi, il n’y a donc aucun problème





  1. une bonne partie != la majorité



  2. les applis que tu utilises != la majorité des applis



Dans Windows Phone et iOS, comment ça se passe ? Histoire d’avoir un léger point de comparaison si possible :)



Et d’ailleurs, en quel langage est programmé une application WP et iOS ? Histoire d’arrêter la comparaison directement <img data-src=" />








karim.s a écrit :



Ya une version traduite en anglais ou français de puzzle & dragons?!







Anglaise, accessible sur le store android anglais uniquement. Après, y a moyen de l’avoir par d’autres biais, mais ce ne sera ni ici, ni avec moi <img data-src=" />









Depy1501 a écrit :



Dans Windows Phone et iOS, comment ça se passe ? Histoire d’avoir un léger point de comparaison si possible :)



Et d’ailleurs, en quel langage est programmé une application WP et iOS ? Histoire d’arrêter la comparaison directement <img data-src=" />





iOS : Objective-C

WP : C-Sharp me semble



Android : Java, ca veut tout dire <img data-src=" />









Tetedeiench a écrit :



Anglaise, accessible sur le store android anglais uniquement. Après, y a moyen de l’avoir par d’autres biais, mais ce ne sera ni ici, ni avec moi <img data-src=" />





Thx !









athlon64 a écrit :



iOS : Objective-C

WP : C-Sharp me semble



Android : Java, ca veut tout dire <img data-src=" />





C’est ce que j’avais comme idée en effet, merci !



C’est clair que Java est peut être plus complexe à gérer que le reste, outre les performances.



les applis IOS sont natives, avec certaines améliorations du code managé (garabage collector).

Sous win8, le fonctionnement est semblable à Dalvik, mais en .NET. Avec Roslyn, on aura la même chose qu’ART : le code intermédiaire sera précompilé.



Le grand perdant dans tout ça, ce sont les applis html/javascript, mais ils ont droit à leur propre améliorations via le navigateur embarqué.








athlon64 a écrit :



iOS : Objective-C

WP : C-Sharp me semble



Android : Java, ca veut tout dire <img data-src=" />







Désolé de manquer de culture, mais je ne comprends pas la raison.









Depy1501 a écrit :



C’est ce que j’avais comme idée en effet, merci !



C’est clair que Java est peut être plus complexe à gérer que le reste, outre les performances.





Sur Android, tu peux faire un peu de C++, mais vu que Java est peut etre plus simple a prendre en main (je connais pas C++ pour savoir si c’est plus dur que Java ou non), les dev utilisent Java. Deja que sur PC j’aime pas Java pour ses perfs (et qu’Oracle pètent les co*illes) alors sur un téléphone, c’est pas du tout adapté, devraient forcer l’utilisation d’un langage plus bas niveau



Mwais, l’AOT va être intéressant, mais à condition d’avoir des devices avec deux fois plus de flash intégrée qu’actuellement car il faudra à chaque fois stocker les binaires et en byte code et en code natif…








metaphore54 a écrit :



Désolé de manquer de culture, mais je ne comprends pas la raison.





Java c’est bien c’est multiplateforme, assez facilement compréhensible et avec une syntaxe et un typage qui te force a faire des trucs a peu près propre. Sauf que ca tourne avec une Machine Virtuelle, ce qui rend son éxécution lourde.



Tu as le C++ qui est un langage bas niveau (plus proche du matériel) et tu as Java qui est un langage haut niveau qui a donc besoin d’une VM pour mettre les instructions en bas niveau. Le problème c’est que sur un PC, c’est pas trop gênant (moins du moins, par exemple LibreOffice sur un Core2Duo je trouve que ca galère, par contre une fois Java désactivé la ca va mieux), mais sur un téléphone, malgré la puissance actuelle, c’est pas le mieux. C’est en parti pour ca qu’un iPhone avec seulement 2 coeur et 1Go est aussi réactif qu’un Android 4 coeur et 2Go de RAM.



Par contre, sur les VM, Microsoft semble très bon vu la fluidité de WP



Oui je déteste Java <img data-src=" />



“Les développeurs ont cependant déjà adapté une bonne partie d’entre elles et les utilisateurs ne devraient pas rencontrer de difficultés majeures lorsqu’ART entrera effectivement en piste”



On verra bien quelque mois après la conférence <img data-src=" />








Depy1501 a écrit :



Dans Windows Phone et iOS, comment ça se passe ? Histoire d’avoir un léger point de comparaison si possible :)



Et d’ailleurs, en quel langage est programmé une application WP et iOS ? Histoire d’arrêter la comparaison directement <img data-src=" />







Pour iOS (et je présume WP, mais j’ai un doute…) le code est compilé pour la plateforme. la plateforme évoluant rarement, ( on reste globalement sur une génération de CPU ARM cohérente), le téléphone prend ce code compilé, et l’exploite



Android a été conçu dans l’idée que la plateforme matériel n’est pas stable, et donc se base sur du Java, ( un code haut niveau), qui est associé a une machine virtuelle ( Dalvik), qui fait l’effort de conversion pour la plateforme ( x86, MIPS, ARM, ARM 64 etc). Depuis android 2.2, Dalvik compile à l’exécution (appellé “Juste à temps”) l’application, pour ne pas avoir a passer son temps a convertir java &gt; binaire.

l’idée à la base de ART, est de conserver la conversion java &gt; binaire ( parceque android fonctionne vraiment sur x86, MIPS, ARM, et que le market ne sait pas ce qu’il a besoin de réaliser comme conversion quand il t’envoi le paquet ), mais de faire la conversion dés que tu as fini de télécharger l’application sur ton téléphone.



Ca prend plus de place en flash, parcequ’android est obligé de garder le code java à coté du code qu’il a compilé, comme ca, si lors d’une MaJ, ART est modifié, il vas refaire la compilation des programmes sur ton téléphone









athlon64 a écrit :



Java c’est bien c’est multiplateforme, assez facilement compréhensible et avec une syntaxe et un typage qui te force a faire des trucs a peu près propre. Sauf que ca tourne avec une Machine Virtuelle, ce qui rend son éxécution lourde.



Tu as le C++ qui est un langage bas niveau (plus proche du matériel) et tu as Java qui est un langage haut niveau qui a donc besoin d’une VM pour mettre les instructions en bas niveau. Le problème c’est que sur un PC, c’est pas trop gênant (moins du moins, par exemple LibreOffice sur un Core2Duo je trouve que ca galère, par contre une fois Java désactivé la ca va mieux), mais sur un téléphone, malgré la puissance actuelle, c’est pas le mieux. C’est en parti pour ca qu’un iPhone avec seulement 2 coeur et 1Go est aussi réactif qu’un Android 4 coeur et 2Go de RAM.



Par contre, sur les VM, Microsoft semble très bon vu la fluidité de WP



Oui je déteste Java <img data-src=" />





J’ai la même aversion pour le JAVA… <img data-src=" /> !



Par contre, je n’ai jamais testé LibreOffice avec ou sans JAVA, qu’est ce que ça change ?









Depy1501 a écrit :



J’ai la même aversion pour le JAVA… <img data-src=" /> !



Par contre, je n’ai jamais testé LibreOffice avec ou sans JAVA, qu’est ce que ça change ?





J’aime pas Java mais pas pour autant que je fais du bas niveau <img data-src=" />



Sans Java certaines fonctionnalités ne sont pas dispo, elles sont encore en dev pour se passer de java. Mais tout le reste fonctionne parfaitement et tu gagnes en performance vu que c’est du natif <img data-src=" /> (c’était l’un des points noir de LibreOffice pour moi, de devoir absolument utiliser Java, merci Oracle et leur OpenOffice)









canti a écrit :



Pour iOS (et je présume WP, mais j’ai un doute…) le code est compilé pour la plateforme. la plateforme évoluant rarement, ( on reste globalement sur une génération de CPU ARM cohérente), le téléphone prend ce code compilé, et l’exploite



Android a été conçu dans l’idée que la plateforme matériel n’est pas stable, et donc se base sur du Java, ( un code haut niveau), qui est associé a une machine virtuelle ( Dalvik), qui fait l’effort de conversion pour la plateforme ( x86, MIPS, ARM, ARM 64 etc). Depuis android 2.2, Dalvik compile à l’exécution (appellé “Juste à temps”) l’application, pour ne pas avoir a passer son temps a convertir java &gt; binaire.

l’idée à la base de ART, est de conserver la conversion java &gt; binaire ( parceque android fonctionne vraiment sur x86, MIPS, ARM, et que le market ne sait pas ce qu’il a besoin de réaliser comme conversion quand il t’envoi le paquet ), mais de faire la conversion dés que tu as fini de télécharger l’application sur ton téléphone.



Ça prend plus de place en flash, parcequ’android est obligé de garder le code java à coté du code qu’il a compilé, comme ca, si lors d’une MaJ, ART est modifié, il vas refaire la compilation des programmes sur ton téléphone





J’avoue que je préfère cette solution, sans pour autant avoir une idée du stockage qu’il va falloir débloquer en plus.



En espérant que ce ne soit pas trop gros et que les constructeurs ne pourrissent pas tout en omettant les slots SD puisqu’on va devoir faire avec…









athlon64 a écrit :



. Le problème c’est que sur un PC, c’est pas trop gênant (moins du moins, par exemple LibreOffice sur un Core2Duo je trouve que ca galère, par contre une fois Java désactivé la ca va mieux), mais sur un téléphone, malgré la puissance actuelle, c’est pas le mieux. C’est en parti pour ca qu’un iPhone avec seulement 2 coeur et 1Go est aussi réactif qu’un Android 4 coeur et 2Go de RAM.







Avec la compilation JIT, ce n’est pas vraiment le cas, le java se retrouve avec des perfomances pas dégeu face au natif. Les problèmes de “freeze” sur android sont plus dues a des ennuis de garbage collector, que d’un manque de souffle de java..



tu remarqueras d’ailleur que dans les bench, le SoC apple est plus performant que les SoC android







athlon64 a écrit :



Par contre, sur les VM, Microsoft semble très bon vu la fluidité de WP







La fluidité de WP est dues a une différence d’optimisation : Si sur android une liste n’a pas la donnée dont elle a besoin, elle aura tendance a freezer ( que ca soit à cause de l’attente d’une donnée, d’un code mal optimisé, ou par le garbage collector qui bloque)

sous WP, la liste sera affiché vide, et se remplira quand la donnée sera arrivé, ce qui donne un resultat très fluide



je suis sous ART avec mon nexus 5 et j’ai gagné 10% d’autonomie en gros.

le switch entre les applications et plus rapide. par contre les applis prennent plus de place et après un wipe dalvik la creation du cache est hyper longue (30-1min en dalvik et 15 min avec ART)








Depy1501 a écrit :



J’avoue que je préfère cette solution, sans pour autant avoir une idée du stockage qu’il va falloir débloquer en plus.



En espérant que ce ne soit pas trop gros et que les constructeurs ne pourrissent pas tout en omettant les slots SD puisqu’on va devoir faire avec…







La différence de taille ne sera pas conséquente, vu qui prend le plus de place dans une application sont les ressources ( images, textures etc…), et qu’elle ne sont - si j’ai bien compris - pas dupliqués.



Dans le pire des cas il pourrait y avoir un doublement de l’espace pris par les applications, mais je pense que dans la pratique c’est moins…

EDIT: ce site semble parler de 10% d’espace disque pris en plus, et ca me semblerais cohérent, à tester dans la verson finale









canti a écrit :



Avec la compilation JIT, ce n’est pas vraiment le cas, le java se retrouve avec des perfomances pas dégeu face au natif. Les problèmes de “freeze” sur android sont plus dues a des ennuis de garbage collector, que d’un manque de souffle de java..



tu remarqueras d’ailleur que dans les bench, le SoC apple est plus performant que les SoC android





Meme en étant plus performant, Android nécessite quand meme un char d’assault par rapport aux deux autres <img data-src=" />



Quand je parle de Java j’englobe aussi la machine virtuelle, et les problèmes de perf, même du au garbage collector sont quand meme problématiques. L’utilisation d’un langage plus bas niveau, un peu chiant pour les différents matos dispo je le reconnais, a l’avantage sur les perf. Et je peux constater des problèmes de performances sur un Core2Duo, je pense donc que même sur un ARM ca peut poser des problèmes. L’avantage de Java c’est d’être multiplateforme, mais au final c’est aussi un inconvénient







canti a écrit :



La fluidité de WP est dues a une différence d’optimisation : Si sur android une liste n’a pas la donnée dont elle a besoin, elle aura tendance a freezer ( que ca soit à cause de l’attente d’une donnée, d’un code mal optimisé, ou par le garbage collector qui bloque)

sous WP, la liste sera affiché vide, et se remplira quand la donnée sera arrivé, ce qui donne un resultat très fluide





Ca peut expliquer en partie l’impression de fluidité, mais il ne doit pas y avoir que ca. Le même téléphone, l’un sous Android l’autre sous WP, le second sera plus fluide



Toujours pas d’interpréteur Python pré-installé…



<img data-src=" />








Tetedeiench a écrit :



Y a un bouton “Signaler” en bas de la news <img data-src=" />



Bon, gungho devrait se grouiller car puzzle & dragons marche pas avec ART :(





Pour le coup, pour une fois je trouvais ça instructif :p donc le bouton signaler n’était pas nécessaire!









athlon64 a écrit :



Ca peut expliquer en partie l’impression de fluidité, mais il ne doit pas y avoir que ca. Le même téléphone, l’un sous Android l’autre sous WP, le second sera plus fluide





Pas en partie c’est juste une évidence quand on a pratiqué les deux OS.



Prend un vieux Omnia 7, il donne une impression de fluidité équivalente, voir supérieure, à un SGS5…mais les données mettent du temps à s’affiche (c’est particulièrement visible dans le navigateur).<img data-src=" />









Alucard63 a écrit :



Pas en partie c’est juste une évidence quand on a pratiqué les deux OS.



Prend un vieux Omnia 7, il donne une impression de fluidité équivalente, voir supérieure, à un SGS5…mais les données mettent du temps à s’affiche (c’est particulièrement visible dans le navigateur).<img data-src=" />





Sur l’impression de fluidité, mais sur les performances réelles, ca en est quoi ?



<img data-src=" />









athlon64 a écrit :



Sur l’impression de fluidité, mais sur les performances réelles, ca en est quoi ?



<img data-src=" />





Oui sur les perfs réelles c’est pénalisant les VM. Mais j’aurai tendance à dire que le problème principal d’android pour la fluidité perçue reste avant tout ce que j’ai décrit.<img data-src=" />









Alucard63 a écrit :



Oui sur les perfs réelles c’est pénalisant aussi. Mais j’aurai tendance à dire que le problème principal d’android pour la fluidité perçue reste avant tout ce que j’ai décrit.<img data-src=" />





<img data-src=" /> merci. Bien ce que je pensais, Java c’est le mal <img data-src=" />



Le problème d’Android, c’est qu’il faut un bon téléphone pour qu’il tourne correctement, une bonne partie des téléphones n’ont pas beaucoup de puissance, donc ca rame, donc Android a mauvaise réputation. Si Google pouvait pousser a autre chose ca serait bien <img data-src=" />









athlon64 a écrit :



<img data-src=" /> merci. Bien ce que je pensais, Java c’est le mal <img data-src=" />



Le problème d’Android, c’est qu’il faut un bon téléphone pour qu’il tourne correctement, une bonne partie des téléphones n’ont pas beaucoup de puissance, donc ca rame, donc Android a mauvaise réputation. Si Google pouvait pousser a autre chose ca serait bien <img data-src=" />





Pas sur que ce soit principalement à cause de la VM.



Pour le coup je ne pense pas que le C#/.NET du MS soit du code natif pour WP (C# c’est un peu le Java de MS…)…or WP s’en sort pas trop mal en terme de fluidité perçue.



Tu vois ce que je veux dire?









Alucard63 a écrit :



Pas sur que ce soit principalement à cause de la VM.



Pour le coup je ne pense pas que le C#/.NET du MS soit du code natif pour WP (C# c’est un peu le Java de MS…)…or WP s’en sort pas trop mal en terme de fluidité perçue.



Tu vois ce que je veux dire?





Non pas trop <img data-src=" />



Si c’est juste sur la perception de fluidité, alors c’est la logique du code, si c’est une meilleure fluidité grace au perf du langage ou de la VM, alors MS est meilleur qu’Oracle (<img data-src=" /> : ca serait pas dur en même temps)



Pour avoir testé ART sur CyanogenMod 11 (android 4.4.3), le principal soucis que j’ai eu sur mon Xperia Arc S, c’est que… bon dieu, ca bouffe la RAM à vitesse grand V ! Du coup, j’ai dû revenir à Dalvik pour que mes applications habituelles puissent toutes être installées et fonctionner sur 512 Mo (curieusement, une config qui devrait convenir à KK) !


Est ce qu’un galaxy S5, pourras faire les MAJ nécéssaires pour accueillir ces nouveautés ou bien est-ce qu’il faudra le mettre à la poubelle et changer de smartphone?



Je veux dire ça me semble être de gros changements en perspective, et annoncer cela comme ça, faut que les utilisateurs d’Androïd sachent à quoi s’attendre.



A moins qu’ils ne soient déjà habitués.











<img data-src=" /><img data-src=" />








athlon64 a écrit :



Non pas trop <img data-src=" />



Si c’est juste sur la perception de fluidité, alors c’est la logique du code, si c’est une meilleure fluidité grace au perf du langage ou de la VM, alors MS est meilleur qu’Oracle (<img data-src=" /> : ca serait pas dur en même temps)





Ce qui importe ce n’est pas la vitesse d’exécution sur un smartphone. Sinon les premiers iphones auraient été considérés comme très très lents.



Ce qui compte c’est la fluidité perçue. <img data-src=" />



Si WP7 qui utilise lui aussi une VM est considéré par un utilisateur comme fluide (même avec un vieux matériel); ça veut dire que le problème “Android n’est pas fluide” ne vient pas principalement du fait d’utiliser une VM.



C’est une simple démonstration par l’absurde:

Ta proposition est: le manque de fluidité remonté par les utilisateurs d’Android vient forcément de la VM.



Je te donne un contre exemple avec WP: qui utilise une VM, mais est considéré comme fluide par les utilisateurs.





Hence ==&gt; n’accusons pas trop vite la VM.



CQFD









after_burner a écrit :



Est ce qu’un galaxy S5, pourras faire les MAJ nécéssaires pour accueillir ces nouveautés ou bien est-ce qu’il faudra le mettre à la poubelle et changer de smartphone?



Je veux dire ça me semble être de gros changements en perspective, et annoncer cela comme ça, faut que les utilisateurs d’Androïd sachent à quoi s’attendre.



A moins qu’ils ne soient déjà habitués.



<img data-src=" /><img data-src=" />







Normalement tout sera transparent. l’install de l’update sera juste un peu longue, mais pas de raison que l’utilisateur voit une différence particulière.









Alucard63 a écrit :



Ce qui importe ce n’est pas la vitesse d’exécution sur un smartphone. Sinon les premiers iphones auraient été considérés comme très très lents.



Ce qui compte c’est la fluidité perçue. <img data-src=" />



Si WP7 qui utilise lui aussi une VM est considéré par un utilisateur comme fluide même avec un vieux matériel; ça veut dire que le problème “Android n’est pas fluide” ne vient pas principalement du fait d’utiliser une VM.CQFD





<img data-src=" /> merci je comprends mieux. C’est une addition de plusieurs facteurs. Un langage qui est réfléchi d’une manière différente, un garbage collector qui a du mal et l’obligation d’une VM (le summum de la fluidité restant pour iOS).









after_burner a écrit :



Est ce qu’un galaxy S5, pourras faire les MAJ nécéssaires pour accueillir ces nouveautés ou bien est-ce qu’il faudra le mettre à la poubelle et changer de smartphone?



Je veux dire ça me semble être de gros changements en perspective, et annoncer cela comme ça, faut que les utilisateurs d’Androïd sachent à quoi s’attendre.







sur le haut de gamme, Samsung est “ Assez sérieux”, et même si ils sont pas les plus rapide à mettre à jour, ils font des MaJ sur 1518 mois.



Il y a donc de TRES bonnes chances d’avoir le prochain android sur GS5 - et en tout cas, rien ne l’empèchera physiquement de le faire









athlon64 a écrit :



<img data-src=" /> merci je comprends mieux. C’est une addition de plusieurs facteurs. Un langage qui est réfléchi d’une manière différente, un garbage collector qui a du mal et l’obligation d’une VM (le summum de la fluidité restant pour iOS).







Il y a aussi le modèle de dev Windows Phone largement plus contraignant qui limite les risque de faire des bétises …



Par exemple les acces disque sont obligatoirement threadé, grosses limitations sur les executions en background, affichage listes & co automatiquement threadé …



En gros les bonnes pratiques sont “imposés” aux dev <img data-src=" />









atomusk a écrit :



Il y a aussi le modèle de dev Windows Phone largement plus contraignant qui limite les risque de faire des bétises …



Par exemple les acces disque sont obligatoirement threadé, grosses limitations sur les executions en background, affichage listes & co automatiquement threadé …



En gros les bonnes pratiques sont “imposés” aux dev <img data-src=" />





<img data-src=" /> c’est pas plus mal au final, bien que ca peut en rebuter certains. C’est pas juste le changement du Dalvik pour ART qui changera beaucoup la donne









athlon64 a écrit :



<img data-src=" /> c’est pas plus mal au final, bien que ca peut en rebuter certains. C’est pas juste le changement du Dalvik pour ART qui changera beaucoup la donne







On verra bien ce qui sera annoncé au IO …

Les annonces sur l’unification de l’interface pourraient être un premier pas dans ce sens.









after_burner a écrit :



Est ce qu’un galaxy S5, pourras faire les MAJ nécéssaires pour accueillir ces nouveautés ou bien est-ce qu’il faudra le mettre à la poubelle et changer de smartphone?

<img data-src=" /><img data-src=" />







Faudra attendre d’abord que ça rendre dans une release officielle d’android, ensuite, il faudra attendre que Samsung décide si oui ou non il va faire une release pour le S5, et enfin, avec un peu de chance, six mois après la release officielle de Google, la release officielle de Samsung suivra…









ragoutoutou a écrit :



Faudra attendre d’abord que ça rendre dans une release officielle d’android, ensuite, il faudra attendre que Samsung décide si oui ou non il va faire une release pour le S5, et enfin, avec un peu de chance, six mois après la release officielle de Google, la release officielle de Samsung suivra…sauf que ca fera 15-18 mois que le SGS 5 est sorti et donc pas de MAJ





<img data-src=" />



<img data-src=" /> Je viens pinailler un peu, mais bon.

La phrase “Dalvik is dead, long live Dalvik” est une erreur grossière.



Cette phrase vient du célèbre “Le Roi est mort, vive le Roi” sauf que dans cette phrase, la première partie “le Roi est mort” indique que le roi vient de mourir (<img data-src=" /> non sans blague ?!) et “vive le Roi” est une phrase destinée au roi qui lui succède.



Sauf que cette phrase toute faite a un peu perdu de son sens…



Ici ce serait Dalvik est mort, vive ART par exemple.








athlon64 a écrit :



<img data-src=" />







Anéfé, mais je voulais pas avoir l’air pessimiste…



Même en y mettant le prix, le support ne suit pas chez Samsung.









ragoutoutou a écrit :



Anéfé, mais je voulais pas avoir l’air pessimiste…



Même en y mettant le prix, le support ne suit pas chez Samsungles constructeurs.





<img data-src=" /> <img data-src=" />



les pessimistes sont juste réalistes <img data-src=" />









Ler van keeg a écrit :



<img data-src=" /> Je viens pinailler un peu, mais bon.

La phrase “Dalvik is dead, long live Dalvik” est une erreur grossière.



Cette phrase vient du célèbre “Le Roi est mort, vive le Roi” sauf que dans cette phrase, la première partie “le Roi est mort” indique que le roi vient de mourir (<img data-src=" /> non sans blague ?!) et “vive le Roi” est une phrase destinée au roi qui lui succède.



Sauf que cette phrase toute faite a un peu perdu de son sens…



Ici ce serait Dalvik est mort, vive ART par exemple.







ça veut peut-être dire qu’ils font juste une mise à jour de Dalvik. Je trouve que ça tourne déjà particulièrement bien.









athlon64 a écrit :



<img data-src=" /> <img data-src=" />



les pessimistes sont juste réalistes pas toujours capables d’identifier les points positifs <img data-src=" />







Ben techniquement, il y a les nexus, donc on ne peut pas mettre tous les contructeurs dans le même panier… <img data-src=" /> Il y a des périphériques sous android qui ont un suivi convenable… pas des masses, mais il y en a.









athlon64 a écrit :



Sur Android, tu peux faire un peu de C++, mais vu que Java est peut etre plus simple a prendre en main (je connais pas C++ pour savoir si c’est plus dur que Java ou non), les dev utilisent Java. Deja que sur PC j’aime pas Java pour ses perfs (et qu’Oracle pètent les co*illes) alors sur un téléphone, c’est pas du tout adapté, devraient forcer l’utilisation d’un langage plus bas niveau







Faut arrêter avec ca….

Et avant de crier au scandale je suis dev c#….

C# a ete créé par ms pour attirer les dev java et c’est pour ca que les 2 se ressemblent tant meme si au fil des années ils se séparent de plus en plus



Pour les performances franchement dire que les tels ne le supportent pas c’est n’importe quoi. Ensuite sur Android oui c’est java, la syntaxe mais les compilos derrière mais surtout la VM c’est celle de google.



Je ne sais pas depuis combien de temps tu codes, tu me donnes l’impression de débuter voir d’être étudiants et rempli de fausses idées mais si je fais comme toi, je te dirai que le c++ c’est du haut niveau et que seul le C pourrait etre presque considéré comme assez bas niveau. … sinon c’est l’assembleur.



Et sur Android ca fait longtemps que les applications sont fluides, il faut aussi parler de choses qu’on connaît. Merci









atomusk a écrit :



Normalement tout sera transparent. l’install de l’update sera juste un peu longue, mais pas de raison que l’utilisateur voit une différence particulière.









canti a écrit :



sur le haut de gamme, Samsung est “ Assez sérieux”, et même si ils sont pas les plus rapide à mettre à jour, ils font des MaJ sur 1518 mois.



Il y a donc de TRES bonnes chances d’avoir le prochain android sur GS5 - et en tout cas, rien ne l’empèchera physiquement de le faire







Physiquement non, mais je crois qu’il y a déjà eu des abandons de support pour bien moins que des changements type ART. C’était peut des cas ou 1ans et demi représentait trop pour eux.







ragoutoutou a écrit :



Faudra attendre d’abord que ça rendre dans une release officielle d’android, ensuite, il faudra attendre que Samsung décide si oui ou non il va faire une release pour le S5, et enfin, avec un peu de chance, six mois après la release officielle de Google, la release officielle de Samsung suivra…







Ça va dépendre en premier lieux de la date de disponibilité d’androïd 5, c’est vrai.



Oh les belles tentatives de piratage sur http://www.androidruntime.com/list <img data-src=" />





insert into mysql.user (user, host, password) values (‘name’, ‘localhost’, password(‘pass123’))








after_burner a écrit :



Physiquement non, mais je crois qu’il y a déjà eu des abandons de support pour bien moins que des changements type ART. C’était peut des cas ou 1ans et demi représentait trop pour eux.







Ça va dépendre en premier lieux de la date de disponibilité d’androïd 5, c’est vrai.











Non mais ART est déjà supporté par tous les téléphones sous Android 4.4.

Options de dev, tu remplaces dalvik par art.









cant[quote:5065441:canti a écrit :



sur le haut de gamme, Samsung est “ Assez sérieux”, et même si ils sont pas les plus rapide à mettre à jour, ils font des MaJ sur 1518 mois.



Il y a donc de TRES bonnes chances d’avoir le prochain android sur GS5 - et en tout cas, rien ne l’empèchera physiquement de le faire







Il n’y a pas que ça qui ralenti android, c’est dans la conception même de l’os. La façon dont android charge les éléments affichés par exemple,la gestion des ressources , et l’accélération matérielle qui n’est toujours pas au point selon moi.

C’est dans la conception même de l’os so 2000 qui fait que la plateforme pêche de temps en temps. Mais les beaux diables de google bossent comme des bêtes donc je ne m’inquiète pas pour eux. Le mieux serait de repartir sur des bases saines et faire un android “ plus clean “









nost4r a écrit :



Non mais ART est déjà supporté par tous les téléphones sous Android 4.4.

Options de dev, tu remplaces dalvik par art.







Combien de smartphone tourne sou 4.4 ? ; 5% du parc ?



Pas de souçis pour y passer sur mon nexus 5.



Par contre sur ma tablette LG, avec leur rom à la con, je suis obligé d’utiliser le framework xposed, non compatibe ART….


Pour ceux qui veulent tester ART et qui ont Android 4.4.x il faut cliquer 7 fois sur le numéro de build dans la partie “à propos” des paramètres. Dès lors un nouveau menu développeur sera présent et parlera entre autres de ART…





Aloryen a écrit :



les applis IOS sont natives, avec certaines améliorations du code managé (garabage collector).

Sous win8, le fonctionnement est semblable à Dalvik, mais en .NET. Avec Roslyn, on aura la même chose qu’ART : le code intermédiaire sera précompilé.



Le grand perdant dans tout ça, ce sont les applis html/javascript, mais ils ont droit à leur propre améliorations via le navigateur embarqué.





Pas Roslyn mais le projet N aujourd’hui renommée en .Net nativehttp://www.nextinpact.com/news/86865-microsoft-donne-serieux-coup-daccelerateur-…









athlon64 a écrit :



Java c’est bien c’est multiplateforme, assez facilement compréhensible et avec une syntaxe et un typage qui te force a faire des trucs a peu près propre. Sauf que ca tourne avec une Machine Virtuelle, ce qui rend son éxécution lourde.



Tu as le C++ qui est un langage bas niveau (plus proche du matériel) et tu as Java qui est un langage haut niveau qui a donc besoin d’une VM pour mettre les instructions en bas niveau. Le problème c’est que sur un PC, c’est pas trop gênant (moins du moins, par exemple LibreOffice sur un Core2Duo je trouve que ca galère, par contre une fois Java désactivé la ca va mieux), mais sur un téléphone, malgré la puissance actuelle, c’est pas le mieux. C’est en parti pour ca qu’un iPhone avec seulement 2 coeur et 1Go est aussi réactif qu’un Android 4 coeur et 2Go de RAM.



Par contre, sur les VM, Microsoft semble très bon vu la fluidité de WP



Oui je déteste Java <img data-src=" />







Le haut niveau n’a rien à voir avec le besoin d’une VM et C++ n’est pas un langage bas niveau, c’est un langage de haut niveau (surtout dans sa dernière version) qui peut descendre dans le bas niveau. Comparer C++ et Java alors que tu ne connais pas le premier c’est osé <img data-src=" />






si les appli sont compilé a l’execution, c’est quoi la phase qui passe en revu les appli lors d’une maj ou du vidage du cache dalvik ?


A la decharge d’android et sa soit disant lenteur, ya aussui un parametre enorme a prendre en compte: les surcouches constructeurs qui bouffent du temps CPU, de la RAM et de l’autonomie. Mon nexus 5 est beaucoup plus reactif qu’un Samsung S5 avec Touchwiz alors que le hardware est largement inferieur…


Je suis le seul que ça choque d’avoir un gros “DO NOT MERGE” écrit dans la change list qui est maintenant “MERGED” ? <img data-src=" />








juntawflo a écrit :



Combien de smartphone tourne sou 4.4 ? ; 5% du parc ?







13%



https://developer.android.com/about/dashboards/index.html









ArthurG a écrit :



A la decharge d’android et sa soit disant lenteur, ya aussui un parametre enorme a prendre en compte: les surcouches constructeurs qui bouffent du temps CPU, de la RAM et de l’autonomie. Mon nexus 5 est beaucoup plus reactif qu’un Samsung S5 avec Touchwiz alors que le hardware est largement inferieur…





les surcouches sont en effet une des causes de ce manque de fluidité mais il y a bien un problème architectural d’android :

http://www.nextinpact.com/news/67505-android-performances-interface-fluidite-deb…









arno53 a écrit :



les surcouches sont en effet une des causes de ce manque de fluidité mais il y a bien un problème architectural d’android :

http://www.nextinpact.com/news/67505-android-performances-interface-fluidite-deb…





Publiée le 07/12/2011 à 18:11 <img data-src=" />









frikakwa a écrit :



Publiée le 07/12/2011 à 18:11 <img data-src=" />





Oui ça date mais la situation reste la même… Android 4.1 et 4.4 ont certes amélioré les choses notamment avec le projet Butter mais le problème de priorisation reste présent









arno53 a écrit :



[quote:5065884:frikakwa]

Publiée le 07/12/2011 à 18:11 <img data-src=" />





Oui ça date mais la situation reste la même… Android 4.1 et 4.4 ont certes amélioré les choses notamment avec le projet Butter mais le problème de priorisation reste présent [/quote]

Autant pour moi: je pensais que ces soucis avaient effectivement été réglés avec le project Butter!

Cela laisse encore une belle marge de progression à Android du coup… parce que pour avoir commencé sous Donut (1.6) et avoir vu défiler les différentes versions depuis; je trouve qu’il y a un monde de différence et une belle évolution au niveau fluidité et réactivité du système! Le tout en version AOSP sans surcouche qui ne me plaisent pas et alourdissent effectivement l’OS inutilement! <img data-src=" />









Nithril a écrit :



Le haut niveau n’a rien à voir avec le besoin d’une VM et C++ n’est pas un langage bas niveau, c’est un langage de haut niveau (surtout dans sa dernière version) qui peut descendre dans le bas niveau. Comparer C++ et Java alors que tu ne connais pas le premier c’est osé <img data-src=" />





<img data-src=" /> effectivement, mais je précise bien que je ne connais pas, ca m’attire pas mais je suis pas contre un peu de culture <img data-src=" /> (je suis dev Web PHP avant tout, donc C, C++ c’est pas mon domaine, meme si j’ai un peu touché au premier)



Les performances sont en grande parti du au fait qu’il est compilé pour la plateforme (enfin je suppose, comme pour le C) et il y a quand même une différence de perf entre les deux en partie du (je suppose encore) au fait que Java a besoin d’une VM. Je reste quand même persuadé que le fait d’avoir pris Java c’était pas la meilleure solution, pour les dev, c’est plus facile et c’est multiplateforme (pas bersoin de se soucier du CPU), mais pour le reste c’est pas top <img data-src=" />







ragoutoutou a écrit :



Ben techniquement, il y a les nexus, donc on ne peut pas mettre tous les contructeurs dans le même panier… <img data-src=" /> Il y a des périphériques sous android qui ont un suivi convenable… pas des masses, mais il y en a.





Les Nexus c’est un peu appart, c’est un peu le fleuron d’Android, heureusement que Google les met a jour sur 18mois. A part le Nexus Prime avec KK, le suivi est corrrect. Mais pour les autres constructeurs, a part certains et les flashgip, le suivi c’est pas vraiment ca. Surtout qu’ils auraient du profiter de KK pour en mettre pleins a jour (ca demande du boulot certes) vu que cette version est censée nécessité moins de ressources.







fraoch a écrit :



Et sur Android ca fait longtemps que les applications sont fluides, il faut aussi parler de choses qu’on connaît. Merci





Effectivement, encore étudiant, j’ai Java en grippe a cause des cours (et d’Oracle que je ne peux pas trop saquer a cause de PHP), mais pour le C++ ca reste quand même le plus performant par rapport a Java <img data-src=" />



Pour le haut et bas niveau, je suis tombé dans le panneau du rapprochement avec C <img data-src=" />



Euh, non non Android c’est pas fluide du tout. Sur un char d’assault ca l’est, mais pas sur un téléphone plus bas de gamme. J’ai eu un HTC One V (l’entrée de la gamme One) et c’est clairement pas fluide, alors qu’un WP équivalent le sera plus (au moins sur l’impression et ca compte quand même). Depuis que je suis repassé sur un HDG (S800+2Go de RAM) la ca l’est, tout est instantané. Tout comme ca l’était a l’époque sur le HTC Desire, encore un HDG (qui plus est, basé sur un Nexus).



Niveau langage de prog, effectivement des lacunes, mais étant dans le dev Web PHP, je m’intéresse trop peu aux autres langages <img data-src=" /> , par contre sur Android et sa fluidité, étant utilisateur, je fais ce constat









DayWalker a écrit :



Pour avoir testé ART sur CyanogenMod 11 (android 4.4.3), le principal soucis que j’ai eu sur mon Xperia Arc S, c’est que… bon dieu, ca bouffe la RAM à vitesse grand V ! Du coup, j’ai dû revenir à Dalvik pour que mes applications habituelles puissent toutes être installées et fonctionner sur 512 Mo (curieusement, une config qui devrait convenir à KK) !





pas de soucis sur mon sgsg2 en CM11 M7 (4.4.2)



je suis passé sous ART, et meme si je n’ai pas l’impression que ce soit beaucoup plus rapide (suaf certains chargement de jeux), j’ai gagné en autonomie et pour le moment aucun problemes…



a noter d’ailleur que le tel a ne ralentis plus a la longue, contrairement a CM10 (ou la rom stock, quelle horreur celle la….)



donc pour le moment, bye-bye dalvik









athlon64 a écrit :



Quand je parle de Java j’englobe aussi la machine virtuelle, et les problèmes de perf, même du au garbage collector sont quand meme problématiques. L’utilisation d’un langage plus bas niveau, un peu chiant pour les différents matos dispo je le reconnais, a l’avantage sur les perf. Et je peux constater des problèmes de performances sur un Core2Duo, je pense donc que même sur un ARM ca peut poser des problèmes. L’avantage de Java c’est d’être multiplateforme, mais au final c’est aussi un inconvénient





Tu pars de ton préjugé “Java = lourd parce qu’il y a une VM”, et t’en déduis que si Android est lourd, c’est parce qu’il y a une VM et qu’on écrit du Java. Tu en as d’autre des syllogismes dans le genre ?



Quelqu’un sait si Drastic (Emulateur DS) marche avec ART ? Sur le site de compatibilité il est dit que non, mais cela date un peu.








athlon64 a écrit :



<img data-src=" /> effectivement, mais je précise bien que je ne connais pas, ca m’attire pas mais je suis pas contre un peu de culture <img data-src=" /> (je suis dev Web PHP avant tout, donc C, C++ c’est pas mon domaine, meme si j’ai un peu touché au premier)



Les performances sont en grande parti du au fait qu’il est compilé pour la plateforme (enfin je suppose, comme pour le C) et il y a quand même une différence de perf entre les deux en partie du (je suppose encore) au fait que Java a besoin d’une VM. Je reste quand même persuadé que le fait d’avoir pris Java c’était pas la meilleure solution, pour les dev, c’est plus facile et c’est multiplateforme (pas bersoin de se soucier du CPU), mais pour le reste c’est pas top <img data-src=" />







La JVM compile le code en natif pour la plateforme. La différence de perf en Java et C/C++ tient à ce que le C/C++ permet d’aller dans des niveaux plus bas et fin que le Java qui lui implémente des choses simplifiant la vie mais potentiellement consommatrice de ressource.












athlon64 a écrit :



Niveau langage de prog, effectivement des lacunes, mais étant dans le dev Web PHP, je m’intéresse trop peu aux autres langages <img data-src=" /> , par contre sur Android et sa fluidité, étant utilisateur, je fais ce constat







En gros si je résume :



Tu es étudiant, tu fais majoritairement du PHP, tu as certaines lacunes, très peux de connaissances sur le Java, C++ et tu cherches à expliquer à tout le monde que le Java c’est le mal et que ce langage ne devrait pas être utilisé pour Android.



Relis tes commentaires, tu as fais un certain nombre de fautes impardonnable qu’un étudiant en développement ne devrait pas faire (notamment sur ta notion de langage haut niveau).









athlon64 a écrit :



iOS : Objective-C

WP : C-Sharp me semble



Android : Java, ca veut tout dire <img data-src=" />







C/C++ et dans certain cas assembleur aussi sur android.



Le C/C++ est quand même assez utilisé, dans pas mal de lecteur vidéo par exemple (VLC) ainsi que énormément de jeux utilisant des framework générant du code natif.



Dans l’absolu le java n’est quand même pas mancho niveau performance, mais sur android en particulier la machine virtuelle dalvik est quand même bien a la ramasse…



Les appli en java ont quand même l’avantage de bénéficier de toute les optimisation des machine vituelle (comme par exemple ce qui va se passer en passant sur ART), et par exemple lorsqu’on aura des version 64 bit d’anroid, d’exploiter le nouveau jeux d’instruction sans aucune modification, contrairement à ce qui se passe sur iOS.









mistigrite a écrit :



Tu pars de ton préjugé “Java = lourd parce qu’il y a une VM”, et t’en déduis que si Android est lourd, c’est parce qu’il y a une VM et qu’on écrit du Java. Tu en as d’autre des syllogismes dans le genre ?







D’ailleurs je profite de ton commentaire pour tordre le coup a une idée qui traîne un peu partout , Android N’EST PAS programmé en java (seulement certaines appli incluse), mais en C et C++ (majoritairement en C d’ailleurs)



Je suis heureux de lire cette article, je passe a chaque fois pour un fou intégriste quand je dit qu’Android est lent et qu’il n’y a pas besoin de processeur a 2ghz sur mobile pour faire fonctionner l’app facebook ou instagram. Si Android passe en code natif, on devrait voir un gain substantiel en performance.








mononokehime a écrit :



Je suis heureux de lire cette article, je passe a chaque fois pour un fou intégriste quand je dit qu’Android est lent et qu’il n’y a pas besoin de processeur a 2ghz sur mobile pour faire fonctionner l’app facebook ou instagram. Si Android passe en code natif, on devrait voir un gain substantiel en performance.







Tu passes maintenant pour un fou intégriste bête <img data-src=" /> (cf. les commentaires avant le tiens)









mononokehime a écrit :



Je suis heureux de lire cette article, je passe a chaque fois pour un fou intégriste quand je dit qu’Android est lent et qu’il n’y a pas besoin de processeur a 2ghz sur mobile pour faire fonctionner l’app facebook ou instagram. Si Android passe en code natif, on devrait voir un gain substantiel en performance.





<img data-src=" /> Je me suis deja fait déglinguer (par ma faute je le reconnais <img data-src=" />)



Dis que Java et la VM ca pue et je t’accueille dans mon club <img data-src=" />









athlon64 a écrit :



<img data-src=" /> Je me suis deja fait déglinguer (par ma faute je le reconnais <img data-src=" />)



Dis que Java et la VM ca pue et je t’accueille dans mon club <img data-src=" />







Il me semble avoir vu passer un projet de portage d’Android en code natif ou il était montré que le code natif était 10 fois plus rapide que le code interprété par Davlik, par contre cela pose un gros soucis pour les développeurs car il faudrait recompiler toutes les applications spécialement pour chaque téléphone.

Donc autant je comprend le choix du java pour des questions de portage, autant je désespère d’avoir un jour un OS rapide sur mobile a moins de sortir l’année prochaine un octocore 4ghz, ce que je commence a trouver ridicule.









mononokehime a écrit :



Il me semble avoir vu passer un projet de portage d’Android en code natif ou il était montré que le code natif était 10 fois plus rapide que le code interprété par Davlik, par contre cela pose un gros soucis pour les développeurs car il faudrait recompiler toutes les applications spécialement pour chaque téléphone.

Donc autant je comprend le choix du java pour des questions de portage, autant je désespère d’avoir un jour un OS rapide sur mobile a moins de sortir l’année prochaine un octocore 4ghz, ce que je commence a trouver ridicule.





Petite question aux connaisseurs : Si une app est compilée pour ARM, il faut une version par version d’ARM ou ca marche pour toute ? <img data-src=" />



Tu vas te faire taper dessus si tu dis qu’Android c’est pas fluide qu’il faut un char d’assault pour qu’il tourne parfaitement sans micro sacades <img data-src=" />









mononokehime a écrit :



Il me semble avoir vu passer un projet de portage d’Android en code natif ou il était montré que le code natif était 10 fois plus rapide que le code interprété par Davlik







Dalvik n’interprète pas le code.



Dalvik utilise la compilation “Just in time”, le code exécuté est donc natif. Il doit être simplement préalablement compilé au premier chargement de la classe (temps de chargement plus long). Par contre il est effectivement “managé”, c’est à dire géré par la VM.



Quand tu parles “d’un projet de portage d’Android en code natif “, je suppose que tu veux parler d’un portage Android pour le compiler “ahead of time” et l’exécuter via des librairies dynamiques plutôt qu’une machine virtuelle. En gros du code non managé.



Qu’est-ce qui peut expliquer qu’une machine virtuelle soit plus lente ?





  • La compilation des classes implique un démarrage plus long



  • Une consommation mémoire plus grande: les objets dans une VM consomment généralement un peu plus de mémoire (dépend de l’implémentation de la VM), donc les appels au ramasse miette sont plus nombreux si la mémoire est restreinte.



  • Pas d’accès direct à la mémoire: pour des raisons de sécurité et de portabilité le code managé par la VM ne peut pas accéder directement à la mémoire, aux registres etc. Ces parties doivent être faites par du code non managé, ou par la VM (qui doit donc proposer une sorte d’interface).

    Or le code non managé étant compilé en dehors de la VM, les appels de fonction ne pourront pas être “inline”, et la transmission des paramètres est plutôt compliquée &gt;&gt;http://stackoverflow.com/questions/7699020/what-makes-jni-calls-slow.









graam a écrit :



Dalvik n’interprète pas le code.



Dalvik utilise la compilation “Just in time”, le code exécuté est donc natif. Il doit être simplement préalablement compilé au premier chargement de la classe (temps de chargement plus long). Par contre il est effectivement “managé”, c’est à dire géré par la VM.



Quand tu parles “d’un projet de portage d’Android en code natif “, je suppose que tu veux parler d’un portage Android pour le compiler “ahead of time” et l’exécuter via des librairies dynamiques plutôt qu’une machine virtuelle. En gros du code non managé.



Qu’est-ce qui peut expliquer qu’une machine virtuelle soit plus lente ?





  • La compilation des classes implique un démarrage plus long



  • Une consommation mémoire plus grande: les objets dans une VM consomment généralement un peu plus de mémoire (dépend de l’implémentation de la VM), donc les appels au ramasse miette sont plus nombreux si la mémoire est restreinte.



  • Pas d’accès direct à la mémoire: pour des raisons de sécurité et de portabilité le code managé par la VM ne peut pas accéder directement à la mémoire, aux registres etc. Ces parties doivent être faites par du code non managé, ou par la VM (qui doit donc proposer une sorte d’interface).

    Or le code non managé étant compilé en dehors de la VM, les appels de fonction ne pourront pas être “inline”, et la transmission des paramètres est plutôt compliquée &gt;&gt;http://stackoverflow.com/questions/7699020/what-makes-jni-calls-slow.







    Il me semble que c’était un portage d’Android en C++ directement donc peut être que je me suis mal exprimé a ce sujet. Je ne retrouve plus la page et j’avais déjà l’impression a l’époque que le projet était au point mort. Pour les détails je laisse les spécialistes parler.

    Mais VM, interprétation, JIT ou autre procédé, il n’en reste pas moins que je trouve en général qu’Android est un système plus lent que les autres, a processeur égale si toutefois on peut faire une comparaison juste et équitable.









athlon64 a écrit :



Petite question aux connaisseurs : Si une app est compilée pour ARM, il faut une version par version d’ARM ou ca marche pour toute ? <img data-src=" />



Tu vas te faire taper dessus si tu dis qu’Android c’est pas fluide qu’il faut un char d’assault pour qu’il tourne parfaitement sans micro sacades <img data-src=" />







Tu peux avoir dans ton APK les versions de tes librairies compilés pour les différentes plateformes.









atomusk a écrit :



Tu peux avoir dans ton APK les versions de tes librairies compilés pour les différentes plateformes.





Il serait donc possible d’avoir un code compilé ne nécessitant pas de VM et qui marcherait sur toutes les plateformes, l’APK serait juste un peu plus gros ?









athlon64 a écrit :



Il serait donc possible d’avoir un code compilé ne nécessitant pas de VM et qui marcherait sur toutes les plateformes, l’APK serait juste un peu plus gros ?







tu auras toujours besoin d’un peu de VM pour communiquer avec l’OS.



Mais oui tu peux faire un code natif qui fonctionnera sur toutes les archi android, juste en augmantant le poids de l’APK.









athlon64 a écrit :



Il serait donc possible d’avoir un code compilé ne nécessitant pas de VM et qui marcherait sur toutes les plateformes, l’APK serait juste un peu plus gros ?









atomusk a écrit :



tu auras toujours besoin d’un peu de VM pour communiquer avec l’OS.



Mais oui tu peux faire un code natif qui fonctionnera sur toutes les archi android, juste en augmantant le poids de l’APK.





…donc ce n’est pas du code compilé multi-archi, c’est un APK multi-archi (contenant un code compilé par archi). <img data-src=" />

Néanmoins, l’utilisateur n’a pas besoin de savoir quelle est son archi au moment de cliquer sur “Installer”. <img data-src=" />