Najpopularniejsze mity dotyczące optymalizacji Androida obalone

Istnieje wiele przewodników instruktażowych poświęconych zwiększeniu wydajności Androida i ogólnych wskazówek dotyczących optymalizacji. Niektóre z nich są uzasadnione, a inne opierają się tylko na teorii lub przestarzałe metody operacyjne w systemie Android lub są po prostu nonsensem. Obejmuje to zalecenia dotyczące zamiany, wartości dodane do build.prop oraz zmiany zmiennych w jądrze Linux.

Istnieje nawet mnóstwo „skryptów optymalizacyjnych”, uniwersalne .zipy flashowane, które obiecują znacznie zwiększyć wydajność, żywotność baterii i inne rzeczy. Niektóre poprawki mogą faktycznie działać, ale większość z nich to po prostu efekt placebo lub, co gorsza, faktycznie ma negatywny wpływ na twoje urządzenie.

Nie oznacza to, że ludzie celowo wypuszczają nikczemne skrypty - w Sklepie Play są zdecydowanie fałszywe płatne aplikacje, ale skrypty optymalizacyjne wydane na forach z Androidem są generalnie dobre, tak się składa, że ​​deweloper może być źle poinformowany, lub po prostu eksperymentując z różnymi poprawkami optymalizacji. Niestety, zwykle występuje efekt kuli śnieżnej, zwłaszcza w skryptach optymalizacyjnych typu „wszystko w jednym”. Niewielka garść poprawek może coś zrobić, podczas gdy inny zestaw poprawek w skrypcie może absolutnie nic nie zrobić - jednak skrypty te są przekazywane jako magiczne pociski, bez żadnego prawdziwego badania tego, co działa, a co nie .

Tak więc wiele skryptów optymalizacyjnych typu „wszystko w jednym” używa tych samych metod, z których niektóre są w dłuższej perspektywie całkowicie przestarzałe lub szkodliwe. Podsumowując, większość skryptów optymalizacyjnych typu „wszystko w jednym” to nic innego, jak tylko zalecane kombinacje, bez jasnego pojęcia, w jaki sposób i dlaczego te optymalizacje „działają - użytkownicy następnie flashują skrypty i twierdzą, że ich wydajność jest nagle szybsza ( kiedy tak naprawdę najprawdopodobniej bardzo prosty restart komputera spowodował wzrost wydajności, ponieważ wszystko w pamięci RAM urządzenia zostało wyczyszczone) .

W tym ekskluzywnym artykule Appuals wyróżnimy niektóre z najczęstszych zaleceń dotyczących „ optymalizacji” wydajności Androida i czy to tylko mit, czy uzasadniona poprawka wydajności urządzenia.

Zamiana

Na szczycie listy mitów znajduje się wymiana Androida - co jest absurdalne, jeśli chodzi o optymalizację Androida. Głównym celem wymiany jest utworzenie i połączenie pliku stronicowania, który zwolni miejsce w pamięci. Na papierze brzmi to rozsądnie, ale naprawdę ma zastosowanie do serwera, który prawie nie ma interaktywności.

Gdy regularnie korzystasz z zamiany swojego telefonu z Androidem, doprowadzi to do poważnych opóźnień, które wynikają z rzeczy wymykających się z pamięci podręcznej. Wyobraź sobie na przykład, że aplikacja próbuje wyświetlić grafikę, która jest przechowywana w swapie, która teraz musi ponownie załadować dysk po zwolnieniu miejsca przez umieszczenie wymiany danych w innej aplikacji. To naprawdę bałagan.

Niektórzy entuzjaści optymalizacji mogą powiedzieć, że swap nie oferował żadnych problemów, ale nie jest to zamiana zwiększająca wydajność - to wbudowany mechanizm Androida lowmemorykiller, który regularnie zabija rozdęte, nieużywane procesy o wysokim priorytecie. LMK został zaprojektowany specjalnie do obsługi warunków niskiej pamięci, jest wywoływany z procesu kswapd i ogólnie zabija procesy przestrzeni użytkownika. Różni się to od OOMkillera (zabójcy braku pamięci), ale to zupełnie inny temat.

Chodzi o to, że urządzenie z, na przykład, 1 GB pamięci RAM nigdy nie może osiągnąć potrzebnych danych o wydajności w zamianie, więc zamiana nie jest absolutnie potrzebna w Androidzie. Jego wdrożenie jest po prostu obarczone opóźnieniem i prowadzi do pogorszenia wydajności, a nie jej optymalizacji.

zRAM - przestarzały i już nieefektywny

zRAM to sprawdzona i skuteczna metoda optymalizacji urządzeń dla starszych urządzeń - pomyśl o urządzeniach opartych na KitKat, które działają tylko na około 512 MB pamięci RAM. Fakt, że niektóre osoby nadal uwzględniają poprawki ZRAM w skryptach optymalizacyjnych lub polecają ZRAM jako rodzaj nowoczesnej optymalizacji, jest przykładem osób, które generalnie nie przestrzegają najnowszych protokołów operacyjnych.

zRAM był przeznaczony do wielordzeniowych układów SoC klasy podstawowej, takich jak urządzenia wykorzystujące mikroukłady MTK i 512 MB pamięci RAM. Zasadniczo bardzo tanie chińskie telefony. ZRAM zasadniczo oddziela jądro poprzez strumień szyfrowania.

Gdy zRAM jest używany na starszych urządzeniach z jednym rdzeniem, nawet jeśli zRAM jest zalecany na takich urządzeniach, duże opóźnienia występują zwykle. Dzieje się tak również z technologią KSM ( Kernel Same Page Merging), która łączy identyczne strony pamięci w celu uzyskania wolnego miejsca. Jest to w rzeczywistości zalecane przez Google, ale prowadzi do większych opóźnień na starszych urządzeniach, ponieważ stale aktywne podstawowe teady działają nieprzerwanie z pamięci w celu wyszukiwania zduplikowanych stron. Zasadniczo próba uruchomienia ulepszenia optymalizacji spowalnia urządzenie jeszcze bardziej, jak na ironię.

Siewnik - nieaktualny od Androida 3.0

Jedną z najczęściej dyskutowanych wskazówek optymalizacyjnych wśród deweloperów Androida jest seeder, i jesteśmy pewni, że ktoś mógłby spróbować udowodnić, że się mylimy w tym temacie - ale najpierw musimy zbadać historię sedera.

Tak, istnieje wiele raportów, które deklarują lepszą wydajność Androida po instalacji na znacznie starszych urządzeniach z Androidem . Jednak ludzie z jakiegokolwiek powodu uważają, że oznacza to również optymalizację dla nowoczesnych urządzeń z Androidem, co jest absolutnie absurdalne. Fakt, że Seeder jest nadal utrzymywany i oferowany jako „ nowoczesne” narzędzie do zmniejszania opóźnień, jest przykładem dezinformacji - chociaż nie jest to wina programisty Seedera, ponieważ nawet ich strona Play Store zauważa, że ​​Seeder jest mniej skuteczny po Androidzie 4.0+. Jednak z jakiegokolwiek powodu Seeder wciąż pojawia się w dyskusjach dotyczących optymalizacji nowoczesnych systemów Android.

Seeder zasadniczo robi dla Androida 3.0 błąd, w którym środowisko wykonawcze Androida aktywnie korzysta z pliku / dev / random /, aby uzyskać entropię. / Dev / random / buffer stałby się niestabilny, a system byłby blokowany, dopóki nie wypełni wymaganej ilości danych - nie myśl o takich rzeczach, jak różne czujniki i przyciski na urządzeniu z Androidem.

Autor Seedera wziął Linux-demon rngd i skompilował dla systemu Android, aby pobierał losowe dane ze znacznie szybszej i bardziej przewidywalnej ścieżki / dev / urandom i łączy je w dev / random / co sekundę, nie zezwalając na / dev / random / wyczerpać się. Spowodowało to, że system Android nie doświadczył braku entropii i działał znacznie płynniej.

Google usunął ten błąd po Androidzie 3.0, ale z jakiegoś powodu Seeder wciąż pojawia się na listach „zalecanych poprawek” w celu optymalizacji wydajności Androida. Co więcej, aplikacja Seeder ma kilka analogów, takich jak sEFix, które obejmują funkcjonalność Seedera, niezależnie od tego, czy używa tego samego rngd lub alternatywnego haveged, czy nawet tylko dowiązanie symboliczne między / dev / urandom i / dev / random. Jest to absolutnie bezcelowe w przypadku nowoczesnych systemów Android.

Powodem, dla którego nie ma sensu jest to, że nowsze wersje Androida używają / dev / random / w trzech głównych komponentach - libcrypto, do szyfrowania połączeń SSL, generowania kluczy SSH itp. WPA_supplication / hostapd, który generuje klucze WEP / WPA, a na koniec garść biblioteki do generowania identyfikatora podczas tworzenia systemów plików EXT2 / EXT3 / EXT4.

Tak więc, gdy w nowoczesnych skryptach optymalizacyjnych Androida zawarte są ulepszenia Seedera lub oparte na Seederze, to ostatecznie dzieje się pogorszenie wydajności urządzenia, ponieważ rngd stale budzi urządzenie i powoduje wzrost częstotliwości procesora, co oczywiście negatywnie wpływa na zużycie baterii .

Odex

Zapasowe oprogramowanie układowe na urządzeniach z Androidem prawie zawsze odex. Oznacza to, że obok standardowego pakietu aplikacji na Androida w formacie APK, znajdującego się w / system / app / i / system / priv-app /, mają te same nazwy plików z rozszerzeniem .odex. Pliki odex zawierają zoptymalizowane aplikacje z kodem bajtowym, które przeszły już przez maszynę wirtualną walidatora i optymalizatora, a następnie zostały zapisane w osobnym pliku przy użyciu narzędzia przypominającego narzędzie dexopt .

Pliki odex mają więc na celu odciążenie maszyny wirtualnej i przyspieszenie uruchamiania aplikacji odexed - z drugiej strony pliki ODEX zapobiegają modyfikacjom oprogramowania wewnętrznego i powodują problemy z aktualizacjami, dlatego wiele niestandardowych pamięci ROM, takich jak LineageOS, jest dystrybuowanych bez ODEX .

Generowanie plików ODEX odbywa się na wiele sposobów, na przykład za pomocą narzędzia Odexer - problem polega na tym, że ma on wyłącznie efekt placebo. Gdy nowoczesny system Android nie znajdzie plików odex w katalogu / system, system faktycznie je utworzy i umieści w katalogu / system / dalvik-cache /. Dokładnie tak się dzieje, gdy na przykład flashujesz nową wersję Androida i przez chwilę wyświetla się komunikat „Zajęty, optymalizacja aplikacji”.

Ulepszenia Lowmemorykiller

Wielozadaniowość w Androidzie różni się od innych mobilnych systemów operacyjnych w tym sensie, że opiera się na klasycznym modelu, w którym aplikacje działają cicho w tle i nie ma ograniczeń co do liczby aplikacji w tle ( chyba że jeden jest ustawiony w Opcjach programisty, ale jest to generalnie odradzane) - ponadto funkcja przejścia do wykonywania w tle nie jest zatrzymana, chociaż system zastrzega sobie prawo do zabijania aplikacji w tle w sytuacjach niskiej pamięci ( zobacz, gdzie rozmawialiśmy wcześniej o lowmemorykiller i zabiciu braku pamięci) przewodnik) .

Aby wrócić do mechanizmu lowmemorykiller, Android może nadal działać z ograniczoną ilością pamięci i brakiem partycji wymiany. Użytkownik może nadal uruchamiać aplikacje i przełączać się między nimi, a system po cichu zabije nieużywane aplikacje w tle, aby zwolnić pamięć dla aktywnych zadań.

Było to bardzo przydatne dla Androida na początku, choć z jakiegoś powodu stało się popularne w postaci aplikacji do wykonywania zadań, które są na ogół bardziej szkodliwe niż korzystne. Aplikacje do zabijania zadań albo budzą się w ustalonych odstępach czasu, albo są uruchamiane przez użytkownika i wydają się zwalniać duże ilości pamięci RAM, co jest postrzegane jako pozytywne - więcej wolnej pamięci RAM oznacza szybsze urządzenie, prawda? Jednak nie jest tak w przypadku Androida.

W rzeczywistości posiadanie dużej ilości wolnej pamięci RAM może być szkodliwe dla wydajności urządzenia i żywotności baterii. Gdy aplikacje są przechowywane w pamięci RAM Androida, znacznie łatwiej jest je wywoływać, uruchamiać itp. System Android nie musi poświęcać dużo zasobów na przełączanie się na aplikację, ponieważ jest już w pamięci.

Z tego powodu zabójcy zadań nie są tak popularni, jak kiedyś, chociaż nowicjusze z Androida nadal z jakiegoś powodu na nich polegają ( niestety, brak informacji) . Niestety nowy trend zastąpił zabójców zadań, trend dostrajania mechanizmów lowmemorykiller . Może to być na przykład aplikacja MinFreeManager, a głównym pomysłem jest zwiększenie obciążenia pamięci RAM, zanim system zacznie zabijać aplikacje działające w tle.

Na przykład standardowa pamięć RAM działa na granicach - 4, 8, 12, 24, 32 i 40 Mb, a gdy wolne miejsce o pojemności 40 MB zostanie zapełnione, jedna z buforowanych aplikacji jest ładowana do pamięci, ale nie działa będzie zakończony.

Zasadniczo więc Android zawsze będzie miał co najmniej 40 MB dostępnej pamięci, co wystarcza, aby pomieścić jeszcze jedną aplikację, zanim lowmemorykiller rozpocznie proces czyszczenia - co oznacza, że ​​Android zawsze dołoży wszelkich starań, aby wykorzystać maksymalną ilość dostępnej pamięci RAM bez ingerowania w doświadczenie użytkownika.

Niestety, niektórzy entuzjaści homebrew zaczęli zalecać zwiększenie wartości do, na przykład, 100 MB przed uruchomieniem LMK. Teraz użytkownik faktycznie straci pamięć RAM (100 - 40 = 60), więc zamiast używać tego miejsca do przechowywania danych aplikacje końcowe, system utrzyma tę ilość wolnej pamięci, bez absolutnie żadnego celu.

Strojenie LKM może być przydatne w przypadku znacznie starszych urządzeń z 512 RAM, ale kto już je posiada? 2 GB to nowoczesny „budżet”, nawet 4 GB pamięci RAM są obecnie postrzegane jako „średni zakres”, więc poprawki LMK są naprawdę przestarzałe i bezużyteczne.

Ulepszenia we / wy

W wielu skryptach optymalizacyjnych dla systemu Android często można znaleźć poprawki, które dotyczą podsystemu we / wy. Na przykład spójrzmy na ThunderBolt! Skrypt, który zawiera następujące wiersze:

 echo 0> $ i / queue / rotational; echo 1024> $ i / queue / nr_requests; 

Pierwszy wiersz zawiera instrukcje harmonogramu we / wy dotyczące obsługi dysku SSD, a drugi zwiększa maksymalny rozmiar kolejki we / wy z 128 do 1024 - ponieważ zmienna $ i zawiera ścieżkę do drzewa urządzeń blokowych w / sys, a skrypt działa w pętli.

Następnie znajdziesz wiersz związany z harmonogramem CFQ:

 echo 1> $ i / queue / iosched / back_seek_penalty; echo 1> $ i / queue / iosched / low_latency; echo 1> $ i / queue / iosched / slice_idle; 

Potem pojawiają się kolejne wiersze, które należą do innych planistów, ale ostatecznie pierwsze dwa polecenia są bezcelowe, ponieważ:

Nowoczesne jądro Linuksa domyślnie rozumie, z jakim typem nośnika pamięci.

Długa kolejka wejścia-wyjścia ( np. 1024) jest bezużyteczna na nowoczesnym urządzeniu z Androidem, w rzeczywistości jest bez znaczenia nawet na komputerach stacjonarnych - jest naprawdę polecana tylko na serwerach o dużej wytrzymałości . Twój telefon nie jest wytrzymałym serwerem Linux.

W przypadku urządzenia z Androidem nie ma praktycznie żadnych aplikacji priorytetowych w danych wejściowych i wyjściowych oraz nie ma mechanicznego sterownika, więc najlepszym planistą jest kolejka noop / FIFO, więc ten „ modyfikator” harmonogramu nie robi nic specjalnego ani znaczącego dla Podsystem we / wy. W rzeczywistości wszystkie te polecenia na wielu ekranach lepiej zastąpić prostym cyklem:

 dla i in / sys / block / mmc *; wykonaj echo noop> $ i / queue / scheduler echo 0> $ i / queue / iostats gotowe 

Pozwoliłoby to harmonogramowi noop dla wszystkich napędów na gromadzenie statystyk we / wy, co powinno mieć pozytywny wpływ na wydajność, choć bardzo niewielki i prawie całkowicie pomijalny.

Innym bezużytecznym usprawnieniem we / wy często znajdowanym w skryptach wydajnościowych jest zwiększenie wartości odczytu z wyprzedzeniem dla kart SD do 2 MB. Mechanizm odczytu z wyprzedzeniem służy do wczesnego odczytu danych z mediów, zanim aplikacja zażąda dostępu do tych danych. Zasadniczo jądro będzie próbowało dowiedzieć się, jakie dane będą potrzebne w przyszłości, i wstępnie załaduje je do pamięci RAM, co powinno skrócić czas powrotu. Brzmi świetnie na papierze, ale algorytm odczytu z wyprzedzeniem jest częściej niepoprawny, co prowadzi do całkowicie niepotrzebnych operacji wejścia-wyjścia, nie wspominając o dużym zużyciu pamięci RAM.

Wysokie wartości odczytu z wyprzedzeniem od 1 do 8 MB są zalecane w macierzach RAID, ale w przypadku urządzeń z Androidem najlepiej pozostawić domyślną wartość 128 KB.

Poprawki systemu zarządzania pamięcią wirtualną

Inną popularną techniką „optymalizacji” jest dostrajanie podsystemu zarządzania pamięcią wirtualną. Zwykle dotyczy to tylko dwóch zmiennych jądra, vm.dirty_background_ratio i vm.dirty_ratio, które służą do dostosowania rozmiaru bufora do przechowywania „brudnych” danych. Brudne dane to zazwyczaj dane, które zostały zapisane na dysk, ale jest jeszcze więcej pamięci i czeka na zapis na dysk.

Typowe wartości poprawek w obu dystrybucjach Linuksa i Androis do podsystemu zarządzania maszyną wirtualną wyglądałyby tak:

 vm.dirty_background_ratio = 10 vm.dirty_ratio = 20 

Próbuje to zrobić, gdy gdy brudny bufor danych stanowi 10% całkowitej ilości pamięci RAM, budzi przepływ pdflush i zaczyna zapisywać dane na dysku - jeśli operacja nagrywania danych na dysku będzie zbyt intensywna, bufor będzie się powiększał, a gdy osiągnie 20% dostępnej pamięci RAM, system przełączy się na kolejną operację zapisu w trybie synchronicznym - bez bufora wstępnego. Oznacza to, że praca zapisu na dysku aplikacji zostanie zablokowana, dopóki dane nie zostaną zapisane na dysku (AKA „lag”).

Powinieneś zrozumieć, że nawet jeśli rozmiar bufora nie osiągnie 10%, system automatycznie uruchomi pdflush po 30 sekundach. Kombinacja 10/20 jest całkiem rozsądna, na przykład na urządzeniu z 1 GB pamięci RAM byłoby to równe 100/200 MB pamięci RAM, co jest więcej niż wystarczające pod względem rekordów serii, w których prędkość jest często mniejsza niż rekord prędkości w systemie NAND - pamięć lub karta SD, na przykład podczas instalowania aplikacji lub kopiowania plików z komputera.

Z jakiegoś powodu autorzy skryptów próbują podnieść tę wartość jeszcze wyżej, do absurdalnych wskaźników. Na przykład możemy znaleźć w skrypcie optymalizacyjnym Xplix szybkość nawet 50/90.

 sysctl -w vm.dirty_background_ratio = 50 sysctl -w vm.dirty_ratio = 90 

Na urządzeniu z 1 GB pamięci ustawia to limit dla brudnego bufora na 500/900 MB, co jest całkowicie bezużyteczne dla urządzenia z Androidem, ponieważ działałoby tylko przy ciągłym nagrywaniu na dysku - coś, co dzieje się tylko przy dużym obciążeniu Serwer Linux.

Piorun! Skrypt ma bardziej rozsądną wartość, ale ogólnie rzecz biorąc, nadal jest dość bez znaczenia:

 if ["$ mem" -lt 524288]; następnie sysctl -w vm.dirty_background_ratio = 15; sysctl -w vm.dirty_ratio = 30; elif ["$ mem" -lt 1049776]; następnie sysctl -w vm.dirty_background_ratio = 10; sysctl -w vm.dirty_ratio = 20; else sysctl -w vm.dirty_background_ratio = 5; sysctl -w vm.dirty_ratio = 10; fi; 

Pierwsze dwa polecenia są uruchamiane na smartfonach z 512 MB pamięci RAM, drugie - z 1 GB, a inne - z ponad 1 GB. Ale w rzeczywistości istnieje tylko jeden powód, aby zmienić ustawienia domyślne - urządzenie z bardzo wolną pamięcią wewnętrzną lub kartą pamięci. W takim przypadku uzasadnione jest rozłożenie wartości zmiennych, czyli utworzenie czegoś takiego:

 sysctl -w vm.dirty_background_ratio = 10 sysctl -w vm.dirty_ratio = 60 

Następnie, gdy system przeciwprzepięciowy zapisuje operacje, bez konieczności zapisywania danych na dysku, do ostatniego nie przejdzie w tryb synchroniczny, co pozwoli aplikacjom zmniejszyć opóźnienie podczas nagrywania.

Dodatkowe bezużyteczne poprawki i modyfikacje wydajności

Istnieje o wiele więcej „optymalizacji”, które naprawdę nic nie robią. Większość z nich po prostu nie ma żadnego wpływu, podczas gdy inne mogą poprawić niektóre aspekty wydajności, jednocześnie degradując urządzenie na inne sposoby ( zwykle sprowadza się to do wydajności vs rozładowania baterii) .

Oto kilka dodatkowych popularnych optymalizacji, które mogą, ale nie muszą być przydatne, w zależności od systemu Android i urządzenia.

• Przyspieszenie - Niewielkie przyspieszenie w celu poprawy wydajności i spadku napięcia - oszczędza trochę baterii.
• Optymalizacja bazy danych - Teoretycznie powinno to poprawić wydajność urządzenia, ale jest wątpliwe.
• Zipalign - Jak na ironię, pomimo wbudowanego wyrównania zawartości funkcji Android SDK w pliku APK w sklepie, można stwierdzić, że wiele programów nie jest przesyłanych przez zipalign.
• Wyłącz niepotrzebne usługi systemowe, usuwając nieużywany system i rzadko używane aplikacje innych firm. Zasadniczo odinstalowanie oprogramowania typu bloatware.
• Niestandardowe jądro z optymalizacjami dla konkretnego urządzenia (znowu, nie wszystkie jądra są równie dobre).
• Opisano już harmonogram we / wy noop.
• Algorytm nasycenia TCP Westwood - Bardziej wydajnie wykorzystywany w domyślnym systemie Android Cubic dla sieci bezprzewodowych, dostępny w niestandardowych jądrach.

Bezużyteczne ustawienia build.prop

LaraCraft304 z forum XDA Developers przeprowadził badanie i stwierdził, że imponująca liczba ustawień /system/build.prop, które są zalecane do użycia „ekspertów”, nie istnieje w źródłowym AOSP i CyanogenMod. Oto lista:

 ro.ril.disable.power.collapse ro.mot.eri.losalert.delay ro.config.hw_fast_dormancy ro.config.hw_power_saving windowsmgr.max_events_per_sec persist.cust.tel.eons ro.max.fling_velocity ro.min.fling_velocity ro. kernel.checkjni dalvik.vm.verify-bytecode debug.performance.tuning video.accelerate.hw ro.media.dec.jpeg.memcap ro.config.nocheckin profiler.force_disable_ulog profiler.force_disable_err_rpt ersist.sys.Hutdown_ap