Jak kompilator Arki Huawei może poprawić wydajność aplikacji na Androida

Huawei opublikował kluczowe szczegóły dotyczące działania nowego kompilatora Ark, obiecując radykalnie zwiększyć wydajność aplikacji na Androidzie. Czytaj dalej, aby uzyskać więcej informacji

Duża część ostatnich rozmów na temat Huawei dotyczyła niefortunnej sytuacji politycznej firmy z powodu: Amerykańskie rozporządzenie wykonawcze zabraniające wielu firmom prowadzenia interesów z Huawei. Konsekwencje tak kluczowej decyzji są zbyt ogromne, aby nie zwracać na nie uwagi. Ale w alternatywnej rzeczywistości, w której to rozporządzenie wykonawcze nie istnieje, Huawei znalazłby się w centrum uwagi niedawno ujawnił Ark Compiler, najnowszą innowację, która ma wypełnić lukę w wydajności aplikacji pomiędzy systemami Android i iOS.

Zanim zagłębimy się w to, czym jest Ark Compiler, musimy cofnąć się o krok i zrozumieć, czym jest kompilator i czemu służy w systemie Android.

Krótka historia kompilatorów i interpreterów na Androida

Kompilator to program komputerowy, który tłumaczy kod z jednego języka na inny, często będący rodzimym językiem maszynowym. Można to następnie wykonać bezpośrednio przez komputer lub za pomocą innego programu (interpretera). To tłumaczenie jest konieczne, ponieważ piszemy kod w językach programowania zrozumiałych dla człowieka (takich jak Java i Kotlin), podczas gdy komputer rozumie tylko natywny język maszynowy (kod binarny w postaci jedynek i 0). Kompilator służy zatem jako pomost pomiędzy instrukcjami pisanymi przez człowieka a zdolnością maszyny do zrozumienia i późniejszego wykonania tych instrukcji. To, jak szybko i efektywnie przebiega ta konwersja i późniejsza interpretacja, określa zatem wydajność kompilatora wprowadzenie bezpośredniej korelacji pomiędzy wydajnością kompilatora a wydajnością i wydajnością kodu, a co za tym idzie, aplikacje.

Dalvik VM

Na początku Androida system operacyjny wykorzystywał tak zwaną maszynę wirtualną Dalvik (interpreter) wraz z kompilatorem JIT (just-in-time). Ten starszy film z Android Basics 101 na platformie XDA TV Seria dotyczy maszyny wirtualnej Dalvik i konfiguracji JIT, które zaspokajały potrzeby wczesnych systemów Android, w których występowały duże ograniczenia pamięci. Maszyna wirtualna Dalvik pobierała kod bajtowy Java i konwertowała go na kod maszynowy w momencie, gdy kod wymagał wykonania (stąd Just-In-Time). Było to konieczne, ponieważ przestrzeń dyskowa w telefonach była wówczas prawdziwym ograniczeniem, więc takie podejście umożliwiło aplikacjom pracę z mniejszymi rozmiarami plików w systemie.

Kompilowanie i interpretowanie aplikacji w czasie wykonywania miało tę wadę, że ogólnie działała wolniej, ponieważ kompilacja odbywała się równolegle z korzystaniem z aplikacji przez użytkownika.

Dalvik miał również ograniczenia związane z mechanizmem zbierania śmieci. Dalvik zbiorczo śledził każdą alokację pamięci. Gdy Dalvik ustali, że fragment pamięci nie jest już używany przez program, zwalnia tę pamięć z powrotem na stertę bez żadnej interwencji programisty. Proces ten nazywa się Garbage Collection (GC) i ma na celu znalezienie obiektów pamięci w programie, do którego nie ma już dostępu, a następnie odzyskanie zasobów używanych przez te obiekty w celu zwolnienia pamięci. System określa, kiedy potrzebne jest GC, więc twórcy aplikacji nie mogą wybierać, kiedy mają nastąpić zdarzenia GC [nawet w ART]. Jeśli więc zdarzenie GC wystąpi w trakcie intensywnego przetwarzania w aplikacji na pierwszym planie, system zostanie wstrzymany wykonanie procesu i rozpoczęcie GC, zwiększając w ten sposób czas przetwarzania i wprowadzając zauważalne „szarpnięcie” do użytkownicy.

Te i inne ograniczenia skłoniły Google do zbadania alternatywnych podejść w celu uzyskania większej wydajności.

Środowisko wykonawcze Androida

Wraz z Androidem 4.4 KitKat Google wprowadziło ART (Środowisko wykonawcze Androida) w formie podglądu z kompilatorem AOT (Ahead-Of-Time) i Androidem 5.0 Lollipop, Google zrezygnował z Dalvik na rzecz ART jako jedynego dostępnego interpretera. ART z AOT przekonwertował kod na język maszynowy w momencie instalacji aplikacji, zamiast czekać na taką konwersję, gdy aplikacja jest używana. Takie podejście przyspieszyło zatem czas uruchamiania aplikacji, ale wprowadziło także wady w postaci wolniejszego czasu instalacji i zwiększonego wykorzystania miejsca na dysku. Aby to wszystko zrównoważyć, Google przyjęty połączenie AOT, JIT i kompilacji opartej na profilach z ART na Androidzie 7.0 Nougat, aby mieć pewność, że żaden pojedynczy czynnik nie ulegnie drastycznemu wpływowi.

Implementacja ART Androida

ART pracował także nad tym, aby usługa zbierania śmieci była mniej uciążliwa. Proces GC został zoptymalizowany tak, aby był ogólnie szybszy z mniejszą liczbą przerw (pojedyncza krótka przerwa w porównaniu z dwiema przerwami Dalvika), mniejszą fragmentacją i mniejszym zużyciem pamięci. Prezentacja Google na Google I/O 2014 zawiera bardziej szczegółowe wyjaśnienia dotyczące ograniczeń GC i ulepszeń ART firmy Dalvik w tym zakresie.

Nawet przy tych zmianach na przestrzeni lat podstawowe założenie podejścia Google polegało na interpretowaniu kodu podczas wykonywania przy jednoczesnej zmianie czasu trwania elementu kompilacji (tłumaczenia). Wyrzucanie śmieci nadal stanowi problem dla twórców aplikacji ze względu na swój nieodłączny, zakłócający i zbiorowy charakter. Prawdopodobnie spada w rezultacie wydajność aplikacji na Androida, ponieważ nadal wiążą się z tym koszty ogólne.

Kompilator Arki firmy Huawei

Huawei pracował nad opracowaniem bardziej wydajnego rozwiązania, w związku z czym zatrudnił setki ekspertów w tej dziedzinie. Rezultatem tych wysiłków jest kompilator Ark, który według Huawei jest pierwszym w historii kompilatorem statycznym który pozwala na bezpośrednie tłumaczenie na język maszynowy, całkowicie eliminując potrzebę interpretator. Ark Compiler został również opracowany w celu maksymalizacji wydajności działania dla Java i C, więc teoretycznie najlepsze wyniki powinny być widoczne w tych językach.

Grafika autorstwa Huawei. Tekst przetłumaczony przez użytkownika XDA MyKeyVans.

Huawei przedstawia kilka kluczowych funkcji kompilatora Ark jak poniżej:

  • Techniki kompilacji, takie jak AOT i JIT, umożliwiają konwersję niektórych programów na kod maszynowy i uruchamianie ich bezpośrednio na procesorze, jednak techniki te nie są w stanie całkowicie uwolnić się od tłumacza i związanych z nim ograniczeń. Kompilator Ark wykorzystuje kompilację statyczną, która pozwala mu uwolnić się od dynamicznego interpretera, otwierając możliwość zwiększenia wydajności aplikacji poprzez „skacze i przekracza."
  • Kompilacja statyczna ma potencjalną wadę, ponieważ jest zbyt sztywna i nie pozwala na dokonanie zmian, które kompilator dynamiczny może wprowadzić podczas wykonywania. Huawei twierdzi, że statyczna kompilacja Arki Compiler rozwiązuje ten problem „poprzez płynne tłumaczenie dynamicznych funkcji języka programowania na kod maszynowy."
  • Istniejące procesy kompilacji mają miejsce podczas lub po instalacji pakietu aplikacji na urządzeniu mobilnym. Ark Compiler jest przeznaczony do wdrażania podczas tworzenia oprogramowania, co, jak zakładamy, pomaga wyeliminować koszty ogólne podczas instalacji i wykonywania. Zakładamy, że twórcy aplikacji będą w stanie bezpośrednio w trakcie tworzenia aplikacji kompilować różne języki do natywnego kodu maszynowego proces programowania, w związku z czym powstały plik APK nie będzie wymagał interakcji z interpreterem ani maszyną wirtualną funkcjonować. Teoretycznie zmniejszyłoby to na przykład koszty ogólne związane z JNI.
  • Ark Compiler zmienia także zbiorowy charakter Garbage Collection. Pozwala na wystąpienie zdarzeń GC oddzielnie dla różnych wątków Java. To podzielone na segmenty podejście zapewnia mniej szarpnięć w aplikacjach na pierwszym planie.

W wyniku tych zmian Ark Compiler może pozornie poprawiają płynność działania systemu Android nawet o 24%, szybkość reakcji nawet o 44%, a płynność działania aplikacji zewnętrznych nawet o 60%, twierdząc, że zapewnia wydajność aplikacji na Androida na tym samym poziomie, co na iOS.

Kompilator Ark jest obecnie skompilowany i zoptymalizowany pod kątem architektury chipów ARM. Huawei ma nadzieję, że w przyszłości wspólne projektowanie sprzętu i oprogramowania będzie sprzyjać maksymalizacji możliwości układu Kirin.

Kompilator Ark obsługuje standardowe użycie języka Java, umożliwiając bezpośrednią kompilację aplikacji innych firm bez konieczności wprowadzania przez twórcę aplikacji jakichkolwiek modyfikacji kodu. Ark Compiler umożliwia także „dostosowanie struktury kodu” w celu dalszej poprawy wydajności i pamięci. Huawei zdecydował się uczynić Ark Compiler systemem typu open source, który umożliwiłby adaptację zewnętrznym programistom i dostosować technologię do swoich potrzeb, ułatwiając jej przyjęcie wśród twórców aplikacji i telefonów komórkowych producenci.

O ile Huawei nie wspomina o wadach Arki Compiler, o tyle można spodziewać się dużych rozmiarów aplikacji przynajmniej, ale nie powinno to stwarzać żadnych problemów na urządzeniach obecnej generacji, które są wyposażone w wystarczającą ilość składowanie. Oczekujemy również, że Ark Compiler nie będzie dostępny dla wszystkich architektur procesorów, ponieważ problemy Google z kompatybilnością nie są problemem Huawei. Kompilator Ark jest przeznaczony do użycia podczas programowania, a nie podczas instalacji; wskazuje to, że Huawei mógł prawdopodobnie zmodyfikować sposób wdrażania i instalowania aplikacji na urządzeniach z Androidem, a także mógł pracować nad własnym projektem pakietu APK. Jeśli to prawda, może to stanowić poważny problem ze zgodnością w ekosystemie i minie dużo czasu, zanim stanie się to standardową funkcją Androida, jeśli w ogóle.

Brak kompilacji na urządzeniu użytkownika rodzi również duże pytanie dotyczące optymalizacji. ART obecnie optymalizuje na podstawie mikroarchitektury, co oznacza, że ​​wynikowy plik binarny będzie taki różni się w przypadku urządzenia Snapdragon w porównaniu z urządzeniem Exynos, a nawet w przypadku Snapdragon 845 w porównaniu ze Snapdragonem 625. Takie podejście ma sens w przypadku producentów, którzy mają pełną kontrolę nad SoC, takich jak Apple i Huawei. Ponieważ jednak reszta świata Androida korzysta z wielu różnych układów SoC, wymuszenie ogólnej optymalizacji na różnych urządzeniach ponownie będzie przeszkodą w standaryzacji kompilatora Ark. W związku z tym nie spodziewaj się, że Ark Compiler pojawi się w najbliższym czasie na Twojej ulubionej niestandardowej pamięci ROM.

Dla wyjaśnienia, kompilator Ark został opracowany do współpracy z Androidem, a Huawei nie wspomniał nic na ten temat rzekomy system operacyjny homebrew i jego kompatybilność z Ark Compiler, dlatego nie robimy żadnych założeń w tym zakresie.

Huawei planuje zorganizować dwie duże konferencje poświęcone programistom i szerszemu ekosystemowi. Są to Konferencja programistów urządzeń Huawei w Chinach i Konferencja programistów Green Alliance China. Obydwa wydarzenia będą poświęcone konkretnym kwestiom związanym z oprogramowaniem open source związanym z kompilatorem Ark firmy Huawei, co ma na celu zapewnienie jak najszerszego dostępu do korzyści płynących z tej technologii.


Specjalne podziękowania dla Starszego Uznanego Współtwórcy XDA Dees_Troy i Uznany Deweloper arter97 za ich pomoc i wkład.

Uwaga: Huawei/Honor zaprzestał dostarczania oficjalnych kodów odblokowujących bootloader dla swoich urządzeń. Dlatego nie można odblokować programów ładujących ich urządzeń, co oznacza, że ​​użytkownicy nie mogą rootować ani instalować niestandardowych ROM-ów.