ART - największa zmiana w Androidzie od czasu Androida [cz. 1]

ART - największa zmiana w Androidzie od czasu Androida [cz. 1]
28.06.2014 09:38
Android 4.4 Kitkat & ART
Android 4.4 Kitkat & ART
Źródło zdjęć: © androidpolice.com
Michał Mynarski
Michał Mynarski

Gdyby ktoś zapytał mnie o największą zaletę Androida, odpowiedziałbym krótko, ale technicznie: Dalvik. Gdyby poproszono mnie o wskazanie największej wady, odpowiedź niestety byłaby identyczna.

Największa siła Androida, które wyniosło go na szczyty popularności i pozwoliła rynkowo zmiażdżyć konkurencję, to otwartość i wieloplatformowość hardware'owa. Androida możemy zainstalować na wszystkim, nawet na stole. I z bardzo dużym prawdopodobieństwem uruchomimy na nim tę samą aplikację, co na naszym flagowcu w kieszeni. To zasługa Dalvika.

Ale maszyna wirtualna ma też spory wkład we wszystkie najbardziej irytujące wady systemu. Fatalne wykorzystanie zasobów sprzętowych, co za tym idzie - mniejsza energooszczędność i problemy natury termicznej. Opóźniona reakcja na dotyk ekranu [względem iOS, chociaż nowy HTC One (M8) pokazał pazur], wolniejsze uruchamianie aplikacji, większe zapotrzebowanie na RAM.

Skoro ten Dalvik taki zły, to czy nie można go po prostu wymienić? - zapytacie. Napisać od nowa i lepiej dostosować do potrzeb nowoczesnego systemu, jakim Android stał się w ciągu sześciu lat?

Odpowiedź na to pytanie jest prosta: nie można. Ale Google wpadł na pomysł, jak upiec dwie pieczenie przy jednym ogniu: pozbyć się ociężałej maszyny wirtualnej, której geneza sięga dekady wstecz, i dać kopa całemu systemowi. Odpowiedzią na problemy użytkowników Androida okazał się Android Run Time, w skrócie ART.

Dalvik vs ART
Źródło zdjęć: © extremetech.com
Dalvik vs ART

Jednak zanim do niego przejdziemy, krótki wykład na temat tego, czym jest maszyna wirtualna i czym różni się ona od tego, z czym możemy się zetknąć np. w komputerze.

Gdy odpalasz jakikolwiek program na swoim pececie z Windowsem (np. przeglądarkę internetową, grę, Spotify), praktycznie zawsze uruchamiasz plik ze skompilowanym kodem. Kod skompilowany to taki, który jest rozumiany przez procesor. To efekt procesu kompilacji wykonywanej przez dewelopera za pomocą kompilatora. Dzięki temu kod, który dla programisty wygląda tak: printf("Hello World\n"), procesor odczyta i przetworzy, a na ekranie w oknie konsoli pojawi się piękny napis, od którego zaczynał każdy programista: Hello World.

Plik *exe (od executable) to plik wykonywalny, kod maszynowy dla procesora, który on zrozumie i wykona.

Innym rodzajem kodu jest kod interpretowany, zazwyczaj nierozłączony z językiem programistycznym wysokiego poziomu. Cóż to takiego? Nie wdając się w szczegóły to język programowania wysokiego poziomu pozwala programiście na dużo łatwiejsze pisanie skomplikowanych programów i aplikacji przy użyciu dużo mniejszej ilości kodu. Ma to swoje wady. Jedną z nich jest właśnie fakt, że najczęściej jest to nierozłączone z potrzebą środowiska pośrodku, między maszyną a kodem aplikacji.

Szybkość działania funkcji w JavaScript interpretowanego (niebieski / czerwony) oraz skompilowanego do postaci natywnej (clang -O2). Niższe wartości - lepszy wynik.
Źródło zdjęć: © extremetech.com
Szybkość działania funkcji w JavaScript interpretowanego (niebieski / czerwony) oraz skompilowanego do postaci natywnej (clang -O2). Niższe wartości - lepszy wynik.

Kod interpretowany wymaga interpretatora, który przetłumaczy polecenia programu w nim napisanego na język procesora. Proces ten zwany jest kompilacją Just in Time i takim interpretatorem jest właśnie Dalvik. Problem polega na tym, że taki kod jest wolny, sporo wolniejszy od kodu natywnego.

Java jest świetnym przykładem kodu interpretowanego i języka programowania wysokiego poziomu. W Javie programista napisze kod raz i ma pewność, że uruchomi się on na Windowsie, Linuksie czy OS X. Wystarczy, że użytkownik będzie miał zainstalowaną wirtualną maszynę Javy (JVM).

Dalvik to maszyna wirtualna Javy, tyle że przygotowana przez Google'a. Oznacza to, że za każdym razem gdy włączamy aplikację, zostaje ona uruchomiona na nowo w swego rodzaju mikrośrodowisku. Takie rozwiązanie pozwala Androidowi na uruchomienie tej samej aplikacji na setkach różnych konfiguracji sprzętowych, bo Dalvik oddziela kod źródłowy aplikacji od hardware'u. To jego największa zaleta.

Do wad można zaliczyć niezoptymalizowanie. Jeżeli wierzyć temu, co czasem chlapną inżynierowie Androida, Dalvik nigdy nie był tworzony z myślą o zastosowaniach, do których zmuszają go dzisiejsi użytkownicy systemu Google'a. Miał być lekkim VM, pozwalającym na odpalanie programów napisanych w Javie bez licencji Oracle'a. Co więcej, jego docelową platformą miały być przeglądarki internetowe, a skończył jako wół roboczy do odpalania zaawansowanych gier 3D w rozdzielczości Full HD. Na początku istnienia Androida to miało sens i mogło działać, dziś już niestety nie, a będzie coraz gorzej.

Jutro część druga dotycząca rodzajów maszyn wirtualnych i tego, jaką pozycję zajmuje wśród nich Dalvik.

Oceń jakość naszego artykułuTwoja opinia pozwala nam tworzyć lepsze treści.
Udostępnij:
Wybrane dla Ciebie
Komentarze (0)