Posiłkowałem się tym artykułem FAQ: Why You Shouldn’t Be Using a Task Killer with Android
Patrząc na to co dzieje się na forum i na to jak często powtarza się pytanie o to jak wyłączyć / zabić procesy działające w tle postanowiłem przetłumaczyć artykuł z serwisu geekfor.me - jest to luźne tłumaczenie, nie słowo w słowo, jednak przekaz pozostaje zachowany.
Zacznijmy od najważniejszych faktów i obaleniu mitów...
Aplikacja, która jest w tle, zużywa tylko i wyłącznie pamięć ram, użycie procesora to 0-0,01% - ma to zerowy wpływ na baterię
RAM jest po to, żeby go używać. Czasy windowsa 98 i XP minęły. Tak więc czym telefon ma więcej ramu, tym więcej będzie miał zajęte, jednak MAŁA ILOŚĆ WOLNEJ PAMIĘCI NIE MA WPŁYWU NA WYDAJNOŚĆ SYSTEMU
System bez auto task killera działa lepiej i szybciej niż z aktywnym auto task killerem - jest to opinia wielu doświadczonych użytkowników Androida
[spoiler=Techniczne sprawy, jeszcze nie przetłumaczone]Poniżej skopiowane parę najważniejszych informacji z instrukcji dla developerów Androida. Najważniejsze zdania są pogrubione. Tekst jest trochę długi, jednak jest ważny i tłumaczy wszystkie kwestie. Pełna wersja znajduje się tutaj . Jeśli nie chce się wam czytać, to poniżej jest podsumowanie (po polsku) tego tekstu w kilku punktach.
By default, every application runs in its own Linux process.
Android starts the process when any of the application’s code needs to be executed, and shuts down the process when it’s no longer needed and system resources are required by other applications.
A content provider is active only while it’s responding to a request from a ContentResolver. And a broadcast receiver is active only while it’s responding to a broadcast message. So there’s no need to explicitly shut down these components.
Activities, on the other hand, provide the user interface. They’re in a long-running conversation with the user and may remain active, even when idle, as long as the conversation continues. Similarly, services may also remain running for a long time. So Android has methods to shut down activities and services in an orderly way:
An activity can be shut down by calling its finish() method. One activity can shut down another activity (one it started with startActivityForResult()) by calling finishActivity().
A service can be stopped by calling its stopSelf() method, or by calling Context.stopService().
Components might also be shut down by the system when they are no longer being used or when Android must reclaim memory for more active components.
If the user leaves a task for a long time, the system clears the task of all activities except the root activity. When the user returns to the task again, it’s as the user left it, except that only the initial activity is present. The idea is that, after a time, users will likely have abandoned what they were doing before and are returning to the task to begin something new.
Activity lifecycle
An activity has essentially three states:
It is active or running when it is in the foreground of the screen (at the top of the activity stack for the current task). This is the activity that is the focus for the user’s actions.
It is paused if it has lost focus but is still visible to the user. That is, another activity lies on top of it and that activity either is transparent or doesn’t cover the full screen, so some of the paused activity can show through. A paused activity is completely alive (it maintains all state and member information and remains attached to the window manager), but can be killed by the system in extreme low memory situations.
It is stopped if it is completely obscured by another activity. It still retains all state and member information. However, it is no longer visible to the user so its window is hidden and it will often be killed by the system when memory is needed elsewhere.
If an activity is paused or stopped, the system can drop it from memory either by asking it to finish (calling its finish() method), or simply killing its process. When it is displayed again to the user, it must be completely restarted and restored to its previous state.
The foreground lifetime of an activity happens between a call to onResume() until a corresponding call to onPause(). During this time, the activity is in front of all other activities on screen and is interacting with the user. An activity can frequently transition between the resumed and paused states — for example, onPause() is called when the device goes to sleep or when a new activity is started, onResume() is called when an activity result or a new intent is delivered. Therefore, the code in these two methods should be fairly lightweight.
The following diagram illustrates these loops and the paths an activity may take between states. The colored ovals are major states the activity can be in. The square rectangles represent the callback methods you can implement to perform operations when the activity transitions between states.
Tutaj to samo co na obrazku, tylko, że wyjaśnione w filmie:
[ame]
[/ame]
Podsumowanie tego co wyżej - czyli wersja w skrócie:
Android jest zaprogramowany do tego, żeby automatycznie zabijać procesy kiedy potrzebne jest więcej pamięci RAM (do odpalenia np pamięciożernej aplikacji).
Android jest zaprogramowany do tego, żeby automatycznie zabić proces, kiedy ten zrobi to co do niego należy.
Android jest zaprogramowany do tego, żeby automatycznie zabić proces, kiedy ten nie jest używany przez dłuższy czas.
Większość usług (które najczęściej działają w tle), kiedy nic nie robi (czyli przez 99% czasu) zjada bardzo małą ilość pamięci RAM.
Content provider działą/robi coś tylko wtedy kiedy jakaś aplikacja tego wymaga. W przeciwnym wypadku zużywa bardzo mało pamięci RAM.
Zabicie procesu, kiedy ten nie skończył tego co miał zrobić, powoduje jego ponowne załadowanie się i zaczynanie od nowa tego, co robił wcześniej.
Procesy, które działają w tle (nawet jeśli ich wcześniej nie włączaliście) działają tam z jakieś przyczyny. Zabicie danego procesu spowoduje jego ponowne uruchomienie tak szybko jak aplikacja, używająca tego procesu odwoła się do niego. I wtedy będzie musiał się załadować od nowa. Czyli program będzie się dłużej włączał!
Zabijanie niektórych procesów może mieć zły wpływ na system i efekty uboczne. Na przykład nie działający zegar, budzik, brak nowych smsów, nie odświeżające się widgety czy wymuszanie zamknięcia działających programów.
Jedyny sposób, żeby tak naprawdę zmusić program do samoistnego nie włączania się, to odinstalowanie go.
Dzięki procesom działającym w tle, programy uruchamiają się szybciej! I samo uruchomienie zjada mniej zasobów, ponieważ część programu jest już wcześniej załadowana.
Większość programów zamyka się samoistnie kiedy wychodzimy z nich używając przycisku "wstecz". A nawet jeśli wyjdziemy używając "Domku" to Android zabije daną aplikację po dłuższym czasie jej nie aktywności.
Jeszcze jedna kwestia. Głównie do użytkowników Windowsa! Pamięć w linuxie działa trochę inaczej niż w Windowsie. Generalnie chodzi o to, że programy używają tyle pamięci ile mają zaprogramowane zabrać. Np jeśli program do uruchomienia potrzebuje 100MB pamięci, to 150MB to dla niego aż za dużo. Nie ma potrzeby czyszczenia pamięci RAM, żeby mieć te 150MB wolnego. Za to jeśli chodzi o Windowsa, zdaje się, że system działa lepiej jeśli ma mniej procesów w pamięci RAM. Zapewne niektórzy z was mający małą ilość ramów na PC, używają również task killerów - programów dla Windowsa, które oczyszczają pamięć RAM.
Jednak Linux sam w sobie nie jest dotknięty tym problemem. Nie wgłębiając się w architekturę tego systemu, faktem jest to, że linux będzie działał identycznie mając 20MB lub 300MB wolnego RAM. A, że Android jest spokrewniony z linuxem to działa tak samo! I tak jak jest to wypunktowane wyżej - Android automatycznie zaczyna zabijać aplikacje/procesy kiedy zaczyna mu brakować pamięci.
Cytując Chris'a Johnston'a "Buffers and cache in RAM being cleared is silly. Imagine a professor, who rather than writing all the way across the chalkboard, finishes a sentence and immediately erases and starts writing in the upper left corner AGAIN and AGAIN and AGAIN OR imagine you like a song. You record it to the beginning of a cassette tape. When you want a new song, do you re-record over the first song or record after it?" // w wolnym tłumaczeniu: "Czyszczenie buforu, pamięci podręcznej (RAM) jest głupie. Wyobraźcie sobie profesora, który zamiast zapisać cała tablicę, po napisaniu jednego zdania, zaraz by je zmazał i w jego miejscu zaczął pisać następne zdanie i tak w kołko. Albo wyobraźcie sobie, to jako piosenkę nagraną na początku kasety. Kiedy chcecie dograć nowy kawałek to nagrywacie go na poprzedni czy w wolnym miejscu?"
Jeszcze raz kwestia baterii - ludzie uważają, że czym więcej RAMu używane, tym szybciej rozładuje im się bateria. Jednak RAM nie ma nic do tego. Co innnego jeśli mowa o użyciu CPU przez daną aplikację - to jest tutaj kluczowe. Żeby sprawdzić co aktualnie spowalnia twój telefon / wyładowywuje baterię potrzebny jest odpowiedni program. Osobiście używam System Panel Lite , jednak jest parę innych aplikacji, które również pokazują użycie CPU przez dany program.
Jak widać na obrazku, największe zużycie ma System Panel Lite (bo monitoruje całość, tak więc używać CPU będzie w tym podmenu), a reszta programów ma praktycznie zero użycia CPU. Tak więc nie ma się czym przejmować. Osobiście używam tego programu raz, może dwa razy miesięcznie, jak ściągnę jakiś nowy program z marketu i nagle telefon zaczyna mulić - w 99% przypadkach jest to właśnie wina tego nowego, nie sprawdzonego programu. A tak to od około roku, używam Androida bez żadnego auto task killera i system działa idealnie, bez żadnego mulenia czy zwieszek. Do tego wszystko się odpala błyskawicznie i nie ma problemów z programami.
Mam nadzieję, że po przeczytaniu tego tekstu (tak wiem, dużo tego) chociaż połowa osób, zdecyduje się wyłaczyć auto task killera i zobaczy jak Android może działać bez niego 😉
----------------------------
Dopiszę jeszcze później coś o programach do zmiany ustawień auto killera wbudowanego w system ;]
MinFreeManager, AutoKiller Memory Optimizer, Auto Memory Manager
----------------------------
Posiadacze HTC Desire / Desire HD / HD2 i chyba Nexusa One mogą sprawdzić sobie zużycie baterii poprzez telefon/system. Program niestety nie działa na reszcie telefonów z Andkiem.
Ściągamy sobie z marketu
CurrentWidget
Dodajemy go na pulpit i widzimy aktualne użycie prądu. Standardowo widget sprawdza użycie co 60 sekund (można to zmienić, w opcjach Update Interval). Można również ustawić tworzenie logu do pliku na karcie pamięci - przydatne do długotrwałych pomiarów.
Blokujemy telefon, odblokowywujemy go po ponad minucie i sprawdzamy w widgecie (lub w logu) użycie prądu. Jeśli wszystko jest ok to powinien wskazywać około 2-3mA (Dane OFF, WiFi OFF, BT OFF). Z włączonymi tymi trzema zjada od 5-8mA (oczywiście w IDLE, czyli jeśli nic się nie aktualizuje i nie przesyła)
Jeśli podczas uśpienia jest około 50-60mA i się to utrzymuje to można poszukać winowajcę w programach, które działają w tle. U mnie 60mA jest podczas aktywnego teetheringu po WiFi - i to akurat jest normalne (w końcu moduł WiFi nadaje cały czas)
Przykładowo zużycie prądu dla HD2 - sam odpalony wyświetlacz i powiedzmy scrollowanie pulpitów / chodzenie po menu to 180-250mA. Transmisja aktywna po WiFi i ładowanie stronki ~200-250mA. Transmisja po HSDPA przy słabym zasięgu - 500-600mA (taaak, to tyle zjada). Przy EDGE jest ok, bo około 250-300mA. Granie w jakąś gierkę, np Gameloftu to około 300-350mA.
Zapraszam do dyskusji :cool::hyhy: