Dlaczego mój smartfon zamula się po pewnym czasie?

Ach to uczucie, gdy z pudełka wyjmuje się nowy gadżet. Pierwsza konfiguracja, ochy, achy, i wszystko śmiga jak należy. A po kilku tygodniach... czar świeżości pryska. Niegdyś wymarzony i sprawnie działający sprzęt zaczyna działać coraz bardziej ociężale. Brzmi znajomo? Przez coś takiego przechodzi większość użytkowników. Niektórzy zrzucają to na „mułowatość” nielubianego przez siebie systemu, inni doradzają aby nie instalować miliona niepotrzebnych aplikacji, a jeszcze inni stwierdzają, że im wszystko działa i narzekająca osoba musi mieć jakieś zwidy. No więc gdzie tak naprawdę leży problem?

Jest on bardzo złożony i może zależeć od wielu czynników, ale bardzo często winowajcą jest główny nośnik danych urządzenia. Jest to element naszych kieszonkowych komputerów, który otrzymuje znacznie mniej uwagi, niż powinien. Zresztą to nic dziwnego, bo choć piksele, megaherce i rdzenie łatwo „sprzedać” specjalistom od marketingu, to mało kogo interesuje ile wbudowana pamięć flash danego smartfona wyciąga „ajopsów” przy losowym zapisie małych plików. Prawda, że brzmi to abstrakcyjnie?

A skąd przekonanie, że to właśnie o to chodzi?

Z obserwacji i z... logiki. Już od dłuższego czasu w testach tabletów i smartfonów publikowanych na PCLabie pojawiają się wykresy z Androbencha. Domyślam się, że większość z Was je całkowicie ignoruje, bo są one mało interesujące. No i nie czarując zbyt mocno, ja też przez długi czas miałem problem z właściwym zinterpretowaniem tych cyferek, więc w pewnym sensie Was rozumiem ;) Ale warto na nie patrzeć, bo w praktyce są one czasem nawet bardziej istotne, niż wynik Geekbencha, czy GLBenchmarka, bo mają one dużo większy związek z komfortem użytkowania, niż jakieś punkty i „efpeesy”. Po prostu patrząc na wynik testu szybkości zapisu losowego warto pamiętać o pewnej prostej zależności, którą wypatrzyłem w czasie przerzucania kilkudziesięciu smartfonów i tabletów z Androidem – jeśli jakieś urządzenie uzyskuje tam mniej niż 0,3 MB/sek., to znaczy, że na 100% w czasie gdy jest coś pobierane w tle, instalowane, czy po prostu w czasie przełączania się między aplikacjami będzie ono muliło i wydawało się działać dużo wolniej, niż sprzęt uzyskujący ponad 0,5 MB/sek., nawet jeśli ten drugi ma teoretycznie dużo wolniejszy procesor. W tym momencie wystarczy mi kilka minut z jakimś urządzeniem i sprawdzenie jak się ono zachowuje w czasie podpinania różnego rodzaju kont i instalowania aplikacji, aby znać mniej więcej wynik Androbencha, zanim go jeszcze zobaczę. Serio – nawet  coś co ma milion rdzeni taktowanych zegarem bilion gigaherców, to nie będzie w pełni płynne, jeśli ma pamięć flash uzyskującą 0,2-0,3 MB/sek w tym benchmarku. Z obserwacji wiem, że wszystko powyżej 0,5 MB/sek. można uznać za w miarę akceptowalne, ale naprawdę fajnie robi się dopiero w najnowszych urządzeniach, osiągających w tym teście ponad 1 MB/sek.

A jest to logiczne, bo pokrywa się chociażby z tym, co zauważają użytkownicy desktopów. Jeśli jesteś jednym ze szczęśliwców posiadających nośnik SSD, to zapewne dobrze pamiętasz ten moment, gdy pierwszy raz uruchomiłeś świeżo zainstalowany na nim system operacyjny i o ile szybciej wszystko zaczęło działać. Tak samo jest tutaj i jakość wbudowanego w smartfon/tablet nośnika danych ma spore przełożenie na komfort użytkowania go. Zresztą, dziwnym zbiegiem okoliczności, 0,2-0,3 MB/sek. losowego zapisu małych plików, to mniej więcej tyle samo, ile uzyskują klasyczne twardziele, co skutecznie działa na wyobraźnię ;) Co prawda praktyczne różnice między najnowszymi SSD-kami są niemal niezauważalne (chyba, że ktoś bardzo chce się pochwalić przed kumplami, że jego „dysk” ma 500 MB/sek. zapisu, a nie „tylko” 400), ale gadżetowe nośniki eMMC mają przed sobą jeszcze daleką drogę, zanim ich wydajność przestanie mieć znaczenie dla użytkownika.

Ale to dopiero połowa historii

Jednak powyższe słowa, choć mówią czemu niektóre urządzenia mulą, choć teoretycznie nie powinny, w żaden sposób nie odpowiadają na pytanie zadane w tytule. Przez długi czas główkowałem nad tym i miałem wrażenie, że brakuje mi jakiegoś elementu w tej układance, aż w końcu został mi on pokazany palcem w jednym z tekstów opublikowanym na Anandtech, który później (często z różnymi przekłamaniami) obiegł internet. To powinno być dla mnie oczywiste (a może po prosto było zbyt oczywiste), ale smartfonowa pamięć eMMC to przecież taki nośnik SSD w mniejszej skali, a więc kontroler i system plików muszą radzić sobie z wyzwaniami typowymi dla SSD-ków, które były rozwiązywane w różny sposób jakieś trzy, czy cztery lata temu. Po prostu myślałem, że od tamtej pory wszyscy się nauczyli jak właściwie opiekować się pamięcią flash, ale... myliłem się. Krótko mówiąc, każdy nośnik oparty na pamięciach flash zwolni po pewnym czasie, jeśli:

• niemal całkowicie zapełnisz go danymi (dobrym zwyczajem jest pozostawianie przynajmniej 20% wolnego miejsca, bo poniżej tej granicy zawsze robi się trochę wolniej)
• komórki pamięci nie są w nim trimowane, co niestety dotyczy większości urządzeń z Androidem

Nad tą pierwszą rzeczą nie będę się zbytnio rozpisywał, ale druga może wymagać dla niektórych z Was wyjaśnienia. W przypadku klasycznych dysków talerzowych, gdy się kasuje jakiś plik, to nie jest on fizycznie wymazywany z nośnika, ale po prostu system zaznacza sobie, że zajmowane przez niego wcześniej miejsce można ponownie wykorzystać i nowe dane są „nadpisywane” na pozostałości starych bez jakiejkolwiek straty wydajności. W nośnikach flash działa to inaczej i zanim jakiś sektor nośnika będzie mógł być ponownie wykorzystany, to najpierw musi zostać wyczyszczony z pozostałości po skasowanych danych. Niestety, domyślnie nie dzieje się to w momencie wciśnięcia guzika Delete na klawiaturze, a tuż przed zapisaniem nowych informacji w ich miejsce. Jak mocno spowalnia to zapis danych? To zależy od konkretnego nośnika i jego kontrolera, ale czasem różnica bywa bardzo duża (niektórzy z Was zapewne pamiętają niesławne JMicrony...).

Rozwiązaniem tego problemu jest TRIM, czyli komenda, która w momencie jej wywołania, nakazuje wyczyścić nośnik z pozostałości po skasowanych plikach, zanim zaistnieje potrzeba zapisania czegoś nowego w ich miejsce, dzięki czemu nośnik może pracować cały czas z pełną szybkością. Sposoby na zaimplementowanie i wywoływanie tego mechanizmu są różne i zależą od systemu operacyjnego, kontrolera i innych czynników, ale można je wrzucić do dwóch głównych worków: trimowanie całego napędu co jakiś czas, gdy urządzenie akurat nic nie robi, albo trimowanie plików od razu w momencie wciśnięcia guzika Delete.

Smartfonowo-tabletowa praktyka...

... jest taka, że w większości urządzeń nie korzysta z TRIM, choć jego obsługa jest w Androidzie od dawna. Ale jak to? To nie została ona wprowadzona dopiero w Androidzie 4.3? Nie. Najprostszym sposobem na wywołanie TRIM w Androidzie, jest skorzystanie z systemu plików ext4 i flagi discard. Jeśli producent sprzętu ustawi flagę discard, to TRIM jest uruchamiany od razu w momencie kasowania pliku, więc dane są usuwane nie tylko „z widoku” użytkownika, ale też fizycznie. Właściwie jedynym warunkiem, aby to zadziałało, jest posiadanie sprzętu z niezamierzchłą wersją Androida, który ma pamięć eMMC w wersji 4.4, lub nowszej. Z tym pierwszym warunkiem nie powinno być problemu, a z tym drugim... bywa różnie. Teoretycznie są one produkowane już od kilku lat i powinny występować we wszystkich nowych smartfonach i tabletach, ale niektóre nowości nadal mają swoje systemy zainstalowane na magazynowych leżakach, które nie dość, że w standardzie są dramatycznie wolne, to nie da się ich „ztrimować” w żaden sposób.

W jaki sposób sprawdzić, czy Twoje urządzenie „discarduje” dane i dzięki temu jest w 100% odporne na spowalnianie nośnika danych z biegiem czasu? Trzeba je podłączyć do komputera w trybie debugowania USB i skorzystać z dwóch komend adb: najpierw wpisać adb shell, a potem mount. To drugie polecenie wyświetla wszystkie systemy plików i ich parametry. Jeśli wśród podanych informacji znajduje się coś takiego:

to jest dobrze. Do tej pory odnalazłem to w Samsungu Galaxy S4 (Android 4.3) i... Kiano Elegance 8 3G (Android 4.2). Także wiele ROM-ów z XDA ma domyślnie włączony discard dla partycji systemowej i z danymi, co przyczynia się do tego, że wielu użytkowników zauważa po ich zainstalowaniu sporą poprawę w szybkości działania systemu.

W nowych Nexusach z Androidem 4.3 i 4.4 skorzystano z innego rozwiązania. Gdy sprzęt jest przez jakiś czas nieużywany, to działające w tle procesy uruchamiają „odśmiecarkę” trimującą odpowiednie sektory nośnika danych. Najpewniejszym sposobem na wymuszenie „sprzątania” na Nexusie 7 jest zostawienie go podłączonego do ładowarki na noc, bo wywołanie funkcji fstrim jest obwarowane kilkoma wymaganiami dotyczącymi chociażby poziomu naładowania akumulatora, czasu nieaktywności itp. Krótko mówiąc, sposób ten działa, ale nie przepadam za implementacją tego typu. Bo co jeśli ktoś ładuje tablet gdy jest on wyłączony? Albo tylko doładowuje go w ciągu dnia od czasu do czasu? Albo ładuje w czasie grania, oglądania czegoś, albo surfowania po Internecie? Jeśli masz takie zwyczaje, to może się okazać, że nośnik Twojego Nexusa nie będzie trimowany nawet przez kilka tygodni. Zresztą okazało się, że mój nie był i z biegiem czasu zaczął wyraźnie zwalniać. Wystarczyło go tylko podłączyć na noc do ładowarki, sprawdzić logi systemowe:

... i wydajność wróciła do normy.

Jeśli nie masz Nexusa, ani twórca Twojego sprzętu nie pobłogosławił go discardem, to jest jeszcze jeden sposób na TRIM – manualny. Na Google Play Store znajduje się program LagFix, który ręcznie wysyła komendę TRIM do nośnika danych. W wersji płatnej można nawet ustawić, aby proces ten był uruchamiany codziennie, albo raz w tygodniu. Jest tylko jeden problem – wymaga on zrootowanego systemu. Jeśli nie wiesz co to znaczy, to niestety w tym wpisie tego nie będę tłumaczył.

Różnice, różnice

W ramach testów pomęczyłem trochę dwa urządzenia: LG G2, który domyślnie nie ma zaimplementowanego żadnego mechanizmu wywołującego TRIM i Nexusa 7, w którym łatwo „ominąć” sprzątanie nośnika danych. G2 używałem regularnie przez kilka miesięcy i zauważyłem, że ostatnio zaczyna się robić ślamazarny. W końcu go zrootowałem, przeczyściłem mu pamięć i poniżej można zobaczyć efekt.

Pamięć eMMC Nexusa lepiej znosi upływ czasu bez trimowania, ale i tak po przeczyszczeniu jej wszystko zaczęło działać po prostu szybciej. Natomiast LG G2... no właśnie. W przypadku niektórych urządzeń różnica bywa bardzo duża. A teraz wyobraźcie sobie, że czysta pamięć jakiegoś sprzętu „wyciąga” początkowo nie prawie 1 MB/sek (tak jak G2), ale około 0,5 MB/sek. i spowalnia o tyle samo procent, co w smartfonie LG. Właśnie coś takiego działo się na przykład ze starym Nexusem 7 i niektórzy użytkownicy przed aktualizacją do Androida 4.3 (szczególnie ci, którzy zainwestowali w wersję 8 GB) po pewnym czasie narzekali na to, że ich tablet staje się niemiłosiernie powolny, choć początkowo wszystko działało jak trzeba. I nic dziwnego, bo z tego co widziałem w sieci, niektóre Nexusy 7 2012 osiągały w Androbenchu w teście zapisu losowego wyniki na poziomie pojedynczych (czyli mniej niż 10!) operacji na sekundę.

Powyższy slajd Samsunga pochodzi z listopada 2011 roku, czyli problem i jego świadomość nie jest nowa, ale nadal mało kto korzysta z TRIM-u w smartfonach i tabletach. Warto też zauważyć, że wynik średniej szybkości zapisu danych nie opowiada całej historii.

A jak to jest z innymi systemami?

Powyższe akapity skupiają się na Androidze, ale jak wspomniałem na początku, nie jest to kwestia „mułowatości” jednego systemu, a ograniczeń pamięci flash montowanej w naszych gadżetach i tego, jak z nimi radzą sobie programiści. Czy problem ten dotyczy też Windows Phone i iOS? W pewnym stopniu tak, choć nie ma tego jak za bardzo sprawdzić. Pierwsze iPhony raczej na pewno nie były trimowane, ale nie mam pojęcia jak to jest z ich najnowszymi wydaniami, bo znalezienie bardziej szczegółowych informacji na temat systemu plików iOS i tego jakie funkcje w nim zaimplementowano jest bardzo trudne. Tak samo jest z Windows Phone. Podejrzewam, że Windows Phone 7, oparty jeszcze na starszym jądrze systemowym, również nie wiedział co to TRIM, bo powstawał w czasach, gdy jeszcze mało kto był świadomy tego problemu. A czy w Windows Phone 8 działa to jak powinno? Zapewne tak, bo jest oparty na kernelu Windows NT, więc byłbym bardzo zdziwiony, gdyby w tym systemie nie zaimplementowano „śmieciarki”, skoro w biurkowym Windowsie wywodzącym się z tego samego kernela jest ona aktywna od czasów Windowsa 7.

tl;dr

Na koniec skrót dla osób, którym nie chciało się przekopywać przez powyższą ścianę tekstu. Jeśli twój smartfon/tablet po pewnym czasie zaczyna wyraźnie zwalniać, to istnieje duże prawdopodobieństwo tego, że ma on kiepską pamięć flash, która nie jest regularnie „sprzątana” przez system. Jak temu zapobiec i jak to rozwiązać?

• Najlepiej zapobiegać. Urządzenia z małą ilością wbudowanej pamięci i bez slotu na kartę pamięci są dużo bardziej podatne na wspomniane tu spowalnianie, więc w pewnym stopniu można się ubezpieczyć na przyszłość już w czasie zakupów.
• Po zakupie gadżetu, należy nie instalować na nim wszystkiego co się da, utrzymywać jak największą ilość wolnego miejsca (dobrze jest, gdy jest go przynajmniej 20%), a dane trzymać na karcie SD.
• Jeśli masz jakiegoś Nexusa z Androidem 4.3, lub 4.4, to należy pamiętać o tym, że czasem trzeba go zostawić włączonego na noc z podpiętą ładowarką, bo dopiero wtedy jego pamięć zostanie „posprzątana” i jej szybkość wróci do normy.
• Jeśli wiesz jak zrootować swój sprzęt, to zrób to i skorzystać z programu LagFix.
• No i zawsze można się modlić o to, żeby dane urządzenia otrzymało aktualizację oprogramowania dodającą jakąkolwiek implementację TRIM (i wcale nie musi to być Android 4.3).