Ah, stimmt. Das ist ein bisschen praktischer als das dieser Status-Dialog.bemymonkey schrieb:
Was ziemlich fatal wäre, da dann kein Wecker, keine SMS/MMS, kein Anruf, keine Pushdienste, keine automatiche Synchronisation, kein zeitgesteuerter Profilwechsel, kein (beliebiges auf äußeres Ereignis wartendes App einsetzen) funktionieren würde.HassaniSabbah schrieb:
Das stimmt so nicht. Power kostet es nur, wenn dem App auch CPU-Zeit zugeteilt wurde und das RAM ist eh' da - wenn es anderweitig benötigt wird, wird es eben kurz frei geschaufelt. Ob das RAM mit "leer" oder "belegt" ist, spielt powertechnisch keine Rolle (der Inhalt muss eh regelmässig erneuert werden - ob da nun 0 oder 1 reingeschrieben wird, ist egal).
Gibt es, sind aber in meinen Augen kontraproduktiv, da Android das sehr gut alleine macht - aber darüber man streitet man sich schon an sehr vielen Stellen (auch hier im Forum)
HassaniSabbah schrieb:
Dem schließe ich mich an. Wieso muss die Galerie, die ich vor zwei Tagen das letzte Mal nutzte, ständig im RAM bleiben und somit anderen Anwendungen beim flotteren Arbeiten im Wege stehen. Sooo viel Rechenpower und Wartezeit beansprucht ein Neustart der App nun auch wieder nicht.HassaniSabbah schrieb:
HassaniSabbah schrieb:
Das funktioniert bei meinen Anwendungen zu 99% bis 100% nicht!winne schrieb:Wenn du die Apps schließen willst, dann nimm die Backtaste. Das klappt mit 99% aller Apps.
Wenn die Galerie nach zwei Tagen noch im Speicher 'rum dödelt, dann hat das Android System eben entschieden, dass die Anwendung eben nicht den anderen im Wege ist. Wenn die Galerie andere Anwendungen behindert, d.h. Systemressourcen braucht, die besser aktiven Anwendungen zugestanden werden, dann beendet der Scheduler die Anwendung schon selbst. Und deswegen sollte man dem Scheduler auch nicht mittels eines Taskkillers in seine Arbeit pfuschen, sonst kann der nämlich nie ein vernünftiges Verhalten bzgl. der Speicherauslastung lernen. Siehe Garbage Collection.email.filtering schrieb:
Das Problem bei WinMobile ist der schlechte Speichermanager, der es nicht geschafft hat, den Speicher auch ordentlich wieder frei zu räumen. Und dass WinMobile (zumindest in den alten Versionen, die ich noch kannte auf meinem iPaq) auf kooperatives Multitasking der Anwendungen angewiesen waren. Die Applikationen mussten sich quasi freiwillig beenden.email.filtering schrieb:
Der Speichermanager macht genau das. Solange noch Systemresssourcen vorhanden sind, können die belegt werden. Es macht keinen Sinn, ständig xyz an MB "feien" Speicher vor zu halten. Speicher ist dazu da, dass er belegt werden kann. Im Idealfall hat man immer einen zu 100% belegten Speicher - und keine Anwendung benötigt weiteren Speicher. Dann sind die Daten optimal schnell im Zugriff. Wird eine weitere Anwendung gestartet, dann entscheidet der Speichermanager, welche Anwendung im Background State beendet werden kann. Du sollst nicht schlauer als der Hausmeister sein.email.filtering schrieb:
...und ist vor allen Dingen kontraproduktiv, weil der Speichermanager nie zu einem vernünftigen Haushalten kommt, weil ihm jemand ständig dazwischen pfuscht.email.filtering schrieb:
Das liegt daran, dass das "System" selbst ohne gestartete Apps schon relativ viel Speicher benötigt. Da ist praktisch bei jeder zweiten App, die gestartet wird, ein Jonglieren mit Speicher angesagt. Da stimme ich Dir zu - aber das ist dann meiner Meinung nach schlicht "Broken by Design" vom Hardwarehersteller, nur so ein bisschen Speicher ein zu bauen.email.filtering schrieb:
So ist das auch vorgesehen.Hagbard235 schrieb:
Der call der App geht quasi in "Nullzeit" über eine Speichersemaphore. Die Applikation ist ja noch im RAM. Was in der Tat dauern kann ist, dass sich die App ordentlich beeendet und sauber aufräumt (Speicher ordentlich frei gibt und zu sichernde Daten speichert). Das ist aber kein Problem des Android Systems sondern der App. Idealerweise räumt die App sich schon auf, wenn sie in den Hintergrund geschoben wird. Das kann sie nämlich per Event feststellen. Nur sollte man (also die App) auch auf diesen Event lauschen und entsprechend tätig werden. Dann ist auch das Beenden der App in winzigen Bruchteilen einer Sekunde erledigt und man merkt nichts davon. Aber wie auf allen Plattformen: Programming Guidelines sind dazu da, dass sie von so ziemlich vielen Entwicklern schlicht ignoriert werden...Hagbard235 schrieb:
Prinzipiell gebe ich Dir da recht. Du verlagerst aber die "Zeitaufteilung" auf Deine aktive Zeit und behinderst einen technischen Lernprozess des Speichermanagers. Aber klar, ich kenne das, es ist einfach nur nervig, wenn man auf das Starten von Apps warten muss.Hagbard235 schrieb:
Dann ist RedAltert sch... programmiert und dem Entwickler gehört das über konstruktives Feedback mitgeteilt. Er soll sich mal mit dem Zustandsdiagramm von Android Apps beschäftigen. Ich habe mich da noch nicht wirklich arg eingelesen, aber so schwer ist das nicht. Und wenn man sich daran hält, dann passieren solche Dinge einfach nicht. Aber schlechte Software gleich auf die Plattform zu schieben... Nee, das ist zu einfach.Hagbard235 schrieb:
Hille schrieb:
So ganz stimmt das nicht.Hille schrieb:
Kooperativ war das Multitasking von WM wenn ich mich recht erinnere nur was die Meldungsschlangen (Eingaben, Systembenachrichtigungen, ...) anging. Problematisch war bei WM vor allem, dass es wie das "richtige" Windows davon ausging, dass jedes Programm jederzeit Eingaben bekommen und die Anzeige aktualisieren könnte. D.h., sebst im Hintergrund liegende Apps warteten auf Eingaben die sie nie bekommen konnten und aktualisierten Bildschirmelemente, die evtl. erst nach hunderten weiteren Änderungen jemand zu sehen bekommt - wenn überhaupt. Bei Android hingegen wird der sichtbare Teil der App komplett gestoppt (= 0 CPU) wenn sie nicht mehr sichtbar ist.
Nunja, manchmal wäre auch ein bisschen Kontrolle, welche Apps zuerst aus dem Speicher geworfen werden sollen, nicht schlecht. Wenn ich den Browser nur ab und an brauche, hätte ich z.B. doch lieber den zuerst entfernt als den aktuellen Home-Screen...
