Dlatego wiele kompleksowych skryptów optymalizacyjnych korzysta z tych samych metod, z których niektóre są całkowicie przestarzałe lub szkodliwe na dłuższą metę. Podsumowując, większość skryptów optymalizacyjnych typu „wszystko w jednym” to nic innego jak zestawione ze sobą zalecane strojenie, bez jasnego pojęcia, jak i dlaczego te optymalizacje działają - użytkownicy następnie flashują skrypty i twierdzą, że ich wydajność jest nagle szybsza ( podczas gdy w rzeczywistości była to najprawdopodobniej bardzo prosta czynność ponownego uruchomienia urządzenia, która spowodowała wzrost wydajności , ponieważ wszystko w pamięci RAM urządzenia zostanie wyczyszczone) .
W tym ekskluzywnym artykule Appuals przedstawimy niektóre z najczęstszych zaleceń dotyczących „ optymalizacja ” Wydajność Androida i czy to po prostu mit, czy uzasadniona modyfikacja wydajności urządzenia.
Zamiana
Na szczycie listy mitów znajduje się wymiana Androida - co jest dość absurdalne, jeśli chodzi o bycie postrzeganym jako optymalizacja Androida. Głównym celem zamiany jest utworzenie i połączenie pliku stronicowania, który zwolni miejsce w pamięci. Brzmi rozsądnie na papierze , ale to naprawdę ma zastosowanie do serwer , który prawie nie ma interaktywności.
Regularne korzystanie z funkcji zamiany telefonu z Androidem prowadzi do poważnych opóźnień wynikających z wymykania się rzeczy z pamięci podręcznej. Wyobraź sobie, na przykład, jeśli aplikacja próbuje wyświetlić grafikę, która jest przechowywana w miejscu wymiany, a teraz musi ponownie załadować dysk po zwolnieniu miejsca przez umieszczenie wymiany danych z inną aplikacją. Jest naprawdę brudny.
Niektórzy entuzjaści optymalizacji mogą powiedzieć, że zamiana nie sprawiała żadnych problemów, ale nie jest to zamiana powodująca wzrost wydajności - jest to wbudowany mechanizm Androida lowmemorykiller , który regularnie zabija rozdęte procesy o wysokim priorytecie, które nie są używane. LMK został zaprojektowany specjalnie do obsługi warunków małej ilości pamięci, jest wywoływany z kswapd proces i ogólnie zabija procesy w przestrzeni użytkownika. To różni się od OOMkiller (zabójca 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 osiągnie niezbędnych danych wydajnościowych w zamianie, więc wymiana jest absolutnie niepotrzebna w Androidzie. Jego wdrożenie jest po prostu obarczone opóźnieniem i prowadzi do pliku degradacja w wydajności, zamiast ją optymalizować.
zRAM - przestarzały i nie jest już wydajny
zRAM to sprawdzona i skuteczna metoda optymalizacji urządzeń, np starsze urządzenia - pomyśl o urządzeniach opartych na KitKat, które działają tylko na około 512 MB pamięci RAM. Fakt, że niektórzy ludzie nadal uwzględniają poprawki zRAM w skryptach optymalizacyjnych lub zalecają zRAM jako rodzaj nowoczesnej optymalizacji, jest przykładem ludzi, którzy generalnie nie stosują się do najnowszych protokołów operacyjnych.
zRAM był przeznaczony dla podstawowych, budżetowych wielordzeniowych układów SoC, takich jak urządzenia wykorzystujące chipsety MTK i 512 MB pamięci RAM. W zasadzie bardzo tanie chińskie telefony. Zasadniczo zRAM oddziela jądro za pomocą strumienia szyfrowania.
Gdy zRAM jest używany na starszych urządzeniach z rozszerzeniem pojedynczy rdzeń , nawet jeśli zRAM jest zalecany na takich urządzeniach, pojawiają się duże ilości opóźnień. Dzieje się tak również w przypadku technologii KSM ( Łączenie tej samej strony jądra) który łączy identyczne strony pamięci w celu zwolnienia miejsca. W rzeczywistości jest to zalecane przez Google, ale prowadzi do większych opóźnień na starszych urządzeniach, ponieważ stale aktywne rdzenie rdzenia działają nieprzerwanie z pamięci w poszukiwaniu duplikatów stron. Zasadniczo, próba uruchomienia optymalizacji optymalizacji spowalnia urządzenie jeszcze bardziej, jak na ironię.
Seeder - nieaktualny od Androida 3.0
Jedną z najbardziej dyskutowanych wskazówek dotyczących optymalizacji wśród twórców Androida jest cedr , i jesteśmy pewni, że ktoś mógłby spróbować udowodnić nam, że nie mamy racji w tym temacie - ale najpierw musimy przyjrzeć się historii siewnika.
Aplikacja Seeder na Androida
Tak, istnieje wiele raportów, które deklarują lepszą wydajność Androida po instalacji znacznie starsze urządzenia z Androidem . Jednak ludzie z jakiegokolwiek powodu uważają, że jest to również odpowiednia optymalizacja dla nowoczesne urządzenia z systemem Android , co jest absolutnie absurdalne. Fakt, że Seeder jest nadal utrzymywany i oferowany jako „ nowoczesny' Narzędzie do redukcji lagów jest przykładem dezinformacji - choć nie jest to wina programisty Seedera, ponieważ nawet jego strona Sklepu Play zauważa, że Seeder jest mniej skuteczny po Androidzie 4.0+. Jednak z jakiegoś powodu Seeder wciąż pojawia się w dyskusjach dotyczących optymalizacji dla nowoczesnych systemów Android.
To, co w zasadzie robi Seeder dla Androida 3.0, to naprawienie błędu, w którym środowisko uruchomieniowe Androida aktywnie korzystałoby z / dev / random / file w celu uzyskania entropii. Bufor / dev / random / stałby się niestabilny, a system zostałby zablokowany, dopóki nie wypełni wymaganej ilości danych - pomyśl o drobiazgach, takich jak różne czujniki i przyciski na urządzeniu z Androidem.
Autor Seedera zajął się demonem Linuksa rngd i skompilowany dla systemu inastroil Androida, dzięki czemu pobierał losowe dane ze znacznie szybszej i bardziej przewidywalnej ścieżki / dev / urandom i łączy je w dev / random / co sekundę, nie pozwalając, aby / dev / random / się wyczerpały. Doprowadziło to do powstania systemu Android, który nie odczuwał braku entropii i działał znacznie płynniej.
Google rozwalił ten błąd po Androidzie 3.0, ale z jakiegoś powodu Seeder nadal pojawia się „Zalecane poprawki” listy do optymalizacji wydajności Androida. Ponadto aplikacja Seeder ma kilka analogów, takich jak sEFix, które obejmują funkcjonalność Seedera, niezależnie od tego, czy używają tej samej rngd lub alternatywa haveged lub nawet dowiązanie symboliczne między / dev / urandom i / dev / random. W przypadku nowoczesnych systemów Android jest to absolutnie bezcelowe.
Powodem, dla którego nie ma to 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 i wreszcie garść bibliotek do generowania ID w tworzeniu systemów plików EXT2 / EXT3 / EXT4.
Więc kiedy Siewnik lub ulepszenia oparte na Seeder są zawarte w nowoczesnych skryptach optymalizacyjnych Androida, co ostatecznie się dzieje, to plik degradacja w wydajności urządzenia, ponieważ rngd będzie stale budzić urządzenie i powodować wzrost częstotliwości procesora, co oczywiście negatywnie wpływa na zużycie baterii.
Odex
Oprogramowanie sprzętowe na urządzeniach z Androidem prawie zawsze odex. Oznacza to, że oprócz standardowego pakietu dla 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 wykorzystującym coś w rodzaju dexopt narzędzie.
Pliki odex mają więc na celu odciążenie maszyny wirtualnej i przyspieszenie uruchamiania aplikacji odexed - z drugiej strony pliki ODEX zapobiegają modyfikacjom oprogramowania układowego i stwarzają problemy z aktualizacjami, dlatego wiele niestandardowych 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 jest to efekt czysto 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 /. To jest dokładnie to, co się dzieje, gdy na przykład flashujesz nową wersję Androida i przez chwilę wyświetla się komunikat „Zajęte, optymalizuję aplikacje”.
Poprawki Lowmemorykiller
Wielozadaniowość w Androidzie różni się od innych mobilnych systemów operacyjnych tym, że opiera się na klasycznym modelu, w którym aplikacje działają cicho w tle i nie ma ograniczeń co do liczby aplikacji działających w tle ( chyba że jest ustawiona w Opcjach programisty, ale jest to ogólnie zalecane) - ponadto funkcjonalność przejścia do wykonywania w tle nie jest zatrzymywana, chociaż system zastrzega sobie prawo do zabijania aplikacji działających w tle w sytuacjach małej ilości pamięci ( zobacz, gdzie rozmawialiśmy o zabójcy niskiej pamięci i zabójcy braku pamięci wcześniej w tym przewodniku) .
Aby wrócić do lowmemorykiller mechanizm 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 zabija nieużywane aplikacje działające w tle, aby spróbować 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 zabijających zadania, które są generalnie bardziej szkodliwe niż korzystne. Aplikacje do zabijania zadań albo budzą się w określonych 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 to dokładnie w przypadku Androida.
W rzeczywistości posiadanie dużej ilości wolnej pamięci RAM może w rzeczywistości zaszkodzić wydajności urządzenia i żywotności baterii. Gdy aplikacje są przechowywane w pamięci RAM Androida, o wiele łatwiej jest je wywoływać, uruchamiać itp. System Android nie musi poświęcać dużo zasobów na przejście do aplikacji, ponieważ jest ona już w pamięci.
Z tego powodu zabójcy zadań nie są tak popularni jak kiedyś, chociaż nowicjusze Androida nadal z jakiegoś powodu polegają na nich ( brak informacji, niestety) . Niestety, nowy trend zastąpił zabójców zadań, trend lowmemorykiller strojenie mechanizmu. To byłby na przykład MinFreeManager app, a głównym pomysłem jest zwiększenie narzutu pamięci RAM, zanim system zacznie zabijać aplikacje w tle.
Na przykład standardowa pamięć RAM działa na granicach - 4, 8, 12, 24, 32 i 40 Mb, a po zapełnieniu wolnego miejsca 40 MB jedna z aplikacji w pamięci podręcznej jest ładowana do pamięci ale nie działa będzie zakończony.
Zasadniczo Android zawsze będzie miał co najmniej 40 MB dostępnej pamięci, co wystarcza wcześniej, aby pomieścić jeszcze jedną aplikację lowmemorykiller rozpoczyna proces czyszczenia - co oznacza, że Android zawsze zrobi wszystko, co w jego mocy, aby wykorzystać maksymalną ilość dostępnej pamięci RAM bez zakłócania komfortu użytkowania.
Niestety, niektórzy entuzjaści homebrew zaczęli zalecać podniesienie wartości do, na przykład, 100 MB przed uruchomieniem LMK. Teraz użytkownik faktycznie stracić RAM (100-40 = 60), więc zamiast używać tego miejsca do przechowywania aplikacji zaplecza, system zachowa taką ilość pamięci wolny , bez żadnego celu.
Strojenie LKM może się przydać dla znacznie starszych urządzeń z 512 RAM, ale kto jest już ich właścicielem? 2 GB to nowoczesny „zakres budżetowy”, nawet urządzenia z 4 GB pamięci RAM są obecnie postrzegane jako „średniej klasy”, więc poprawki LMK są naprawdę przestarzałe i bezużyteczne.
Poprawki we / wy
W wielu skryptach optymalizacyjnych dla Androida często można znaleźć poprawki dotyczące podsystemu we / wy. Na przykład spójrzmy na plik Piorun! Skrypt zawierający te wiersze:
echo 0> $ i / queue / rotational; echo 1024> $ i / queue / nr_requests;
Pierwsza linia poda instrukcje harmonogramu I / O, jak postępować z dyskiem SSD, a druga zwiększa maksymalny rozmiar kolejki I / O ze 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;
Po tym następuje więcej wierszy należących do innych planistów, ale ostatecznie pierwsze dwa polecenia są bezcelowe, ponieważ:
Nowoczesne jądro Linuksa jest w stanie zrozumieć, z jakim typem nośnika pamięci domyślnie pracuje.
Długa kolejka wejścia-wyjścia ( np. 1024) jest bezużyteczny na nowoczesnym urządzeniu z Androidem, w rzeczywistości jest bez znaczenia nawet na komputerze - tak naprawdę jest zalecany tylko na serwery o dużej wytrzymałości . Twój telefon nie jest wydajnym serwerem Linux.
W przypadku urządzenia z systemem Android praktycznie nie ma aplikacji z priorytetem w wejściach i wyjściach ani mechanicznego sterownika, więc najlepszym planistą jest kolejka noop / FIFO, więc ten typ harmonogramu ” dostrajać' nie robi nic specjalnego ani znaczącego dla podsystemu we / wy. W rzeczywistości wszystkie te polecenia listy wieloekranowej lepiej zastąpić prostym cyklem:
dla i in / sys / block / mmc *; do echo noop> $ i / queue / schedule echo 0> $ i / queue / iostats done
Umożliwiłoby to harmonogramowi noop dla wszystkich dysków gromadzenie statystyk we / wy, co powinno mieć pozytywny wpływ na wydajność, chociaż bardzo mały i prawie całkowicie pomijalny.
Inną bezużyteczną poprawką we / wy, często spotykaną w skryptach wydajnościowych, są zwiększone wartości odczytu z wyprzedzeniem dla kart SD do 2 MB. Mechanizm odczytu z wyprzedzeniem służy do wczesnego odczytu danych z nośnika, 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 źle , co prowadzi do całkowicie niepotrzebnych operacji wejścia-wyjścia, nie wspominając o wysokim zużyciu pamięci RAM.
Wysokie wartości odczytu z wyprzedzeniem od 1 do 8 MB są zalecane w tablicach RAID, ale w przypadku urządzeń z systemem Android 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 dostosowywania rozmiaru buforu do przechowywania „brudnych” danych. Brudny dane to zwykle dane, które zostały zapisane na dysku, ale ich więcej znajduje się w pamięci i czeka na zapisanie na dysku.
Typowe wartości dostosowania w dystrybucjach Linuksa i Androis do podsystemu zarządzania maszynami wirtualnymi wyglądają następująco:
vm.dirty_background_ratio = 10 vm.dirty_ratio = 20
Więc to, co próbuje zrobić, to to, że gdy brudny bufor danych stanowi 10% całkowitej ilości pamięci RAM, budzi się pdflush przepływa i zaczyna zapisywać dane na dysk - jeśli operacja zapisu danych na dysku będzie zbyt intensywny 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 pre-bufora. Oznacza to, że praca nad zapisem na dysku aplikacji będzie zablokowane, dopóki dane nie zostaną zapisane na dysku (AKA „lag”).
Należy zrozumieć, że nawet jeśli rozmiar bufora nie osiąga 10% , system automatycznie uruchomi pdflush po 30 sekundach. Połączenie 10/20 jest całkiem rozsądne, 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 poniżej rekordu prędkości w systemowej pamięci NAND -pamięć lub karta SD, na przykład podczas instalowania aplikacji lub kopiowania plików z komputera.
Z jakiegoś powodu scenarzyści próbują podnieść tę wartość jeszcze wyżej, do absurdalnych wskaźników. Na przykład możemy znaleźć w Xplix skrypt optymalizacyjny z szybkością 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 brudnego bufora na 500/900 MB, co jest całkowicie bezużyteczne dla urządzenia z Androidem, ponieważ działałoby tylko pod ciągłe nagrywanie na płycie - coś, co dzieje się tylko na ciężkim serwerze Linux.
Piorun! Skrypt używa bardziej rozsądnej wartości, ale ogólnie jest nadal dość bez znaczenia:
if ['$ mem' -lt 524288]; to 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 więcej niż 1 GB. Ale tak naprawdę jest tylko jeden powód, aby zmienić ustawienia domyślne - urządzenie z bardzo wolną pamięcią wewnętrzną lub kartą pamięci. W tym przypadku rozsądne jest rozłożenie wartości zmiennych, czyli wykonanie czegoś takiego:
sysctl -w vm.dirty_background_ratio = 10 sysctl -w vm.dirty_ratio = 60
Wtedy, gdy system przeciwprzepięciowy zapisuje operacje, bez konieczności zapisywania danych na płycie, do ostatniej nie przełącza się w tryb synchroniczny, co pozwoli aplikacjom na zmniejszenie opóźnienia podczas nagrywania.
Dodatkowe bezużyteczne poprawki i dostrajanie wydajności
Jest o wiele więcej „optymalizacji”, które tak naprawdę nic nie robią. Większość z nich po prostu nie daje żadnego efektu, podczas gdy inne mogą się poprawić trochę aspekt wydajności, jednocześnie degradując urządzenie w inny sposób ( zwykle sprowadza się to do wydajności vs wyczerpania baterii) .
Oto kilka dodatkowych popularnych optymalizacji, które mogą być przydatne lub nie, w zależności od systemu Android i urządzenia.
- Przyspieszenie - małe przyspieszenie poprawiające wydajność i obniżanie napięcia - oszczędza trochę baterii.
- Optymalizacja bazy danych - w teorii to powinien dają poprawę wydajności urządzenia, ale wątpliwe.
- Zipalign - Jak na ironię, pomimo wbudowanej funkcji Android SDK wyrównania zawartości w pliku APK w sklepie, wiele programów nie jest przesyłanych za pomocą 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).
- Już opisany program planujący I / O noop.
- Algorytm nasycenia TCP Westwood - bardziej efektywnie używany w domyślnym systemie Android Cubic dla sieci bezprzewodowych, dostępny w niestandardowych jądrach.
Bezużyteczne ustawienia build.prop
LaraCraft304 z forum deweloperów XDA przeprowadziło badanie i odkryło, że imponująca liczba ustawień /system/build.prop, które są zalecane do użycia przez „ekspertów”, nie istnieje w źródłowych 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.shutdown.mode ro.config.nocheckin profiler.force_disable_ulog profiler.force_disable_err_rpt ersist.sys.shutdown.mode.Tagi android Rozwój 12 minut czytania
