Google testuje następcę Dalvika: z ART‑em Android będzie dwukrotnie szybszy?

Niedawna premieraAndroida 4.4 przyniosła ze sobą dla mobilnego systemu operacyjnegoGoogle'a coś, co większość komentatorów początkowo przeoczyła, a comoże okazać się dla niego nowym początkiem. W Kit Kacie zadebiutowałaotóż nowa maszyna wirtualna Androida, przez dwa lata rozwijana wcieniu sporu licencyjnego z Oracle o Javę i wirtualną maszynę Dalvik.Przynosi ona szybsze i efektywniejsze uruchamianie aplikacji w Javie,przy jednoczesnym zmniejszeniu zużycia energii i większejresponsywności całego systemu.Deweloperzy i fascynaci Androida, którzy zainstalowali już naswoich telefonach i tabletach ROM-y z wersją 4.4 systemu, mogą wustawieniach (Settings | Developer Options) wybrać sobie noweśrodowisko uruchomieniowe dla aplikacji. Zamiast klasycznego Dalvika(libdvm.so) mogą włączyć ART(Android RunTime, libart.so). Potem wystarczy odczekać kilkanaścieminut, podczas których system optymalizuje aplikacje pod kątem nowejmaszyny – i w ten sposób wkraczamy we wciąż eksperymentalnąprzyszłość Androida.[img=android44]Co takiego przełomowego przynosi ART? Przede wszystkim zmieniacałkowicie proces uruchamiania aplikacji. W Dalviku od wersji 2.2Androida wykorzystywany jest kompilator Just-In-Time do optymalizacjikodu bajtowego (co i tak przyniosło wówczas nawet 4,5-krotneprzyspieszenie w teście Linpack for Android), ale i tak aplikacja zakażdym uruchomieniem musi przejść przez interpreter, co oczywiściewiąże się ze sporym narzutem. Zaletą takiego podejścia jest łatwośćuruchamiania na różnych architekturach sprzętowych, wadą oczywiściemarnotrawstwo mocy obliczeniowej. Tak więc ART pozwala naprekompilację kodu bajtowego Javy na kod maszynowy, za pomocą tzw.kompilatora ahead-of-time(AOT). Jako że optymalizacje wprowadzane przez taki kompilatorwykonywane są tylko raz, mogą one być znacznie bardziej zaawansowane,niż byłoby to uzasadnione dla kompilatora JIT (choć oczywiście AOTnie może stosować wielu typów dynamicznej optymalizacji).Efekt jest jednak bardzo odczuwalny, szczególnie przezużytkowników urządzeń o niewielkich zasobach pamięci i mocyobliczeniowej. Prekompilowane aplikacje i biblioteki zajmują mniejpamięci i szybciej się uruchamiają, są bowiem aplikacjami w pełninatywnymi, nie wymagają każdorazowego uruchamiania maszynywirtualnej. Pierwsze benchmarki pokazują, że dla większości aplikacjiczas uruchamiania może zostać w ten sposób skrócony nawet o połowę.To zaś oznacza, że system dłużej będzie przebywał w staniebezczynności i wykorzystywał mniej rdzeni procesora, oszczędzając wten sposób energię.Przejście na ART-a będzie miało też pewne negatywne skutki –rozmiar zainstalowanych aplikacji będzie trochę większy (kod bajtowyjest oszczędniejszy od kodu maszynowego), aplikacje będą też dłużejsię instalowały, jako że częścią procesu instalacji będzie ichprekompilacja na konkretną architekturę sprzętową. Są to jednakkoszty warte poniesienia, pozwalające Androidowi uzyskać wydajnośćporównywalną z iOS-em Apple'a. Nie wiadomo, kiedy ART stanie się domyślnym środowiskiemuruchomieniowym Androida. Google udostępniło tę technologię jedynieeksperymentalnie, tak by zapoznać się z nią mogli producenci sprzętui programiści. Jej stosowanie na co dzień na razie nie ma sensu,ryzykujemy niestabilnością systemu i niekompatybilnością z wielomaaplikacjami. Widać to szczególnie na ROM-ach AOSP, gdzie przełączeniez Dalvika na ART powoduje awarie aplikacji Google.