A Huawei nyilvánosságra hozta az új Ark Compiler működésével kapcsolatos legfontosabb részleteket, és azt ígéri, hogy drasztikusan javítja az alkalmazások teljesítményét Androidon. Olvasson tovább
A Huawei körüli közelmúltbeli beszélgetések nagy része a vállalat szerencsétlen politikai helyzete körül forgott, mert egy Az Egyesült Államok végrehajtói rendelete, amely számos vállalatot korlátozott abban, hogy üzletet folytasson a Huawei-vel. Egy ilyen sarkalatos döntés következményei túlságosan hatalmasak ahhoz, hogy ne figyeljünk oda. De egy alternatív valóságban, ahol ez a végrehajtási utasítás nem létezik, a Huawei a rivaldafényben lett volna a közelmúltban bemutatta az Ark Compiler-t, a legújabb innovációt, amely azt állítja, hogy áthidalja az Android és az alkalmazások teljesítménybeli különbségeit iOS.
Mielőtt belemerülnénk abba, hogy mi is az Ark Compiler, tennünk kell egy lépést hátra, és meg kell értenünk, mi a fordító, és milyen célt szolgál az Android rendszerben.
A fordítók és tolmácsok rövid története Androidon
A fordítóprogram olyan számítógépes program, amely lefordítja a kódot egyik nyelvről egy másik nyelvre, amely gyakran az anyanyelve. Ezt vagy közvetlenül a számítógép, vagy egy másik programon (tolmácson) keresztül hajthatja végre. Erre a fordításra azért van szükség, mert ember által olvasható programozási nyelveken írunk kódot (például Java és Kotlin), míg a számítógép csak az anyanyelvet érti (bináris kód 1-es és 0-k). A fordító így hídként szolgál az ember által írt utasítások és a gép azon képessége között, hogy megértse, majd végrehajtsa ezeket az utasításokat. Az, hogy ez az átalakítás és az azt követő értelmezés milyen gyorsan és hatékonyan megy végbe, meghatározza a fordító hatékonyságát, tehát közvetlen összefüggés bevezetése a fordító hatékonysága és a kód teljesítménye és hatékonysága között, és kibővítve, alkalmazásokat.
Dalvik VM
Az Android korai napjaiban az operációs rendszer az úgynevezett Dalvik VM-et (az értelmezőt) használta egy JIT (just-in-time) fordítóval együtt. Ez a régebbi videó az XDA TV Android Basics 101-ből A sorozat a Dalvik virtuális gépet és a JIT beállítást érinti, mindkettő a korai Android rendszerek igényeit szolgálta ki, ahol bőséges volt a memóriakorlát. A Dalvik virtuális gép Java bájtkódot használt, és gépi kóddá alakította át, amikor és amikor a kódot végrehajtani kellett (tehát a Just-In-Time). Erre azért volt szükség, mert akkoriban a telefonok tárhelye igazi korlát volt, így ez a megközelítés lehetővé tette, hogy az alkalmazások kisebb fájlmérettel dolgozzanak a rendszerben.
Az alkalmazások futás közbeni fordításának és értelmezésének hátránya az alkalmazás általános lassabb teljesítménye volt, mivel a fordítás az alkalmazás használatával párhuzamosan zajlik.
A Dalviknak is voltak korlátai a szemétgyűjtő mechanizmussal kapcsolatban. Dalvik együttesen nyomon követte az egyes memóriakiosztásokat. Miután Dalvik megállapítja, hogy egy memóriadarabot már nem használ a program, a programozó beavatkozása nélkül visszaszabadítja ezt a memóriát a kupacba. Ezt a folyamatot szemétgyűjtésnek (GC) nevezik, és célja, hogy memóriaobjektumokat találjon egy olyan programban, amelyhez már nem fér hozzá, majd visszaszerezze az objektumok által a memória felszabadítására használt erőforrásokat. A rendszer kollektív alapon határozza meg, hogy mikor van szükség GC-re, így az alkalmazásfejlesztők nem választhatják meg, hogy mikor történnek GC-események [még az ART-ban sem]. Tehát ha egy GC-esemény az előtérbeli alkalmazásban végzett intenzív feldolgozási tevékenység közepette történik, a rendszer szünetel a folyamat végrehajtása és a GC megkezdése, ezáltal növelve a feldolgozási időt, és észrevehető "jank"-ot hozva a felhasználókat.
Ezek és más korlátok arra késztették a Google-t, hogy alternatív megoldásokat keressen a gyorsabb teljesítmény érdekében.
Android Runtime
A Google bemutatta az Android 4.4 KitKat rendszert ART (Android Runtime) előnézeti formában AOT (Ahead-Of-Time) fordítóval, és Android 5.0 Lollipop esetén a Google elvetette a Dalvik-ot, és az ART javára az egyetlen elérhető tolmácsot választotta. Az ART az AOT-val az alkalmazás telepítésekor konvertálta a kódot gépi nyelvre, ahelyett, hogy várna az átalakításra, amikor az alkalmazás használatban van. Ez a megközelítés így felgyorsította az alkalmazások indítási idejét, de hátrányokat is jelentett a lassabb telepítési idők és a megnövekedett lemezterület-használat formájában. Hogy mindezt egyensúlyba hozza, a Google fogadott az AOT, a JIT és a profilvezérelt összeállítás kombinációja az ART-val Android 7.0 Nougat rendszeren, hogy egyetlen tényezőt se érintsen drasztikusan.
Az ART azon is dolgozott, hogy kevésbé zavaró legyen a szemétgyűjtés. A GC folyamatot úgy optimalizálták, hogy összességében gyorsabb legyen, kevesebb szünettel (egyetlen rövid szünet a Dalvik két szünetével), kevesebb töredezettséggel és kevesebb memóriahasználattal. A Google prezentációja a 2014-es Google I/O-n részletesebben elmagyarázza a Dalvik GC és ART fejlesztéseinek korlátait.
Még az évek során bekövetkezett változások ellenére is, a Google megközelítésének alaptétele a kód értelmezése volt a végrehajtás során, miközben változtatta a fordítási (fordítási) elem időzítését. A Szemetgyűjtés továbbra is fájdalmas pont az alkalmazásfejlesztők számára, mert megszakító és kollektív jellege van. Vitathatatlan, hogy az Android alkalmazások teljesítménye csökken ennek eredményeként, mivel továbbra is vannak általános költségek.
Ark Compiler a Huaweitől
A Huawei egy hatékonyabb megoldás kifejlesztésén dolgozik, és ennek következtében több száz szakértőt vett fel a területen. Ennek az erőfeszítésnek az eredménye az Ark Compiler, amely a Huawei állítása szerint az első statikus fordító. amely lehetővé teszi a közvetlen fordítást gépi nyelvre, teljesen megszüntetve az an tolmács. Az Ark Compiler-t is azzal a céllal fejlesztették ki, hogy maximalizálják a Java és C futási hatékonyságát, így elméletileg ezekkel a nyelvekkel kell a legjobb eredményeket elérni.
A Huawei az alábbiak szerint bemutatja az Ark Compiler néhány kulcsfontosságú funkcióját:
- Az olyan fordítási technikák, mint az AOT és a JIT, képesek egyes programokat gépi kódokká konvertálni, és közvetlenül a CPU-n futtatni, de ezek a technikák nem képesek teljesen elszakadni az értelmezőtől és a hozzá kapcsolódó korlátoktól. Az Ark Compiler statikus fordítást használ, amely lehetővé teszi, hogy leválasztja magát a dinamikus értelmezőről, így lehetőség nyílik az alkalmazások teljesítményének növelésére a "ugrásszerűen."
- A statikus fordításnak megvan az a lehetséges hátulütője, hogy túl merev, és nem tudja végrehajtani azokat a beállításokat, amelyeket a dinamikus fordító végrehajthat a végrehajtás során. A Huawei azt állítja, hogy az Ark Compiler statikus fordítása megoldja ezt "a programozási nyelv dinamikus jellemzőinek zökkenőmentes lefordításával gépi kódba."
- A meglévő fordítási folyamatok az alkalmazáscsomag mobileszközre történő telepítése során vagy azt követően zajlanak. Az Ark Compiler szoftverfejlesztés során történő üzembe helyezésre készült, amelyről feltételezzük, hogy segít eltávolítani a telepítés és a végrehajtás során felmerülő többletköltségeket. Feltételezzük, hogy az alkalmazásfejlesztők képesek lennének közvetlenül különböző nyelveket natív gépi kódba fordítani az alkalmazás során. a fejlesztési folyamat, és az eredményül kapott APK-nak így nem kell interakciót végrehajtania egy értelmezővel vagy egy virtuális géppel funkció. Ez elméletileg csökkentené például a JNI-vel kapcsolatos általános költségeket.
- Az Ark Compiler a szemétgyűjtés kollektív jellegét is megváltoztatja. Lehetővé teszi, hogy a GC események külön-külön forduljanak elő a különböző Java szálakhoz. Ez a részekre osztott megközelítés azt állítja, hogy kevesebb zökkenőt kínál az előtérben lévő alkalmazásokban.
E változtatások eredményeként az Ark Compiler képes látszólag akár 24%-kal javítja az Android rendszer működésének gördülékenységét, akár 44%-kal a válaszsebességet és akár 60%-kal a harmadik féltől származó alkalmazások zökkenőmentességét, amely azt állítja, hogy az Android-alkalmazások teljesítményét az iOS-el azonos szintre hozza.
Az Ark Compiler jelenleg ARM chip architektúrára van fordítva és optimalizálva. A Huawei reméli, hogy a jövőben az együttműködésen alapuló hardver- és szoftvertervezés a Kirin chip képességeinek maximalizálására törekszik majd.
Az Ark Compiler támogatja a szabványos Java-használatot, lehetővé téve harmadik féltől származó alkalmazások közvetlen fordítását anélkül, hogy az alkalmazásfejlesztőnek bármiféle kódmódosítást kellene végrehajtania. Az Ark Compiler lehetővé teszi a „kódstruktúra módosítását” is a teljesítmény és a memória további javítása érdekében. A Huawei úgy döntött, hogy az Ark Compilert nyílt forráskódú rendszerré teszi, amely lehetővé tenné a külső fejlesztők számára és a technológiát igényeikhez igazítsák, elősegítve az alkalmazásfejlesztők és a mobiltelefonok elfogadását gyártók.
Bár a Huawei nem említi az Ark Compiler hátrányait, nagy alkalmazásméretekre számíthatunk legalábbis, de ez nem jelenthet semmilyen problémát a jelenlegi generációs eszközökön, amelyek bőséggel érkeznek tárolás. Arra is számítunk, hogy az Ark Compiler nem lesz elérhető minden CPU-architektúrához, mivel a Google kompatibilitási problémái nem okozzák a Huawei fejfájását. Az Ark Compiler a fejlesztés során, és nem a telepítés során használható; ez arra utal, hogy a Huawei valószínűleg módosította az alkalmazások Android-eszközökön történő üzembe helyezésének és telepítésének módját, és a saját APK-terven is dolgozhatott. Ha ez igaz, akkor ez komoly kompatibilitási problémát jelenthet az ökoszisztémában, és hosszú időbe telhet, amíg ez az Android szabványos funkciója lesz, ha valaha is.
Ha nem a felhasználó eszközén fordítunk, az is nagy kérdést vet fel az optimalizálással kapcsolatban. Az ART jelenleg mikro-architektúránkénti alapon optimalizál, ami azt jelenti, hogy az eredményül kapott bináris különbözik a Snapdragon eszköztől az Exynos eszköztől, vagy akár a Snapdragon 845-től a Snapdragontól 625. Ez a megközelítés logikus az olyan gyártók számára, akik teljes ellenőrzést gyakorolnak az SoC felett, mint például az Apple és a Huawei. Mivel azonban az Android világ többi része sok különböző SoC-t használ, az általános optimalizálás kényszerítése az eszközökön keresztül ismét akadályt jelent majd az Ark Compiler szabványosítása előtt. Következésképpen ne számítson arra, hogy az Ark Compiler hamarosan megérkezik kedvenc egyéni ROM-jára.
Az egyértelműség kedvéért az Ark Compilert Androiddal való együttműködésre fejlesztették ki, és a Huawei semmit sem említett állítólagos homebrew operációs rendszer és az Ark Compilerrel való kompatibilitása, ezért ezzel kapcsolatban nem teszünk feltételezéseket.
A Huawei két nagy konferenciát tervez a fejlesztőknek és a nagyobb ökoszisztémának szentelve. Ezek a Huawei Device China Developers Conference és a Green Alliance China Developers Conference. Mindkét esemény konkrét, a Huawei Ark Compiler programjával kapcsolatos nyílt forráskódú kérdésekkel foglalkozik, annak érdekében, hogy a technológia előnyeit a lehető legszélesebb körben elérhetővé tegyék.
Külön köszönet az XDA elismert vezető közreműködőjének Dees_Troy és elismert fejlesztő arter97 segítségükért és hozzájárulásukért.
Megjegyzés: A Huawei/Honor leállította a hivatalos rendszerbetöltő feloldó kódok biztosítását eszközei számára. Emiatt eszközeik rendszerbetöltői nem oldhatók fel, ami azt jelenti, hogy a felhasználók nem rootolhatnak vagy telepíthetnek egyéni ROM-okat.