Dlaczego Android laguje? „Bo jest źle zoptymalizowany”. To bardzo ogólna i trochę myląca odpowiedź. Osoby, które miały choć trochę kontaktu z programowaniem, często odpowiadają, że problem leży w maszynie wirtualnej i środowisku uruchomieniowym Dalvik.
Jakiej maszynie?! Tabletowo to nie miejsce na niskopoziomowe rozważania na temat kodu maszynowego, kompilatorów czy środowisk runtime’ów, ale warto zrozumieć podstawy i to jak działa Android i aplikacje w nim uruchamiane. Zacznijmy od podstaw – zielony robot musi chodzić na najróżniejszych procesorach różnych architektur – w tym ARM i x86. Co z tego wynika? Taka uniwersalność warunkuje również uniwersalność skompilowanego kodu aplikacji. Same aplikacje tworzone są w języku Java, jednak po zakończeniu kodowania i testowania są one kompilowane. W przypadku iOS czy Windows Phone, aplikacje kompilowane są do kodu niskopoziomowego – maszynowego, czyli bezpośrednich rozkazów dla procesora. To rozwiązanie optymalne pod względem wydajności i szybkości. Android natomiast ze względu na konieczność zachowania uniwersalności i niezależności od architektur nie może być kompilowany do kodu niskopoziomowego.
Jak jest zatem kompilowany? Dotąd javowy kod aplikacji przekształcany był na wykonywalny kod w plikach .dex (Dalvik Executable Format) podczas instalowania aplikacji na urządzeniu. Jest to kompilacja wstępna, „średniopoziomowa”, uniwersalna dla wszystkich procesorów. Maszyna wirtualna czyli Dalvik VM jest środowiskiem uruchomieniowym dla tego kodu i ma za zadanie przetłumaczyć go na kod maszynowy, zrozumiały dla lokalnego procesora. Skomplikowane? A to dopiero początek. To właśnie ta konstrukcja jest problematyczna – maszyna wirtualna to dodatkowa warstwa systemu operacyjnego, a każda kolejna warstwa to konieczność dodatkowej komunikacji, a co za tym idzie wolniejsze działanie. Co więcej, kompilacja przez tę maszynę wirtualną działa na zasadzie JIT (Just-In-Time), czyli kod maszynowy powstaje za każdym razem gdy uruchamiamy aplikację i z niej korzystamy. Aplikacje zatem w teorii uruchamiać będą się dłużej niż w przypadku rozwiązania natywnego, bez maszyny wirtualnej.
Czy ART rozwiązuje ten problem? Częściowo. Czym jest ART? Skrót oznacza Android Runtime czyli androidowe środowisko uruchomieniowe. Podstawową różnicą w stosunku do Dalvika jest to, że ART używa kompilacji AOT (Ahead-Of-Time) zamiast JIT. A co to oznacza w praktyce? Już podczas instalacji aplikacji, kod z pliku .apk (lub .dex) jest przekształcany na niskopoziomowy kod maszynowy dostosowany do lokalnego procesora. Pozwala to na utworzenie prawdziwych, natywnie działających aplikacji bez konieczności pełnej wirtualizacji. To oczywiście ogromne uproszczenie tego co się dzieje na tych etapach, ale wystarczające by zrozumieć podstawową przewagę ART nad Dalvikiem.
Dalvik jest „zły”? Właściwie tak, ale nie jest to takie oczywiste. Dalvik nie jest wolny z uwagi na kiepską optymalizację kodu samej maszyny. Jest wolny, bo każda maszyna wirtualna jest co najmniej dwa razy wolniejsza niż rozwiązania natywne. Dodatkowo, Android laguje/klatkuje nie ze względu na Dalvika. Problemem jest jego natura, oparta o pełną wielozadaniowość i wieloprocesowość, ciężkie animacje oraz źle napisane, zasobożerne aplikacje (widzę Cię, Facebooku). Kompilacja JIT też nie jest zła sama w sobie i dotyczy jedynie ok. 2% kodu. Te 2% to są jednak najczęściej dość zasobożerne rozkazy, co stwarza pewne problemy wydajnościowe. ART ma być 2x szybszy od Dalvika w wykonywaniu kodu, ale dalej ok. 2x wolniejszy od pełnoprawnego rozwiązania natywnego.
Zmniejszenie roli maszyny wirtualnej, lepsza optymalizacja kodu i lepszy Garbage Collector. Czy wszystko to przełoży się na wzrost płynności systemu? I tak i nie. Odciąży to procesor, więc jeśli to procesor był wąskim gardłem – urządzenie może przyspieszyć. ART to też mniejsza zajętość pamięci RAM i lepsze zarządzanie pamięcią. Kolejny plus. Okazuje się jednak, że większość problemów wynika z zastosowania wolnych podzespołów takich jak pamięć wewnętrzna i korzystaniu z zasobożernych aplikacji, które pożrą zasoby procesora i RAM-u bez względu na ich wydajność i rozmiar. W benchmarkach, realna korzyść z ART nie wygląda już jednak tak różowo.
Jestem pozytywnie nastawiony do tego rozwiązania i liczę na realna poprawę płynności systemu. Jednak pamiętamy, że poprawę płynności obiecywały kolejno Androidy 4.0, 4.1, 4.2 i 4.4, a jak było w praktyce – sami dobrze wiemy – różnie. Ogromnym plusem może być jednak poprawa żywotności baterii, która powinna zostać osiągnięta dzięki mniejszemu zaangażowaniu CPU i lepszemu zarządzaniu pamięcią.
