Kaip „Huawei Ark“ kompiliatorius gali pagerinti „Android“ programos našumą

Didžioji dalis pastarojo meto pokalbių apie „Huawei“ buvo susiję su nepalankia bendrovės politine padėtimi, nes JAV vykdomasis įsakymas, kuriuo daugeliui įmonių buvo apribota verslo veikla su „Huawei“.. Tokio esminio sprendimo pasekmės yra pernelyg didžiulės, kad nekreiptume dėmesio. Tačiau alternatyvioje realybėje, kai šio vykdomojo įsakymo nėra, „Huawei“ būtų atsidūręs dėmesio centre dėl savo neseniai atskleidė „Ark Compiler“ – naujausią naujovę, kuri, kaip teigiama, panaikina programos našumo atotrūkį tarp „Android“ ir iOS.

Prieš pasinerdami į tai, kas yra „Ark Compiler“, turime žengti žingsnį atgal ir suprasti, kas yra kompiliatorius ir jo paskirtis „Android“ sistemoje.

Trumpa „Android“ kompiliatorių ir vertėjų istorija

Kompiliatorius yra kompiuterio programa, kuri verčia kodą iš vienos kalbos į kitą kalbą, kuri dažnai yra gimtoji mašinų kalba. Tada tai gali būti vykdoma tiesiogiai kompiuteriu arba per kitą programą (vertėją). Šis vertimas yra būtinas, nes kodą rašome žmonėms skaitomomis programavimo kalbomis (pvz., Java ir Kotlin), o kompiuteris supranta tik gimtąją mašinų kalbą (dvejetainis kodas 1 ir 0). Taigi kompiliatorius yra tiltas tarp instrukcijų, kurias rašo žmogus, ir mašinos gebėjimo suprasti, o paskui jas vykdyti. Tai, kaip greitai ir efektyviai vyksta šis konvertavimas ir tolesnė interpretacija, lemia kompiliatoriaus efektyvumą įvesti tiesioginį ryšį tarp kompiliatoriaus efektyvumo ir kodo našumo bei efektyvumo, o taip pat programėlės.

Dalvikas VM

Pirmosiomis „Android“ dienomis OS naudojo tai, kas buvo vadinama Dalvik VM (vertėju) kartu su JIT (tiesiog laiku) kompiliatoriumi. Šis senesnis vaizdo įrašas iš XDA TV „Android Basics 101“. serija paliečia „Dalvik VM“ ir „JIT“ sąranką, kurios abi atitiko ankstyvųjų „Android“ sistemų, kuriose buvo daug atminties apribojimų, poreikius. Dalvik VM paėmė „Java“ baitinį kodą ir konvertavo jį į mašininį kodą, kai reikėjo vykdyti kodą (taigi, „Just-In-Time“). Tai buvo būtina, nes anuomet telefonų saugykla buvo tikras apribojimas, todėl šis metodas leido programoms dirbti su mažesnio dydžio failais sistemoje.

Programų kompiliavimas ir interpretavimas vykdymo metu turėjo bendrą lėtesnį programos našumo trūkumą, nes kompiliavimas vyks tuo pačiu metu, kai vartotojas naudoja programą.

Dalvik taip pat turėjo apribojimų dėl šiukšlių surinkimo mechanizmo. Dalvikas bendrai stebėjo kiekvieną atminties paskirstymą. Kai Dalvik nustato, kad programa nebenaudoja atminties dalies, ji atlaisvina šią atmintį atgal į krūvą be jokio programuotojo įsikišimo. Šis procesas vadinamas šiukšlių surinkimu (GC), juo siekiama rasti atminties objektus programoje, kuri nebepasiekiama, ir atgauti išteklius, kuriuos tie objektai naudoja atminčiai atlaisvinti. Sistema nustato, kada GC reikalingas kolektyviai, todėl programų kūrėjai negali pasirinkti, kada įvyksta GC įvykiai [net ART]. Taigi, jei GC įvykis įvyktų atliekant bet kokią intensyvią apdorojimo veiklą pirmame plane, sistema pristabdytų proceso vykdymą ir pradėti GC, taip pailginant apdorojimo laiką ir įvedant pastebimą „žaliuką“ vartotojų.

Šie ir kiti apribojimai paskatino „Google“ ieškoti alternatyvių greitesnio našumo metodų.

Android Runtime

„Google“ pristatė „Android 4.4 KitKat“. ART („Android Runtime“) peržiūros formoje su AOT (Ahead-Of-Time) kompiliatoriumi ir su Android 5.0 Lollipop, Google atsisakė Dalvik ir pasirinko ART kaip vienintelį prieinamą vertėją. ART su AOT konvertavo kodą į mašinos kalbą diegiant programą, o ne laukė tokio konvertavimo, kai programa naudojama. Taigi šis metodas pagreitino programos paleidimo laiką, tačiau taip pat atsirado trūkumų, susijusių su lėtesniu diegimo laiku ir didesniu vietos diske naudojimu. Norėdami viską subalansuoti, „Google“. priimtas AOT, JIT ir profilio valdomo kompiliavimo derinys su ART operacinėje sistemoje Android 7.0 Nougat, siekiant užtikrinti, kad joks veiksnys nebūtų smarkiai paveiktas.

ART taip pat stengėsi, kad šiukšlių surinkimas būtų mažiau įkyrus. GC procesas buvo optimizuotas, kad apskritai būtų greitesnis su mažiau pauzių (viena trumpa pauzė, palyginti su dviem Dalviko pauzėmis), mažiau susiskaidymo ir mažiau atminties. „Google“ pristatymas „Google I/O 2014“ išsamiau paaiškina Dalvik GC ir ART patobulinimų apribojimus.

Net ir su šiais pokyčiais bėgant metams, pagrindinė „Google“ metodo prielaida buvo kodo interpretavimas vykdymo metu, keičiant kompiliavimo (vertimo) elemento laiką. Šiukšlių rinkimas taip pat tebėra problemų programėlių kūrėjams, nes jai būdingas pertraukiantis ir kolektyvinis pobūdis. Galima teigti, kad dėl to nukenčia „Android“ programos našumas, nes vis dar kyla papildomų išlaidų.

„Ark Compiler“, sukurta „Huawei“.

„Huawei“ stengėsi sukurti efektyvesnį sprendimą, todėl pasamdė šimtus šios srities ekspertų. Šių pastangų rezultatas yra Ark Compiler, kuris, kaip teigia Huawei, yra pirmasis statinis kompiliatorius. kuri leidžia tiesiogiai išversti į mašininę kalbą, visiškai pašalinant poreikį vertėjas. „Ark Compiler“ taip pat buvo sukurtas siekiant maksimaliai padidinti „Java“ ir „C“ veikimo efektyvumą, todėl teoriškai turėtumėte pamatyti geriausius rezultatus naudojant šias kalbas.

„Huawei“ pateikia keletą pagrindinių „Ark Compiler“ funkcijų, kaip nurodyta toliau:

• Kompiliavimo metodai, tokie kaip AOT ir JIT, gali konvertuoti kai kurias programas į mašininį kodą ir paleisti jas tiesiai CPU, tačiau šie metodai negali visiškai atsiriboti nuo vertėjo ir su ja susijusių apribojimų. „Ark Compiler“ naudoja statinį kompiliavimą, kuris leidžia atsieti nuo dinaminio vertėjo, atverdamas galimybę padidinti programos našumą naudojant „šuoliais."
• Statinio kompiliavimo trūkumas yra tas, kad jis yra per griežtas ir negali atlikti koregavimų, kuriuos vykdydamas gali atlikti dinaminis kompiliatorius. „Huawei“ teigia, kad „Ark Compiler“ statinis kompiliavimas išsprendžia šią problemą.sklandžiai verčiant dinamines programavimo kalbos funkcijas į mašininį kodą."
• Esami kompiliavimo procesai vyksta įdiegiant programos paketą mobiliajame įrenginyje arba po jo. „Ark Compiler“ sukurtas diegti programinės įrangos kūrimo metu, o tai, mūsų manymu, padeda sumažinti diegimo ir vykdymo laiką. Manome, kad programų kūrėjai galės tiesiogiai kompiliuoti įvairias kalbas į savąjį mašininį kodą naudodami programą kūrimo procesą, todėl gautam APK negali būti reikalinga sąveika su vertėju ar virtualia mašina funkcija. Tai teoriškai sumažintų, pavyzdžiui, su JNI susijusias pridėtines išlaidas.
• Ark Compiler taip pat keičia kolektyvinį šiukšlių surinkimo pobūdį. Tai leidžia GC įvykiams įvykti atskirai skirtingose ​​Java gijose. Teigiama, kad šis suskirstytas metodas siūlo mažiau nešvarumų pirmojo plano programose.

Dėl šių pakeitimų „Ark Compiler“ gali iš pažiūros pagerina Android sistemos veikimo sklandumą iki 24%, atsako greitį iki 44%, o trečiųjų šalių programų sklandumą iki 60%, teigiantys, kad „Android“ programos našumas yra toks pat kaip ir „iOS“.

„Ark Compiler“ šiuo metu yra sudarytas ir optimizuotas ARM lustų architektūrai. „Huawei“ tikisi, kad ateityje bendras techninės ir programinės įrangos kūrimas padės maksimaliai padidinti „Kirin“ lusto galimybes.

„Ark Compiler“ palaiko standartinį „Java“ naudojimą, leidžiantį tiesiogiai kompiliuoti trečiųjų šalių programas, programų kūrėjui nereikia keisti kodo. „Ark Compiler“ taip pat leidžia „koreguoti kodo struktūrą“, kad būtų galima toliau tobulinti našumą ir atmintį. „Huawei“ nusprendė padaryti „Ark Compiler“ atvirojo kodo sistema, kuri leistų trečiųjų šalių kūrėjams pritaikyti ir pritaikyti technologiją savo poreikiams, toliau ją pritaikydami programėlių kūrėjams ir mobiliajam telefonui gamintojų.

Nors „Huawei“ nemini jokių „Ark Compiler“ trūkumų, galima tikėtis didelių programų dydžių. bent jau, bet tai neturėtų kelti jokių problemų dabartinės kartos įrenginiuose, kurie tiekiami pakankamai saugykla. Taip pat tikimės, kad „Ark Compiler“ nebus prieinama visoms procesorių architektūroms, nes „Google“ suderinamumo problemos nėra „Huawei“ galvos skausmas. Ark Compiler sukurtas naudoti kūrimo metu, o ne diegiant; tai rodo, kad „Huawei“ galbūt pakeitė programų diegimą ir įdiegimą „Android“ įrenginiuose, taip pat galėjo dirbti su savo APK dizainu. Jei tai teisinga, tai gali sukelti didelę suderinamumo problemą ekosistemoje, ir praeis daug laiko, kol tai taps standartine „Android“ funkcija, jei kada nors.

Nekompiliavimas vartotojo įrenginyje taip pat kelia didelį optimizavimo klausimą. Šiuo metu ART optimizuoja pagal mikro architektūrą, o tai reiškia, kad gautas dvejetainis dydis būtų skiriasi „Snapdragon“ ir „Exynos“ įrenginiu arba net „Snapdragon 845“ ir „Snapdragon“ įrenginiu 625. Šis požiūris yra prasmingas gamintojams, kurie visiškai kontroliuoja SoC, pavyzdžiui, Apple ir Huawei. Tačiau likusiam „Android“ pasauliui naudojant daugybę skirtingų SoC, privertus naudoti bendrą optimizavimą visuose įrenginiuose, vėl bus kliūtis „Ark Compiler“ standartizavimui. Todėl nesitikėkite, kad „Ark Compiler“ greitai pasieks jūsų mėgstamą tinkintą ROM.

Kad būtų aiškiau, „Ark Compiler“ sukurtas dirbti su „Android“, o „Huawei“ nieko nepaminėjo. tariama „Homebrew“ OS ir jo suderinamumas su Ark Compiler, todėl šiuo klausimu nedarome jokių prielaidų.

„Huawei“ planuoja surengti dvi pagrindines konferencijas, skirtas kūrėjams ir didesnei ekosistemai. Tai yra Huawei Device China Developers Conference ir Green Alliance China Developers Conference. Abiejuose renginiuose bus nagrinėjamos konkrečios atvirojo kodo problemos, susijusios su Huawei Ark Compiler, siekiant, kad šios technologijos privalumai būtų kuo plačiau prieinami.

---

Ypatingas ačiū XDA vyresniajam pripažintam bendradarbiui Dees_Troy ir pripažintas kūrėjas arter97 už pagalbą ir indėlį.

Pastaba: „Huawei/Honor“ nustojo teikti oficialius įkrovos įkrovos atrakinimo kodus savo įrenginiams. Todėl jų įrenginių įkrovos tvarkyklės negali būti atrakintos, o tai reiškia, kad vartotojai negali įsitvirtinti arba įdiegti pasirinktinių ROM.