jackall Posté(e) 1 juillet 2009 Share Posté(e) 1 juillet 2009 Bonjour/bonsoir a tous, Je préviens tout de suite , le but du sujet n'est pas de lancer un troll sur l'intérêt du multitache :D Mais j'ai pu avoir en main plusieurs androphone (dream et magic) et les ralentissements et saccades sont parfois assez désagréable. Ma question est donc la suivante, savez vous s'il est possible de réduire, au moment de la compilation par exemple, le nombre d'appli concurentes. Et donc de passer par exemple à 2 ou trois appli, histoire de simplifier la vie du garbage collector et d'economiser de la mémoire. De même est il possible de faire du "ressource control" en attribuant une quantite no compréssible de ram à certaines appli... Je sais j'en demande beaucoup là :). Mais peut etre que des gens ayant déjà étudier le code source pourront répondre . Alors des idées?? Voila... Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
alejandro Posté(e) 2 juillet 2009 Share Posté(e) 2 juillet 2009 connais pas et si ca existe ca doit etre complique. Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
popolbx Posté(e) 2 juillet 2009 Share Posté(e) 2 juillet 2009 (modifié) Alors les gens il va falloir arréter de parler de garbage collector et d'applis. Le garbage est interne au langage java, il libère la mémoire des objets non utilisés. Si une appli tourne, il n y a aucune raison de la couper. Ensuite utilisez le bouton retour pour fermer une appli , le bouton home la laisse tourner en arrière plan. Et au final : un soft comme taskiller (pub perso) permet de flinguer les applis qui trainent en mémoire. du coup je n'ai jamais observé de ralentissement avec ces méthodes. Modifié 2 juillet 2009 par popolbx Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Jorodan Posté(e) 2 juillet 2009 Share Posté(e) 2 juillet 2009 Je confirme les dires de popolbx et j'ajouterais : Le processeur actuel est largement assez puissant pour tout ce qui lui est demandé (même en multitâche) hors 3D et Flash, là il rame. Les ralentissement viennent de problème libération et de chargement de la mémoire vive du téléphone. Le garbage Collector n'a pas été optimisé pour Android. Une des rumeurs de Donut et l'arrivée d'un garbage collector optimisé. Après tout ce que tu me demandes me parait possible mais très difficile à faire! C'est comme vouloir améliorer Linux en modifiant soit même le noyau : très peu de personnes en son capables. Ce que je te conseille c'est de passer directement tes demandes à l'équipe de développement d'Android. Ils ont l'air ouvert à la discussion mais c'est en anglais!! Voilou! Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
jackall Posté(e) 2 juillet 2009 Auteur Share Posté(e) 2 juillet 2009 Alors les gens il va falloir arréter de parler de garbage collector et d'applis.Le garbage est interne au langage java, il libère la mémoire des objets non utilisés. Si une appli tourne, il n y a aucune raison de la couper. Sans partir dans un debat ou une polémique, le garbage collector libère de la mémoire en "détruisant" les objets non utilisé et en détruisant les variables non référencé par un objet... Donc en principe si l'appli tourne il y a garbage collecting. Android "est" un linux, si un processus est stoppé (normalement ou pas ) c'est l'os qui désalloue la mémoire virtuelle. De plus le garbage collector par la vérification régulière du référencement des variables consomme des cycles CPU. Donc en théorie réduire le nombre de processus running réduit bien le travail du garbage collector. Mais bon après je me tromper je ne suis pas un expert en java.... Après tout ce que tu me demandes me parait possible mais très difficile à faire! C'est comme vouloir améliorer Linux en modifiant soit même le noyau : très peu de personnes en son capables. Oui je me rend bien compte ^^ spécialement pour la réservation de mémoire et de cycle CPU, ça pose de nombreux problèmes ( famine etc) . Mais dans le même temps je n'ai pas d'androphone donc je ne me rend pas bien compte si une tel limitation est intéressante ou non... Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Jorodan Posté(e) 2 juillet 2009 Share Posté(e) 2 juillet 2009 Effectivement Android est un linux avec une surcouche Java! Là ou ma connaissance s'arrète c'est que fais lequel par rapport à l'autre! Je crois que la gestion de la mémoire est presque entièrement gérée par le GC de Java. Et d'après les rumeurs, Donut aura un GC amélioré! Wait & see! Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
popolbx Posté(e) 2 juillet 2009 Share Posté(e) 2 juillet 2009 Chaque appli lancée utilise une instance de la machine java dalvik. Dans cette machine le gc fonctionne mais uniquement dans cette machine. 2 appli lancees = deux machines. il est possible de modifier la machine pour lui interdir de lancer une autre machine s il y en a déjà un nombre déterminé. mais c dangereux. Par exemples si le nombre est atteind mais que tu n utilise que des services (sms popup, musique, bluetooth) tu ne pourra plus rien lancer. Voir même ne plus recevoir d appel. Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
popolbx Posté(e) 2 juillet 2009 Share Posté(e) 2 juillet 2009 (modifié) Pourt ceux qui se demandent ou est l interaction linux/java, un bref cours. Le linux après son boot lance un exe : ServiceManager. Cet exe coordine les processus "zygote" et permet aux processus de communiquer entre eux. Puis il lance l exe zygote: il permet de lancer la machine virtuelle java et de s'inscrire auprès du service manager. Les messages envoyés à ces processus sont transmis à la machine java. Les processus zygote peuvent communiquer entre eux grace à leur pid linux et à un système de bind (dans le noyaux linux). Là c'est le noyau qui gère tout donc c fiable à 100%. Chaque processus zygote est une instance de la machine java. Donc si on lance 10 processus, on lance 10 machines. Là c'est carrément pas du tout optimisé, MAIS si une appli plante, le processus "creve" tout seul et les autres machines java ne sont pas touchées. Pas de probleme de mémoire. Par exemple home peut très bien planter.... quand il se relance vos applis sont encore là. (pas comme windows et son écran bleu^^) le premier processus zygote lancé est "surfaceflinger" une appli java qui gere l'écran. Puis le home, qui communique avec le surfaceflinger pour dessiner le bureau ^^ Puis pleins d'autres qui constituent "android". Quand on lance une appli avec home, il demande au servicemanager de lancer l appli. Un nouveau processus linux est crée, une nouvelle machine et hop ! une fenêtre. c'est dans cette machine que la mémoire de l'appli est gérée . Et que le garbage collector fait son boulot. Là ou ce n'est pas optimisé c'est que s'il y a 10 processus lancés il y a autant de machines java qui n'arrettent pas de lancer leurs gc. Donc 10 applis = 10 gc = ça rame à max... Mais si un gc tourne pdt qu'une autre appli tourne, le noyau linux va donner priorité à .... bein....celle qui tourne car home sait qu'elle est au premier plan donc il la dit au service manager qui la dit au noyau linux. Après si les applis sont des services...ils ont tous la même priorité... donc leurs GC tournent souvent pour rien...donc oui là grosses pertes de perfs. Android peut être 100 fois plus rapide MAIS 100 fois moins souple, et 100 fois moins stable. Le choix fait a été celui de la stabilité et de la simplicité. S'il devait y avoir une seule machine java il faudrait gérer pleins de choses en plus qui sont gérées en standard dans le noyau linux... Modifié 2 juillet 2009 par popolbx Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
xau Posté(e) 2 juillet 2009 Share Posté(e) 2 juillet 2009 Les processus zygote peuvent communiquer entre eux grace à leur pid linux et à un système de bind(dans le noyaux linux). j'ai zappé à partir de là :cool: Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
popolbx Posté(e) 2 juillet 2009 Share Posté(e) 2 juillet 2009 lol :P Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Fluckysan Posté(e) 2 juillet 2009 Share Posté(e) 2 juillet 2009 Il est vrai que du coup ça a son point faible mais le gros avantage est en effet la stabilité ! C'est un bon choix qui a été fait par Androïd, ça respecte l'état d'esprit de Linux : la stabilité Duc oup je comprend mieux les multiples Zygote de la console dans Eclipse ;) Thx Popolbx pour les explications Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
jackall Posté(e) 2 juillet 2009 Auteur Share Posté(e) 2 juillet 2009 Merci popolbox pour ces explications, je comprend bien que limite le nombre d'instance concurrentes de java pourraient entacher la souplesse du système. De même il ne me viendrait même pas à l'idée de ne passer que par une seule jvm, ne serait ce que pour les problème de sécurité... Mais ma question ne portait pas sur le fait de limité je nombre d'instance concurente (pas directement) mais bien de réduire le nombre d'application concurrentes( car je suppose que la couche téléphone est un service...) je pense que c'est une question auquel peu de monde peut répondre , mais j'ai idée que peut être... Popolbx :D j'ai zappé à partir de là cool lol , l'informatique s'est plein de mot et de terme compliqué mais au final.... bah c'est quand même compliqué Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
popolbx Posté(e) 2 juillet 2009 Share Posté(e) 2 juillet 2009 ah bein techniquement il y aurait deux méthodes: - modifier le source (par exemple du launcher pour bloquer si trop d applis ou du servicemanager pour geler le processus en trop ) - faire une appli en service qui compterai les nb d applis et interviendrait quand il y en a trop. En théorie on peut faire quelquechose..mais c ets un coup à se retrouver avec un iphone ^^ Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
jackall Posté(e) 2 juillet 2009 Auteur Share Posté(e) 2 juillet 2009 ah bein techniquement il y aurait deux méthodes:- modifier le source (par exemple du launcher pour bloquer si trop d applis ou du servicemanager pour geler le processus en trop ) Idée intéressante . - faire une appli en service qui compterai les nb d applis et interviendrait quand il y en a trop. En théorie on peut faire quelque chose..mais c ets un coup à se retrouver avec un iphone ^^ Idée aussi intéressante, d'autant plus qu'avec un système de politique (ou même des user defined policies!!!! :rolleyes: ) = on pourrait intégrer de la souplesse au truc ^^. Par contre bizarement mes "genes" de dev en herbe me disent que cette solution est bien plus compliqué à implémenter proprement que la première :| Ne pas faire du multitâche est impensable pour un téléphone digne de ce nom... :lol: Merci pour ton avis Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Jorodan Posté(e) 3 juillet 2009 Share Posté(e) 3 juillet 2009 Merci pour ces explications!!! Moi j'espère que chez Google ils ont des mecs suffisamment balèze pour faire une JVM propre a Android, qui gère un seul garbage pour tout le monde, et qui plante pas si une plante! C'est compliqué, mais si linux, MacOs et windows devaient s'arrêter aux trucs compliquez, je serais encore sous Windows95!!! Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Recommended Posts
Rejoignez la conversation
Vous pouvez poster maintenant et vous enregistrez plus tard. Si vous avez un compte, connectez-vous maintenant pour poster.