On Sat, 06 Sep 2014 10:01:37 +0200, GAD Zombie
<g...@g...BEZ.art.SPAMU.pl.PROSZE> wrote:
> Obserwuję to już od kilku dni uważnie. Konsola Atari 2600 jest
wyłączona
> całkiem. Ale jak się ją włączy, to pozostaje w pamięci jakiś jej
proces,
> który jest aktywny (widać po statystykach w Wakelock Detector). Jak
się
> go nie ubije, to jest aktywny nawet parę dni. Wytłumacz mi, po co
to
> może być, skoro programista musiał tego chcieć? Jak to ubiję, to
> wszystko działa jak należy, nic się nie psuje, ale to zostaje
wyłączone.


Zanim spróbuję odpowiedzieć na Twoje pytanie kilka słów wstępu o
zarządzaniu uruchomionymi aplikacjami przez system Android.
O zakończeniu i usuwaniu aplikacji z ram decyduje system a nie user.
To taki paradygmat Androida. Chodzi o to by kolejne jej uruchomienie
było szybsze. Z potrzeby izolacji każdy proces to dedykowana
instancja maszyny wirtualnej javy (dalvik), częste uruchamianie
takiego procesu jest dość cpu-żernym zadaniem więc tego się unika.
Szybciej wywoływać uśpiony w pamięci proces niż go od nowa ładować.
System wie ile ma wolnych zasobów, jeśli ram się kończy usuwa
najrzadziej uruchamiane aby zrobić miejsca nowym. Z tego powodu
programiści nie stosują trwałego "zamykania" aplikacji, można to
wymusić, ale takie działanie jest niezgodne z przyjętym paradygmatem.
System ma tym zarządzać i koniec. Aplikacja zakończona nie zabiera
cpu, jest "zamrożona" w ram. Nie będzie widoczna w oryginalnym
menadżerze aktywnych aplikacji. Niestety mogą ją niepotrzebnie
pokazywać jakieś "eksperckie" narzędzia, użytkownikowi wychowanemu na
PC może się to kojarzyć źle, stąd zaraz ma odruch usuwania takich
aplikacji. Takie działanie nie ma sesnsu dla poprawnie napisanych
aplikacji. Tutaj zaczyna się pierwszy haczyk.
Aplikacjie "zakończone" (ale ciągle trzymane "pod ręką" przez system
w ram) nie będą używać cpu (baterii) pod warunkiem, że są to
aplikacje bez serwisów, np. apka do rysowania na ekranie: działa
(jest aktywna) gdy jest "na ekranie", gdy jej nie ma (przełączono się
na coś innego) jej aktywność traci sens, więc jest zatrzymywana.
Serwis to taka wyodrębniona cześć aplikacji, która ma za zadanie
obsłużyć w tle jakieś zdarzenie w systemie np. odbiór sms. Jeśli apka
ma serwis to będzie on aktywowany aby gdy nastąpi odpowiednie
zdarzenie. Serwis też nie jest problemem dla baterii, bo jego kod
wykonywany jest tylko gdy nastąpi zdarzenie i z reguły krótko.
Narzędzia pokazujące listę procesów taki serwis będą najczęściej
wyświetlały pod nazwą aplikacji, do której należy (bo de facto to
cześć procesu tej aplikacji). Jak widać nieaktywna aplikacja baterii
zużywać nie może, a nawet jeśli ma serwis to jest on aktywny tylko
przy zdarzeniu więc też drastycznie bateri nie użyje. I tutaj
dochodzi drugi haczyk czyli nieszczęsne "wakelocki".
System telefonu jako narzędzia zasilanego z baterii ma mechanizm,
który jak najszybciej chce aktywne ale "niedotykane" przez
użytkownika urządzenie przełączyć w stan o niskim poborem energii
nazywany potocznie uśpieniem. Jest kilka poziomów głębokości
uśpienia, najgłebszy (najmniej zużywający baterii) to taki, w którym
ekran jest wyłączony i cpu zatrzymany. Wakelocki (dosl. "pozostań
aktywny") to takie blokady zakładane przez aplikacje, które blokują
automatyczne usypianie (wyłączanie) lcd lub cpu (i innych
peryferiów). Wakelock na lcd spowoduje ciągle włączony ekran ale nie
ma wypływu na cpu. Wakelock na cpu nie uśpi cpu mimo, że lcd zostanie
wyłączony. Np. aplikacja odtwarzająca mp3 musi włączyć wakelocka na
cpu ale nie musi na lcd. Jeśli nie założy na cpu to po chwili braku
akywności ze strony usera cpu zostanie zatrzymany i odtwarzanie
zostanie przerwane. Oczywiście po zakończeniu odtwarzania (lub
aplikacji) wakelock musi być "zdjęty" bo inaczej cpu nigdy nie
wejdzie w stan uśpienia. I tutaj się zaczyna ów drugi haczyk:
aplikacja sama musi wakelocka zdjąć bo tylko ona (czyt. programista)
wie czy cpu jest jej jeszcze potrzebny czy nie, system za nią tego
nie zrobi. Jeśli programista popełni błąd i z powodu tego błędu nie
nastąpi zdjęcie wakelocka to cpu nie zostanie już w pełni uśpiony i
będzie drenował baterię mimo wyłączonego ekranu (!).
Przykład z potrzebą użycia wakelocka w odtwarzaniu mp3 jest chyba
prosty i zrozumiały.
Emulator, o którym piszesz ma najpewniej zarejestrowany serwis do
obsługi jakiegoś zdarzenia. Serwis ten aktywuje wakelocka gdy nastąpi
owo zdarzenie aby je obslużyć, a potem z jakiś powodów go nie
zdejmuje. Pytanie, po co emulatorowi serwis działający w tle...
autor to jakoś tłumaczy? Możesz podać linka do tej aplikacji? Może z
jej manifestu da się wywnioskować co się dzieje.

--
Marek