Android Kit Kat disposerait d’une alternative à la Dalvik Virtual Machine ?

Je ne trouve pas le menu développeur ....

Le succès d' android c'est justement java ... un langage populaire ( java ME, java SE, etc ) et libéré par Oracle ... Sans java il n'y aurait pas eu l'adoption massive des développeurs et donc Android serait mort très rapidement

Dalvik

On peut aussi penser que l'intégration de Art dans l'OS est une sorte de beta test à grande échelle... on laisse dalvik pour que les gens gueulent pas si c'est foireux et on attend les retours des utilisateurs sur des plates formes diverses

Tu es -ENCORE- sous i7500 ?!!

Mais par défaut, c'est quoi qui est utilisé ? Dalvik ou ART ?

Humpf, je pense que tu oublies qu'il se passe quelque chose en dehors de l'univers du smartphone. Quant aux perfs ... http://talk.maemo.org/showthread.php?t=68730&page=12

dotNet est né sur Desktop, pour le desktop et est largement utilisé par les logiciels Windows. Tu peux penser que le risque vaut d'être pris si tu veux mais ce n'est pas le cas. Si Android reposait sur du code natif, non seulement il ne connaîtrait aucun essor dans l'industrie de l'embarqué mais Google serait contraint d'adopter exactement le même modèle qu'Apple avec un modèle de distribution du contenu contrôlé a priori. Inutile de dire que peu de constructeur aurait suivi Google dans une aventure où il est seul maitre à bord.

La réactivité du Touchscreen est très à l'avantage d'Apple, ça se sent... Mais ce n'est pas forcément à mettre sur le dos de Java... Je ne suis pas développeur, mais j'ai quelques avis sur le sujet, les devs pourront me dire si j'ai tort, ce n'est qu'un débat, pas une vérité : 1) les priorités des appareils, la gestion du multitâche, les applications peu multithreadées sur lesquelles le quad-core n'a pas d'impact (sauf à avoir d'autres programmes qui tournent en multitâche) 2) le module de gestion de l'énergie : quand on te vend un proco à 2Ghz, en fait sa fréquence est variable (de 300Mhz à 2Ghz par exemple), En changeant de mode de gestion de l'énergie (Governor), tu gagnes parfois 40% de performances (mais avec une perte d'autonomie). Typiquement, le bench qui avantage Apple est un bench Javascript : "Sunspider". Ce bench est systématiquement mis en avant sur les tests "pro-Apple", il est pour moi beaucoup trop léger pour permettre la montée en fréquence sur Android. Un autre test Javascript plus lourd, Mozilla Kraken change complètement la donne. 3) le natif avait un avantage conséquent sur des machines à 3Mhz, Le temps d'interprétation était alors important et les tâches étaient petites pour que ça ne rame pas...Aujourd'hui, les tâches sont plus lourdes et le temps d'interprétation devient plus négligeable 4) des tests perso fait il y a un peu plus d'un an (avant la sortie de l'iPhone 5 et d'iOS 6) en ouverture de pages web lourde (la page d'accueil de league of legend) : iPhone 4s sous iOS5 vs mt6577 sous Android 4.0.4 (2 téléphones dual-cores A9 à 1Ghz)....résultats : les pages se sont ouvertes à la même vitesse...certes on repasse par du Java 5) en comparant d'autres matériels proches (ici PowerVr 543MP2 à 200Mhz sur iPad mini et Power544MP2-proche- à 533MHz), on se rend compte que les fps sont proportionnels à la fréquence (533/200=2.66, 9fps/3.4=2.64) http://gfxbench.com/compare.jsp?D1=Teclast+P89+mini+%28E2W6%29&D2=Apple+iPad+mini&cols=2 Certes on passe par une lib OpenGL 6) les croyances du public : à la sortie de l'iPad 3, Apple a dit qu'il était 4x plus rapide que le Tegra 3 sur le Fillrate (et c'est vrai). En se servant d'une composante du GPU qui n'a strictement rien à voir, ils ont réussi à faire croire (sans jamais mentir) au grand public qu'un CPU dual-core Apple allait plus vite qu'un CPU quad-core nVidia (ce qui est faux) : le tour de force est énorme....aucun journaliste n'était là pour expliquer techniquement la chose Tout ceci me laisse penser que sans la nier, l'optimisation Apple est très fortement surévaluée par le grand public. Et que ce petit sacrifice de performances nous ouvre à une diversité de matériels hautement bénéfique

Pas seulement

"il n'a pas compris que rien n'est ni totalement nul ni totalement parfait ; il y a juste des technos diverses qui s'adaptent plus ou moins à divers besoins et qu'une techno n'est qu'un outil, pas une fin en soi." Pas mieux.

Roger, fais ripper l'jaune..

"un bordel sans nom à cause des archis différentes" Heu ouais... Sauf que si Google était partie sur une architecture bien spécifique il y aurait pas eu une si grande homogénéité au niveau des architectures dispo sur android (et je dis "homogénéité" hein, mais 80% du parc c'est de l'ARM7, faut arreter de mettre en avant MIPS, x86, ARMv6 dans vos comms hein, parce que je suis certain que ca represente meme pas 2% des ventes d'applications). Apres certains me diront que c'est le concept de base d'android, ok, ca reste emmerdant... "ta gestion entière de la mémoire à la mano" Ouais, c'est clair ca va etre chiant pour ceux qui font des applications de compta sur android, mais pour les autres ca sera surtout un énorme gain de perf... Les mauvais developpeurs continurons a generé des fuites de memoires, mais les bons pourront enfin rivaliser avec iOS.... "des taaaaas de biblis existent déjà pour ce langage." Ouais, dommage qu'elles ne fonctionnent pas sur android les 3/4 du temps (incompatibilité de la vm, nécessité des framework java)... En C++ c'est generalement beaucoup plus simple de recuperer les bibliotheques, car elles sont souvent plus independante...

Non

C'est à peu près toujours comme ça: ceux qui ont les avis les plus tranchés sont souvent ceux qui n'y connaissent pas grand chose. Les "Java cayDeLaMayrde" et compagnie, ce ne sont que des trolls d'il y a 20 ans qui ont fini par suinter chez ceux qui CROIENT savoir mais qui n'ont en fait aucun background technique. Ils trainent ces caricatures entendues ça et là en pensant que ça leur donne une certaine assise technique qu'ils n'ont pas. Leur suffisance leur interdit dans le même temps de pouvoir imaginer ne serait-ce qu'une seule seconde que si une palanquée d'ingénieurs chez Google a fait ce genre de choix, c'est qu'ils ont peut-être un poil plus de compétences que lui dans son petit coin et qu'ils ont pesé le pour et le contre un peu plus loin que lui. En bref, ce genre de poncif à portée définitive (JavaCayLent, JScayPourLesNoobs, etc...) est le marqueur de celui qui ne connaît rien plus que celui qui comprend les enjeux. En général quand j'entends ce genre de phrase en entretien d'embauche, c'est d'emblée très mal barré pour le candidat puisqu'il montre qu'il n'a pas compris que rien n'est ni totalement nul ni totalement parfait ; il y a juste des technos diverses qui s'adaptent plus ou moins à divers besoins et qu'une techno n'est qu'un outil, pas une fin en soi. Je re-quote Zratul qui a tout dit en une phrase: "Les langages de programmation sont une affaire de compromis.". J'ajouterai que c'est la même chose pour à peu près toute chose en ce bas monde. Techniquement parlant, la réalité c'est que le managé propose un surcoût faible, et étant donné que ce surcoût est globalement constant, sa proportion faiblit régulièrement au fur et à mesure que la puissance moyenne des CPUs grand public augmente. Il y a 20 ans sur un desktop, un interpréteur te mangeait 15% à 20% de surcoût pour une tâche donnée ; aujourd'hui, si tu es à un ou deux pour-cents, c'est déjà surestimé. C'est exactement la même chose pour les CPUs mobiles dont la puissance explose à chaque génération et qui rend le différentiel négligeable tout en conservant les avantages intrinsèques au managé (sandboxing, gestion d'erreur, portabilité, introspection, ...) qui sont justement d'une importance capitale pour ce segment de marché de la mobilité et de l'embarqué ; en plus de tout l'existant en Java à la fois en ressources techniques mais aussi humaines.

non c'est une question de kernel là.

Tu sais le language java est déjà bien JARrté .. Pardon ... -> []

Respect à utilisateur de Galaxy i7500! Je vais passer de mon i7500 au Nexus 5 ;-)

Sauf que si les gens ont inventé des langages tournant sur des VMs c'est pas pour faire joli non plus, c'est qu'il y a aussi un intérêt et c'est justement parce que tu n'es pas développeur que tu ne vois peut être pas pourquoi. Binaires liés à une archi, gestion de la mémoire moins évidente, oui les langages de plus haut niveau font forcément un compromis au niveau perf mais en contrepartie permettent aux développeurs de se prendre moins la tête sur certaines choses. C'est pas une histoire d'être un dev fainéant ou pas, c'est juste que plus le logiciel à coder est gros et complexe et plus la voie native va apporter des soucis en termes de temps de développement par rapport aux langages plus haut niveau. (l'exemple qui revient le plus souvent est toute la gestion de la mémoire souvent) Parce que sinon on peut même pousser le raisonnement à l'extrême et tout coder en assembleur... Les langages de programmation sont une affaire de compromis.

Tu voulais quoi comme langage ? Tu avais grosso-modo plusieurs choix à l'époque : - du pur natif avec C/C++ par exemple - un langage semi-compilé comme Java/.net - un langage de script comme PHP, Ruby, Python, LUA Tu aurais imposé le C/C++, non seulement on aurait actuellement un bordel sans nom à cause des archis différentes : MIPS, x86, ARMv6, ARM v7 obligeant à avoir des tas de binaires différents , mais en plus je ne te raconte pas la difficulté pour les devs. Mange toi tes segfaults, ta gestion entière de la mémoire à la mano. Même si les Garbage Collectors sont pas la solution ultime, savoir faire des bonnes libérations de mémoire quand il faut est extrêmement difficile. Pour les langages de script, c'est souvent plus élégant (bon sauf PHP parce que hein...), ça a l'avantage aussi d'être multi plate-forme quand tous les interpréteurs sont codés mais c'est plus lent que les langages semi-compilés comme Java Pour moi Java est un bon compromis, il est répandu, il était éprouvé, il était relativement "Open" (bon avant que Oracle décide de faire chier) même si ce point est un peu plus complexe, des taaaaas de biblis existent déjà pour ce langage. Oui Java c'est lourd et verbeux mais périmé : tout dépend de ce que tu veux dire. Java est pur objet et permet de monter de très belles choses surtout quand on voit toutes les horreurs en PHP et Javascript qui sont légion en ce moment. Son typage fort et statique est contraignant pour certains, moi au contraire je trouve que c'est bien d'être carré sur ce point et ça permet aux IDE de permettre de très puissantes auto-completion, contrôles impossibles à faire sur des langages à typage dynamique. Apple a choisi ObjectiveC pour iOS car c'est depuis longtemps le langage de choix pour les frameworks de dev d'app MacOSX Donc Java pour Android, oui c'est loin d'être parfait et y a des lourdeurs avec lesquelles il faudra composer pendant longtemps mais en analysant un peu tout ce qu'il y avait à côté quand le système a été écrit (on parle de 2005-2007) je trouve que c'était sûrement un des choix les plus logiques.

" Pour le Desktop aussi ..." Qu'est ce qui te fais dire ça..? " imagine si ça avait été du natif avec de vrais risques." Ben les gens auraient enfin des bonnes raisons de se plaindre de la securité d'android (plutot que de faire des news à scandale pour rien)... Je pense que le risque vaut la peine d’être pris.

Et dans l'article depuis plus de deux heures mais ok

Pour avoir passer plusieurs années dans l'écosystème Microsoft, s'il est vrai que C# implémente plus de concepts que Java, je ne suis pas d'accord pour le reste. Quoiqu'il en soit, la direction prise par MS est celle du tout managé, et pas juste pour ses mobiles. Pour le Desktop aussi (et bien évidemment pour le web). Si on parle des prétendus problèmes de sécurité d'Android aujourd'hui avec le sandboxing et le tout managé, imagine si ça avait été du natif avec de vrais risques.

Comme c'est dit dans l'article, c'est à cause de l'hétérogénéité des processeurs. Pas besoins de recompiler chaque programme pour chaque architecture, mais juste en byte code qui sera lui traduit par les interpreteurs qui eux seront biens compilés pour leurs processeurs respectifs. En gros chaque développeur n'a pas à faire attention à quelle modèle de processeur il va avoir à faire.

c'est ce qu'on appelle une communauté Android :p

frandroid, le site ou la vrai info est dans les commentaires... ;)

Ben pour moi c'est clairement pas suffisant comme arguments... On releve les meme problème sur pc, pourtant on est tres loins d'etre passé au tout-langage-managé... Et là c'est mille fois moins adapté parce qu'on parle quand meme de petit hardware, orienté divertissement... Sinon, c'est vrais que MS a effectivement fait la meme erreur pour ses mobiles (à ceci près que .Net est quand même beaucoup plus fouillé et agréable à utiliser que le couple l'android framework + java), Est ce suffisant pour justifier ce choix pour android...? MMmmmh... non.

Moi je pense que c'était surtout afin de pouvoir remplir le market rapidement (étant donné que Java est aussi utilisé sur les anciens téléphones).

Oui enfin déjà, il faudrait déjà que ce soit autre-chose qu'une démo technique planquée dans les options développeurs pour penser sérieusement à l'utiliser, ne serait-ce qu'en 4.4. D'ici à ce que ça remplace effectivement Dalvik (si ça arrive un jour), on aura le temps d'en reparler hein.

Plus exactement, iOS favorise l'interaction (car Android favorise très clairement l'interface).

Le fait de pouvoir passer de 32 bits à 64 en claquant des doigts ? D'être dispo. sur MIPS, ARM et x86 ? De contrôler les accès mémoires et autre joyeusetés du natif et d'établir un système de permission ? Le fait que c'est le langage utilisé par Google à à peu pr tout les niveaux (AppEngine, GWT, etc.) ? De l'autre côté de l'échiquier, on fait pareil. Côté Microsoft, ça s'appelle dotNet et c'est exactement la même histoire (pour exactement les mêmes raisons). Quant à pourquoi Java, il a le côté "libre" même si Oracle est pas ultra clair dessus, il y a surtout le fait que sur mobile, c'est le langage de prédilection, jusqu'à la carte SIM qui se programme en Java.

C'est un peu l'impression que j'ai aussi... Faut dire, Google est super connu pour balancer des projet gratuit dans tout les sens sans avoir la certitude que ca devienne populaire... Et je suis pas certains qu'ils aient anticipé le "succès" d'android... :p

Respect mais tu manque de billes techniques. Que ce soit une Dalvik ou une ART ou une JVM, une VM (virtual machine) reste dans le même principe. À savoir également qu'un code dans une VM peu s'exécuter aussi vite que du natif grâce au JIT. Quand à la question de réactivité c'est juste un choix dans la politique de priorité des processus s'exécutant. iOS favorise l'interface, Android non. Ça se remarque assez bien, sur iOS tu charges une grosse page web (avec du Javascript conséquent) et pendant le chargement tu fais des actions sur ton interface, la page web se chargera plus lentement, sur Android ce n'est pas le cas, le temps de calcul est répartie plus ou moins également entre les processus.

C'est introduis dans 4.4 donc non sa n'est pas dans les version inferieur. A voir a termes si un portage est possible.

Ce n'est pas actif par defaut je penche donc plus pour un projet experimental qui a termes pourrais remplacer dalvik (dans la version 5.0 par exemple)

J'ai toujours été nul pour faire des métaphores

Android c'est comme une habitation isolée à l'amiante Depuis des années des cache l'amiante, on met du joli papier-peint, on repeint les volets, on refait le crépi... Mais bon un jour faudra bien la virer cette amiante

Vrai, la priorité étant donnée aux événements tactiles, d'où les limitations de l'OS dés qu'il s'agit d'être background.

Reste que niveau réactivité pure, Apple est loin devant, et c'est pour ça que ça semble tellement plus "fluide" (Android user since Galaxy i7500, please respect)

Ouais enfin, de mon point de vue c'est tout le langage java qui est bon à jarté (qui en plus d'etre lourd est complètement périmé). D'ailleurs, j'ai vraiment du mal à saisir qu'est ce qui les ammené à faire ce choix... qu'est ce qui justifie l'utilisation d'une machine virtuelle sur un meme Os..? Une erreur qui date des debut d'android? (à l’époque ou ca devait juste etre une merde pour appareil photo?)

Magic: http://source.android.com/devices/tech/dalvik/art.html

L'empreinte mémoire est plus petite et tout ce concerne un affichage est plus rapide, son utilisation énergétique est beaucoup plus petite, etc. Bref, les cas d'utilisation de tout les jours. Là où la Dalvik pêche par rapport à la JVM, c'est sur les calculs mathématiques bruts. Bref, des cas de labo.

N'importe qu'elle dev te le dira on utilise pas dalvik pour le plaisir de faire de belles chouquettes Dalvik et plus légère (avantage non négligeable pour un os Mobile) et plus performante sur des architecture modeste (du style de celle qu'on trouve sur les smartphone) ne t’inquiète pas que les gens qui ont était fait l'ont était pour de conne raison

On a testé sur un N4 en effet, c'est palpable.

https://www.usenix.org/legacy/events/vee05/full_papers/p153-yunhe.pdf On bosse juste dedans, du coup on n'y connait rien. @ExaGod Il y a quand même des mécanismes qui permettent à une VM de rivaliser avec du natif : http://www.javarants.com/2010/05/26/android-dalvik-vm-performance-is-a-threat-to-the-iphone/

C'est connu... Je suis pas dev, et je n'ai pas de sources Mais en gros android se base sur une machine virtuelle pour faire tourner les .apk Et même la mieux optimisée des machines virtuelle ne fera jamais le poids face à un système en natif Au final pour l'utilisateur, c'est une surconsommation de puissance (donc de batterie), une latence plus élevée.. C'est ainsi qu'Apple peut rivaliser avec un système sous android avec une batterie de capacité inférieure, des processeurs moins puissants... tout en ayant une latence quasi divisée par deux ( http://img.staticigen.com/2013/10/macgpic-1381409638-47729001713242.png )

et apparemment c'est dans la ROM du nexus 5, et dispo sur le portage pour n4, et ça fluidifie le launcher :3 (commentaires visibles sur le topic XDA concerné.)

Non. Ou alors source. C'est comme dans l'article : "La machine virtuelle Dalvik, bien que beaucoup plus rapide que la machine virtuelle Java classique [...]". Cette phrase est non sourcée et non explicitée. Pour quel type d'opérations, sur quelle architecture, avec quelle version de la JVM ? C'est vraiment n'importe quoi ce site. En plus de l'orthographe dans les articles, les auteurs et les commentateurs ne connaissent rien à l'informatique.

Enfin ! Dalvik c'est LE truc qui plombe les perfs sur android..

Purée, ils sont fort ses bretons !!!