[andy]

Napisany przez Bartez

W androidzie wystarczy uruchomić listę kontaktów, żeby przymuliło. Sprawdzane na xperii, galaxy s3 mini, galaxy s3. Dopiero jak się skeszuje, to działa w miarę płynnie.

Przymuliło? Nie do końca rozumiem o co Ci chodzi.

Przymuliło == skakanie przy przewijaniu?
Przymuliło == aplikacja wczytuje się cała, stąd przez pierwsze dwie sekundy może nie być aktywna?

Jeżeli to drugie to dzieje się tak poniważ aplikacja nie jest wczytywana z pamięci RAM i jej uruchomienie trwa wtedy dłużej.
Na iP jest podobnie. Tam tylko ukryto ten fakt pokazywaniem zdjęcia pierwszego okna aplikacji.


Dla pewności zamieść filmik.

Z ciekawości sprawdziłem teraz. Mam Go Dialer EX i Go Pro SMS. Przy wejściu na listę ostatnich połączeń zamuliło ok 2s. Z listą smsów trochę lepiej, ale też nie od razu. Na stockowym dialerze to samo. Za drugim razem już weszło od razu, ale po jakimś czasie znowu się to powtarza.

Czyli jednak to o czym mówiłem? Jeżeli aplikacja nie jest wczytywana z RAMu to normalne że załaduje się nie od razu. W iP tak samo to działa, tam tylko oszukują przez pokazanie zdjęcia pierwszej aktywności/widoku aplikacji, co daje złudzenie że ona już działa.

Napisany przez sobrus

Android ma słabe zarządzanie pamiecią. Dla mnie to przykład jak nie powinno się tego robić.
Trzeba zmienić domyślne ustawienia oom killera, na coś bardziej rozsądnego (w zasadzie zmniejszyć ile sie da).

Konkretnie chodzi o to ustawienie:
/sys/module/lowmemorykiller/parameters/minfree

aktualnie mam 256,512,1024,2048,4096,8192 i działa mi lepiej, najchętniej wszystko bym ustawił na 0, ale nie wiem czy coś się nie zacznie wysypywać.

Nie zgodzę się. Zarządzanie pamięcią w Androidzie jest jak dla mnie rozwiązane dobrze.

Jak wiadomo Android do tych systemowych rzeczy używa jajka linuksa. Tam jest jak wspomniał wyżej sobrus coś takiego jak OOM(Out Of Memory Killer). Zabija on aplikacje kiedy limit pamięci w systemie operacyjnym spadnie do krytycznej wartości.


To co poniżej napisane na podstawie tego posta: http://forum.xda-developers.com/showthread.php?t=622666 Polecam go przejrzeć całego - tylko pierwszy post, aby zrozumieć jak działa to zarządzanie pamięcią jeżeli moje wyjaśnienie nie będzie jasne.

ActivityManagerService.java tracks the "importance" of processes (is foreground, is running a service, ..) and reflects this importance by setting the "oom_adj" value of the process.

Jak widzimy ActivityManagerServices zarządza ważnością procesów, oraz tym czym są - aplikacje w tle, te na wierzchu i ustala im odpowiednie wartości oom_adj.

(For info: "oom_adj" is a value of every process under Linux which gives the kernel a hint, which process it can kill in an oom [out of memory] situation. You can see this value on every Linux 2.6 system in the proc directory: /proc/[PID]/oom_adj ). The higher this value is set, the more likely this process gets selected by the kernel's oom killer.)

Jak wiadomo w systemie aplikacja aplikacji nie równa. Jeżeli np. odpalasz FB i braknie pamięci to nie chciałbyś aby zwalnianą aplikacją był właśnie FB, tylko taka do której nie ma żadnych odniesień.

Android dzieli aplikacje na 6 kategorii:

FOREGROUND_APP:
// This is the process running the current foreground app. We'd really
// rather not kill it! Value set in system/rootdir/init.rc on startup.

VISIBLE_APP:
// This is a process only hosting activities that are visible to the
// user, so we'd prefer they don't disappear. Value set in
// system/rootdir/init.rc on startup.

SECONDARY_SERVER:
// This is a process holding a secondary server -- killing it will not
// have much of an impact as far as the user is concerned. Value set in
// system/rootdir/init.rc on startup.

HIDDEN_APP:
// This is a process only hosting activities that are not visible,
// so it can be killed without any disruption. Value set in
// system/rootdir/init.rc on startup.

CONTENT_PROVIDER:
// This is a process with a content provider that does not have any clients
// attached to it. If it did have any clients, its adjustment would be the
// one for the highest-priority of those processes.

EMPTY_APP:
// This is a process without anything currently running in it. Definitely
// the first to go! Value set in system/rootdir/init.rc on startup.
// This value is initalized in the constructor, careful when refering to
// this static variable externally.

Dla każdej zmiennej można zdefiniować próg po przekroczeniu którego zostają one zabijane przez oom.
Jeżeli masz kilka procesów do odstrzału z kategorii 3, to android sprawdza, który się pierwszy nadaje z nich do odstrzału (i je ubija).

Aby sprawdzić jak u nas wyglądają te ustawienia wystarczy wyświetlić zawartość pliku: /sys/module/lowmemorykiller/parameters/minfree

Wartości tam podane to strony pamięci. Aby uzyskać ilość MB należy przemnożyć tą wartość przez 4 i podzielić przez 1024.

Wartości te określają minimalną wartość dostępnej pamięci w systemie, zanim OOM zacznie ubijać aplikacje z danego typu.

Jeżeli dla EMPTY_APP jest ustawione 70MB, to OOM zacznie je zwalniać gdy poziom wolna pamięć spadnie poniżej tego poziomu.

Po dokładnym przeczytaniu tego posta na XDA, stwierdzam że CONTENT_PROVIDER i EMPTY_APP można ustawić na duże wartości dzięki czemu wartościowe aplikacje zostaną zachowane.

U siebie mam tak: 512,1024,2048,4096,16640,23040
Co daje odpowiednio: 2MB,4MB,8MB,16MB,65MB,90MB

Oczywiście te wartości zależą od ilości pamięci posiadanej w telefonie. Te które podałem nie będą optymalne dla telefonów z 512MB pamięci.