Reprise du message précédent :

Tu mélanges tout. Y'a deux états qui nous intéressent :

- Activity active (app démarrée et en cours d'utilisation)
- Activity en pause (app démarée mais non visible)

Une app dont l'activité est en pause ne consomme pas de CPU par définition.
Le cas contraire il s'agit d'un Service, normalement les apps qui utilisent des service sont liées au paramètre de synchro, avec quelques exceptions, e.g l'app du Market, où le font de manière ponctuelle, par exemple un téléchargement.

Si tu trouves une appli qui consomment du CPU en n'étant pas à l'écran, désinstalle la. Period.

Des services (donc un truc qui consomme potentielement du CPU à proprement parler) tu dois en avoir 10 à tout casser qui tournent sur ton téléphone. Si tu regardes ton battery usage tu verras que ce sont les applications au premier plan et Display/Cell Stand by qui consomment : j'ai 47 apps qui "tournent" et deux (Gmail et Internet) dans les applications qui ont consommé de la batterie depuis hier matin.

Shinuza
non mais lol le pb c'est qu'elle ne se mettent pas toute en pause justement.
j'ai deux lecteur MP3 (d'on l'un d'origine sur le tel) et tout les deux bouffe de l'energie une fois fermés (bouton home ou retour) car ils lisent tjrs la zik donc là c'est facile de s'en rendre compte mais celles qui sont silencieuse tu t'en rend pas compte (et ca me le fait avec plein d'appli, peut etre une incompatibilité avec mon phone ?). Toute façon osef des raisons (si bug ou autre), y'a des appli qui bouffe de l'accu inutilement une fois fermer c'est comme ça. Et si on veut les garder ?
 

D'ailleurs le mieu je pesne que c'est de regarder conbien la bat perd en % pendant une periode de x h avec une appli en mémoire don on se doute qu'elle consomme du courant. Et ensuite le faire une fois qu'on a tuer completement l'appli et encore avec et encore sans pour confirmer les resultats. Psk les analyseur de proc c'est pas ce qui est de plus fiable pour savoir si une appli bouffe de l'energie (il suffis que la conso ne soi pas constante et elle peut utiliser d'autre composant que le proc pour consommer du courant).
 

un chatroulette photo je dirait plutot non ?

Je ne mélange rien, je constate le "battery usage" : j'ai des appli qui sont censées être "en pause" (quittées, voire même killées mais relancées automatiquement), qui sont censées ne pas consommer de batterie, mais qui en consomment tout de même (cf battery usage et conso CPU instantanée donnée par "Android Assistant" )

Encore une fois, relis les posts en question plutôt que de faire des hypothèses sur ce dont je parle. Tout ce que tu dis là, je suis tout à fait d'accord avec, seulement ce n'est pas de ça dont on parle.

vous avez pensez a demander juste au développeur de corriger leur soft.? parceque perso j'ai une 30-40aine d'appli que j'utilise plus ou moins régulièrement et aucune ne me pose soucis.  
 
Donc essayer peut être de voir avec le développeur pour qu'il corrige son soft plutôt que vous faire chier avec des task killer

Pour diagnostiquer ce genre de problème il y a System Panel (même en version free) qui liste
les applications inactives, actives, visibles ou en tache de fond (background) et les services,
avec la consommation mémoire et temps CPU.

Ça revient à ce que je disais, un lecteur MP3 utilise un service pour diffuser le son. C'est logique qu'une fois tu quittes l'app le son ne s'arrete pas, sinon quel interêt? D'ailleurs mes lecteurs MP3 une fois en pause pendant un certain temps killent le service de son pour passer en passif complètement.

J'aimerais bien que tu me donnes des exemples concrêts parce que le comportement que tu décris est contraire aux règles de fonctionnement normal d'une app Android.

Donnez moi des chiffres et des données au lieu de me dire, "j'ai des applis qui consomment". J'ai décortiqué au point par point la consommation de mon téléphone, écran éteint il consomme 4mah en moyenne. Ce que je vous dis c'est que le comportement que vous décrivez :

- n'est pas normal
- trahis un développement foireux si l'utilisation CPU est inutile
- n'est par conséquent pas un let motiv suffisant pour que l'Os inclu ce fameux boutton "Quitter" - qui remettrait en cause la totalité des paradigmes d'UX relatives au management des apps à savoir : laisser l'OS gérer.

Voilà, c'est ce que je dis depuis tout à l'heure, ça vient du dev pas de l'OS.

 
J'aime bien le concept, mais j'ai configure mon telephone pour pas qu'il auto rotate le display, du coup j'ai aucun moyen de passer en mode "prendre une photo" sans changer ca, c'est dommage

ouais il faut que je face un truc comme l'appli Youtube qui fonctionne sur l'accéléromettre.
 
Mais j'ai tellement de truc a faire avant

Les exemples précis avec chiffres et données sont dans le post que je te suggère de lire depuis le début et que tu t'obstines à ignorer (ça coute pas grand chose quand on prend une discussion en route de commencer par le début), je ne me contente pas de dire "j'ai des applis qui consomment"

 
Concept sympa, mais malheureusement de grandes chances qu'il soit rapidement atteint, s'il a du succès, par le syndrôme chatroulette, aka "syndrôme du trombitoscope"

sympas. Mais % CPU pour chaque appli, pas en temps reel. Pour cela il ya watchdog ou OSmonitor par ex.
 
 

meme via le bouton retour donc non ce n'est pas normal je trouve. S'il faut arreter toute les fonctions d'une appli quand on veut la fermer, c'est relou. Selon moi la touche retour devrais killer systematiquement les appli qu'on quitte de cette maniere. La touche Home si l'on veut que l'appli continu de fonctionner en tache de fond (ou elle se met en pause, selon sa configuration). Bon ca marche peut etre bien avec la majorité des app mais il suffis qu'il y en ai une seule qui deconne...
 
 

A l'epoque j'installait/desinstallait bcp d'appli et bcp d'entre elles buggai (genre qui tourne toujours en tache de fond, l'ecran du tel qui ne se met plus en veille auto, etc), je quitte l'appli en la killant, point (avec un taskiller j'ai juste a attendre ou à forcer la veille de l'ecran, le killage est automatique). Vais pas m'amuser a avertir les dev (mais c'est vrais que pour celles que je veut absolument conserver ça serait une solution mais bon la flemme quoi )  . Le jour ou l'OS fera en sorte qu'aucune appli ne consomme quand on en a plus besoin (ou avec surveillance de la conso courant et pas seulement du cpu et avertissement via popup ou alors killage auto au dessus d'une certaine consommation), je changerait peut être ma façon de faire. Et pour moi il est important de tenir plusieurs jour sans recharger sinon je serait moins difficile si je l'utilisait intensivement et le rechargait tout les jours.
 

c'est comme un chatroulette ton app ? on peut laisser des commentaires ?

Le concept est déjà présent sur iphone et pour le moment je ne crois pas que ce syndrome ai encore frappé (mais bien évidemment les utilisateurs ne sont pas les mêmes. )

il y a déjà une appli du genre sur android, j'avais essayé mais je me souviens plus du nom

en gros quand tu recevais une photo ça te donnais à ton tour la possibilité de prendre une photo, tu pointais une direction avec ton tel et ça envoyait la photo à un utilisateur au hasard qui se trouve dans la direction pointée

edit: a world of photo : https://market.android.com/details? [...] rch_result

Le coup de pointer dans une direction, je trouve ça excellent. Faudrait y rajouter une vue à la Layar, où tu vois en superposition de l'image filmée, les positions approximatives des cibles anonymes de tes photos, du coup, tu peux sélectionner l'une d'elle en pointant dessus, et communiquer ainsi dans les deux sens (genre la personne qui t'a envoyé une image, sa cible est repérée différemment)

Bon ok, les plus grincheux d'entre vous diront que c'est con, autant envoyer un MMS photo au pif à un numéro au pif, mais moi je trouve cette idée sympathique

Tu parles de ça? A moins que tu ai chargé ton téléphone à bloc entre chaque mesure ton bench est foireux. La mesure donnée par Android c'est depuis la dernière charge, pas un échantillon pondéré par l'indice de charge. D'autant plus que ça n'est pas ce dont je parle, je parle de consommation des dites apps une fois idle (e.g playlist terminée mais app non quittée)

Si tu prêtes attention à ce qu'il se passe quand tu appuis sur la touche retour, tu verras que tu reviens toujours à un écran que tu as déja vu, c'est un fil linéaire. C'est pas son propos de fermer l'application, si tu lance une app et que tu fais retour tu devrais retourner sur le home, sinon tu reviendras d'un cran en arrière.
 
Je repète y'a pas besoin de killer une app pour qu'elle arrête de consommer. Que tu utilises home ou retour pour revenir sur la home, l'app sera en pause.

C'est le cas, sauf avis contraire, c.f mes précédents posts.

Déchire

un autre bug, l'image prise par l'appareil photo est toujours dans le meme sens, donc si on tourne l'appareil dans l'autre sens, on se retrouve avec une image inversee verticalement

un mec de google a pris une pic! jai tracé l'ip c bien aux US

Je viens d'avoir un FC en scrollant les images Rapport envoyé !

Sinon, les nouvelles images sont en bas ou en haut ? On dirait en bas, mais je trouve pas ça intuitif, vu que quand on ouvre on a toujours les vieilles images

edit : bon ben ça FC toujours au même endroit

en fait il faut scroller doucement car c pas super opti pour la vm de decoder les images aussi vite.
 
sinon oui les nouvelles images sont en bas car c'est plus simple a coder dans un premier temps, mais ouais je voudrais mettre le flux en haut a la base.
 
et sinon quand tu ouvre tu devrais etre a la fin, mais si tu FC ben ca enregistre pas ta position, il faudrait que tu retourne sur le home de temsp a autre pour sauver ta position avant le FC.
(je sais c'est pas terrible, mais ca devrait suffir le temps que je trouve un moyen de corriger)

ben non puisqu'il ne les kille pas de force il faut que ce soit l'appli qui le veille bien et non l'OS qui na pas son mot a dire (la preuve avec mes lecteur MP3 que je ne peut pas arretés avec l'OS en fermant simplement l'appli, il faut que j'appuis sur stop avant) et qu'une appli qui consomme sans que je lutilise il ne me l'indiquera pas tout seul. Et le bouton Retours permet de stopper certaines appli (pas en pause) tandi que Home permetra avec ces meme appli de les conservés en pause ou sois actives. j'ai l'impression que c'est le dev qui décide de comment réagira son app selon qu'on appuis sur Home ou Retour et non l'OS.  

c'est ca le pb, suffis qu'une appli soi mal codée...
 
 
 
---------------------------
 
dys,
j'ai essayer Gaze mais quand je prend une tofo elle n'apparait pas dans la liste c'est normal ? Et la MAP ne se fait pas et donc c'est toujours floue

il faut surement que tu attende les chargements des images.
 
Je vais bosser pour rendre l'ui plus clair sur ce qui se passe en tache de fond.
 
sinon j'ai reglé le pb de memory leak

 
J'ai un exemple d'application qui ne fonctionne pas trop comme elle devrait, sur ce point  
 
J'utilise Traffoid le matin pour visualiser l'état de la circulation. Une journée, j'ai constaté que ma batterie se vidait environ 4 fois plus que d'habitude.
- J'ai vérifié l'occupation CPU, rien de louche.
- J'ai utilisé le logiciel tcpdump sous Android, pour analyser les échanges réseau ... c'est là que j'ai vu que l'application Traffoid (qui n'apparaissait pourtant plus à l'écran), continuait de me télécharger la carte bison futé du coin toutes les 5 minutes.
 
J'ai dû sortir un Taskiller pour arrêter ça. (mais ça reste exceptionnel  )
 
(A noter que j'avais signalé le dysfonctionnement au développeur)

Vous avez déjà essayé de télécharger des apps sur des sites de torrent?
Y'a des risques de se faire griller une fois l'app installée sur le phone

Pour moi, y'a surtout le risque d'installer une appli vérolée sur ton téléphone.

 
non ça n'est pas le cas, cf. mon post:
 

 
je pense que lorsque l'OS met en pause une application, il n'y a que le thread correspondant à l'Activity en cours qui est mis en pause, tous les autres threads instanciés par l'application continuent eux à tourner même lorsque l'appli est en background.

Tu te trompes, c'est ce que je te dis depuis le début, le dev n'a pas la main sur ces intéractions. Home retourne sur le Home, Retour revient d'un cran en arrière, j'ai déjà expliqué ça, et c'est simple à vérifier.

Y'a aucun intérêt à killer une application quand t'appuies sur un bouton et pas sur l'autre. Prends les applications qui ont une phase d'initialisation, quel est l'intêret de les redémarrer à chaque fois? Ça ne coûte rien de les avoir en mémoire si elles ne font rien, y'a pas de consommation pour une appli qui n'est pas utilisée.

Comme j'ai expliqué plus haut, les lecteurs MP3 sont DIFFÉRENTS, puisqu'ils font appel à un SERVICE de son qui peut tourner en tache de fond.

Tu démarres ton lecteur il est actif
Tu lances une playlist il démarre un service
Tu reviens sur le home, ou tu écris un sms, l'app tourne toujours
La playlist se termine, y'a une latence puis l'application passe en pause
Elle ne doit plus rien comsommer à ce moment

C'est un exemple typique d'un problème de code, il faut savoir quand arreter le service de téléchargement.

Oui, j'ai pas dis le contraire
Tu regarderas dans le debugger, les process de service ( de toutes façons, comme tu le sais, la déclaration de démarrage d'un Service et d'une Activity n'est pas la même) et le process de l'appli qui peut contenir plusieurs threads. Dépendant du type de process, certains peuvent tourner avec l'app en background d'autres non ( e.g, une ListView )

faux. on ne peut effectivement pas overrider le bouton Home (sécurité de l'OS pour ne jamais être bloqué en utilisant une appli bugguée), mais on peut overrider le bouton Back

Tu vas me l'embrouiller
Je sais qu'on peut, mais les best-practises veulent que tu vois un écran que tu as déjà vu. Tout comme tu peux killer ton app avec un MenuItem écrit "Send Email" dessus

Je peux aussi betement citer la doc :

 
http://developer.android.com/guide [...] #Lifecycle

 
Je développe des applis, j'ai testé de faire une Activity qui démarre un thread qui boucle : quand on appuie sur la touche home et que l'Activity passe en pause, bein le thread tourne toujours et bouffe du CPU jusqu'à 100% si c'est un while(true). Je précise bien qu'il ne s'agit pas d'un Service. Donc le principe de la pause d'une appli quand elle n'est pas visible semble facilement contournable...
 
 

Je pense qu'on a la main là-dessus justement, il suffit de réimplémenter onStop()
http://developer.android.com/refer [...] ivity.html

Ça coborre ce que je dis depuis le début et le lien que j'ai posté juste avant ton post
Une app avec un while(true) claquera un FC au bout de 5 secondes, c'est pas un thread/process/app inactif/en pause.

Bein non, j'ai un thread entrecoupé de sleep qui récupère des données via bluetooth qui affiche des infos chaque seconde dans le Log et j'ai beau être sur le Home le thread tourne toujours indéfiniment en écrivant sur le log. Si ça tourne à 100% effectivement le système cherche à le tuer.

OSEF. Il y a topic pour la programmation Android dans la partie programmation d'HFR.

En même temps on s'en fout que tu t'en foutes C'est pas hors sujet et ça répond à la question d'un utilisateur un peu plus curieux que la moyenne.

Bah si c'est HS. C'est un topic de présentation/demande d'applis. Pas de programmation.

 
Mais bourdel, ce qu'on se tue à te répèter ici, c'est que tout le monde ici est bien d'accord pour dire que ça, c'est le fonctionnement théorique NORMAL, mais que ça n'est pas le cas dans la pratique pour les process dont on parle, notamment les player multimedia, qui continuent à consommer beaucoup une fois la playlist arrêtée depuis longtemps (ou même qui se lancent dés le démarrage du tel et consomment en fond).

Congratulations, tu viens de réinventer le service et tu perds au passage tous les bénéfices de l'OS management
Non sérieux, tu peux faire, mais est-ce que tu veux le faire? C'est en partant dans des trucs comme ça qu'on aura des app foireuses et mal codées.
Ça rejoins les surcharges de onStop() et l'implémentation de kill implicite.
Avoir choisi Java comme langage permet aussi de limiter les trucs farfelus, le reste c'est l'implication du bon sens et de la rigeur de developpeur.
 
J'essaie d'être le plus terre à terre possible et d'éviter les débordements sur les possibilitées qu'offre l'OS et le SDK, c'est pour expliquer à ceux qui se posent la question de comment l'OS gère les applis. J'admets que d'un point de vue développeur c'est pas 100% exact, mais c'est ce qui est recommandé.
 
Maintenant ça commence à devenir technique mais je pense que les curieux auront une vision un peu plus techniques et approfondie de la manière dont marche leur OS. Installer des taskillers et d'autres trucs farfelus où passer son temps dans le menu Applications à tuer des apps à un intêret très limité, si ce n'est inexistant.
 
Il faut se rendre compte que les mecs qui ont repri et developpé cet OS sont quand même à l'origine du moteur de recherche le plus utilisé au monde, derrière y'a un noyau linux qui AFAIK gère très bien la mémoire

moi je comprends pas l'intéret d'un taskkiller.
 
Si on constate qu'une appli est mal codé, on la désinstale. Ca poussera le dev à mieux dev.

Attends, tu me demandes de revenir sur deux jours d'archives pour lire un benchmark basé sur des données que tu n'as pas l'air de comprendre, ou que tu interpretes de manière éronnée, tout ça pour venir me dire que selon toi une fois que le lecteur à fini de lire ta playlist il continue à consommer - à consommer quoi d'ailleurs?

C'est pour ça que je demande des chiffres, ceux dont tu parles sont inutiles pour plusieurs raisons et ne montrent PAS que ton lecteur continue à consommer une fois revenu au silence.

Qu'est ce que tu crois qu'il fait ton lecteur une fois qu'il n'a plus rien à lire? Il se mets en pause sagement dans un coin de la mémoire en attendant gentiment que tu lui donne un truc à manger, jusqu'a être killé automatiquement si besoin est.

J'ai testé Winamp, le lecteur HTC, Songbird et andless y'a plusieurs semaines, je n'ai jamais éteint mon téléphone ni killé ces apps à la main depuis, et c'est pour autant que ma batterie est drainée.

C'est le sujet justement : les applis mal codées Je me suis rendu compte que ce comportement n'était pas celui que j'attendais, je voulais juste un thread temporairement mais j'ai constaté qu'il continuait d'exister même lorsque l'appli n'était plus visible. Donc les applis mal codées consomme du CPU et le système n'a pas la main là dessus !