Programavimas

„WebAssembly“ pradžia: pradėkite naudoti „WebAssembly“

„WebAssembly“ žada visiškai naują žiniatinklio rūšį - greitesnį našumą vartotojams ir daugiau lankstumo kūrėjams. Užuot uždaręs „JavaScript“ kaip vienintelę kalbą kliento žiniatinklio sąveikai, kūrėjas gali pasirinkti iš daugybės kitų kalbų - C, „TypeScript“, „Rust“, „Ruby“, „Python“ - ir dirbti ta kalba, kuri jiems patogiausia. su.

Iš pradžių vienintelis būdas sukurti „WebAssembly“ (arba sutrumpintai - WASM) buvo surinkti C / C ++ kodą į „WebAssembly“ naudojant „Emscripten“ įrankių grandinę. Šiandien ne tik kūrėjai turi daugiau kalbų galimybių, bet ir lengviau sudaryti šias kitas kalbas tiesiai į „WebAssembly“, atliekant mažiau intervencinių veiksmų.

Šiame kūrinyje mes išnagrinėsime veiksmus, reikalingus norint įdiegti „WebAssembly“ komponentus žiniatinklio programoje. Kadangi „WebAssembly“ yra nebaigta veikla, veiksmai labai priklauso nuo to, kurią kalbą naudojate, o įrankių grandinė greičiausiai kurį laiką keisis. Tačiau šiuo metu galima parašyti ir įdiegti naudingas, jei reikia, „WebAssembly“ programas keliomis kalbomis.

Pasirinkite „WebAssembly“ palaikomą kalbą

Pirmasis žingsnis diegiant „WebAssembly“ programą yra pasirinkti kalbą, kurią galima sukonfigūruoti „WebAssembly“ kaip tikslą. Yra didelė tikimybė, kad bent vieną iš pagrindinių kalbų, kurias naudojate gamyboje, galima konvertuoti į „WebAssembly“ arba turėti kompiliatorių, kuris gali skleisti „WebAssembly“.

Čia yra pirmieji bėgikai:

  • C. Akivaizdu. Tipiškas būdas paversti C kodą „WebAssembly“ yra per „Emscripten“, nes „C-to-Emscripten-to-WebAssembly“ buvo pirmasis „WebAssembly“ įrankių tinklas. Tačiau atsiranda kitų priemonių. Visas kompiliatorius „Cheerp“ buvo sukurtas specialiai tam, kad generuotų „WebAssembly“ programas iš C / C ++ kodo. „Cheerp“ taip pat gali nukreipti į „JavaScript“, asm.js ar bet kurį aukščiau nurodytą derinį. Taip pat galima naudoti „Clang“ įrankių grandinę, kad sukurtumėte „WebAssembly“ naudingąsias apkrovas, nors procesas vis tiek reikalauja nemažai rankinio kėlimo. (Čia yra vienas pavyzdys.)
  • Rūdys. „Mozilla“ sistemų programavimo kalba, sukurta taip, kad būtų saugu ir greita, yra viena iš pagrindinių kandidatų gimtoji „WebAssembly“ palaikymas. Įrankių grandinės „Rust“ plėtiniai leidžia rinkti tiesiogiai iš „Rust“ kodo į „WebAssembly“. Jums reikia naudoti „Rust’s“ kasnakt įrankių grandinė, skirta atlikti „WebAssembly“ kompiliavimą, todėl ši funkcija kol kas turėtų būti laikoma eksperimentine.
  • „TypeScript“. Pagal numatytuosius nustatymus „TypeScript“ kompiliuoja į „JavaScript“, o tai reiškia, kad jį savo ruožtu galima sukompiliuoti į „WebAssembly“. „AssemblyScript“ projektas sumažina atliekamų veiksmų skaičių, leidžiant griežtai įvestą „TypeScript“ kompiliuoti į „WebAssembly“.

Kelios kitos kalbos pradeda taikyti „WebAssembly“, tačiau jos yra labai ankstyvoje stadijoje. Šias kalbas galima naudoti kuriant „WebAssembly“ komponentus, tačiau tik ribotais būdais nei „C“, „Rust“ ir „TypeScript“:

  • D. D kalba neseniai papildė kompiliavimo ir tiesioginio susiejimo su „WebAssembly“ palaikymą.
  • „Java“. „Java“ baitinį kodą galima iš anksto surinkti „WebAssembly“ per „TeaVM“ projektą. Tai reiškia bet koks „Java“ baitekodą skleidžiančią kalbą galima sukompiliuoti į „WebAssembly“, pavyzdžiui, „Kotlin“, „Scala“ ar „Clojure“. Tačiau daugelis „Java“ API, kurių negalima veiksmingai įdiegti „WebAssembly“, yra apribotos, pvz., Atspindžio ir išteklių API, todėl „TeaVM“ - taigi ir „WebAssembly“ - yra naudingi tik JVM pagrįstų programų pogrupiui.
  • Lua. „Lua“ scenarijų kalba, kaip ir „JavaScript“, turi ilgą istoriją kaip įterptoji kalba. Tačiau vieninteliai projektai, kuriais „Lua“ paverčiama „WebAssembly“, apima naršyklės vykdymo variklio naudojimą: „wasm_lua“ į naršyklę įdeda „Lua“ vykdymo laiką, o „Luwa JIT“ kompiliuoja „Lua“ į „WebAssembly“.
  • Kotlinas / Gimtoji. „Java“ spinoffo „Kotlin“ kalbos gerbėjai nekantriai laukė visiško „Kotlin / Native“ išleidimo - „LLVM“ galinės versijos „Kotlin“ kompiliatoriui, galinčiam sukurti atskirus dvejetainius failus. „Kotlin / Native 0.4“ pristatė „WebAssembly“ palaikymą kaip kompiliavimo tikslą, bet tik kaip koncepcijos įrodymą.
  • .Net. .Net kalbos dar neturi visiško „WebAssembly“ palaikymo, tačiau kai kurie eksperimentai pradėti. Žr. „Blazor“, kurį galima naudoti kuriant vieno puslapio žiniatinklio programas .Net naudojant C # ir „Microsoft“ sintaksę „Skustuvas“.
  • Nim. Ši nauja kalba ateina į C, taigi teoriškai galima būtų sukompiliuoti gautą C į WebAssembly. Tačiau yra kuriama eksperimentinė „Nim“ programa, vadinama „nwasm“.
  • Kitos LLVM valdomos kalbos. Teoriškai bet kurią kalbą, kuri naudoja LLVM kompiliatoriaus struktūrą, galima sukompiliuoti į „WebAssembly“, nes LLVM palaiko „WebAssembly“ kaip vieną iš daugelio taikinių. Tačiau tai nebūtinai reiškia, kad kuri nors LLVM sukompiliuota kalba veiks tokia, kokia yra „WebAssembly“. Tai tiesiog reiškia, kad LLVM palengvina taikymą prie „WebAssemble“.

Visi pirmiau minėti projektai konvertuoja pradinę programą arba sugeneruotą baitkodą į „WebAssembly“. Tačiau aiškinamoms kalboms, tokioms kaip „Ruby“ ar „Python“, yra kitas požiūris: užuot konvertuojus pačias programas, kalbą galima konvertuoti vykdymo laikas į „WebAssembly“. Tuomet programos veikia taip, kaip yra konvertuotu vykdymo laiku. Kadangi daugelis kalbos vykdymo laiko (įskaitant „Ruby“ ir „Python“) yra parašyti C / C ++, konversijos procesas iš esmės yra toks pats kaip ir bet kurios kitos C / C ++ programos.

Žinoma, tai reiškia, kad konvertuotą vykdymo laiką reikia atsisiųsti į naršyklę, kad būtų galima paleisti bet kokias programas, sulėtinant apkrovą ir analizuojant laiką. „Gryna“ programos „WebAssembly“ versija yra lengvesnė. Taigi vykdymo laiko konversija yra geriausia priemonė, kol daugiau kalbų nepalaiko „WebAssembly“ kaip eksporto ar kompiliavimo tikslo.

Integruoti „WebAssembly“ su „JavaScript“

Kitas žingsnis - parašyti kodą pasirinkta kalba, atkreipiant dėmesį į tai, kaip tas kodas veiks su „WebAssembly“ aplinka, tada sukompiliuokite jį į „WebAssembly“ modulį (dvejetainį WASM) ir galiausiai integruokite tą modulį su esamu „JavaScript“ programa.

Tikslūs kodo eksportavimo į „WebAssembly“ žingsniai labai skirsis, atsižvelgiant į įrankių grandinę. Jie taip pat šiek tiek nukryps nuo to, kaip šiai kalbai kuriami įprasti vietiniai dvejetainiai failai. Pavyzdžiui, programoje „Rust“ turėsite atlikti kelis veiksmus:

  1. Nustatykite kasnakt statyti Rustui su wasm32-nežinomas-nežinomas įrankių grandinė.
  2. Parašykite savo „Rust“ kodą, nurodydami išorines funkcijas kaip Nr. [be jokios].
  3. Sukurkite kodą naudodami aukščiau pateiktą įrankių grandinę.

(Jei norite išsamiai aprašyti anksčiau nurodytus veiksmus, žr. „GustHub“ pateiktą „The Rust and WebAssembly Book“.)

Verta paminėti, kad nesvarbu, kokią kalbą naudojatės, norint integruoti kodą su HTML sąsaja, turite turėti bent minimalų „JavaScript“ mokėjimo lygį. Jei šiame pavyzdyje esantys „JavaScript“ fragmentai iš „The Rust“ ir „WebAssembly Book“ jums atrodo graikiški, skirkite šiek tiek laiko išmokti bent tiek „JavaScript“, kad suprastumėte, kas ten vyksta.

„WebAssembly“ ir „JavaScript“ integravimas atliekamas naudojant Žiniatinklio asamblėja objektą „JavaScript“, kad sukurtumėte tiltą į savo „WebAssembly“ kodą. „Mozilla“ turi dokumentus, kaip tai padaryti. Čia yra atskiras „Rust“ „WebAssembly“ pavyzdys, o „Node.js“ - „WebAssembly“ pavyzdys.

Šiuo metu integracija tarp „WebAssembly“ galinės dalies ir „JavaScript“ / HTML sąsajos vis dar yra sudėtingiausia ir neautomatinė viso proceso dalis. Pavyzdžiui, naudojant „Rust“, „JavaScript“ tiltai vis tiek turi būti sukurti rankiniu būdu, naudojant neapdorotų duomenų rodykles.

Tačiau daugiau įrankių grandinės dalių pradeda spręsti šią problemą. „Cheerp“ sistema leidžia C ++ programuotojams kalbėtis su naršyklės API per tam skirtą vardų sritį. „Rust“ siūlo „wasm-bindgen“, kuris yra dviejų krypčių tiltas tarp „JavaScript“ ir „Rust“ bei tarp „JavaScript“ ir „WebAssembly“.

Be to, svarstomas aukšto lygio pasiūlymas, kaip tvarkyti pririšimus prie pagrindinio kompiuterio. Baigęs jis suteiks standartinį būdą kalboms, kurios kaupiamos „WebAssemble“, sąveikauti su pagrindiniais kompiuteriais. Ilgalaikė strategija su šiuo pasiūlymu taip pat apima susiejimus su pagrindiniais kompiuteriais, kurie nėra naršyklės, tačiau naršyklių susiejimai yra trumpalaikis, neatidėliotinas naudojimo atvejis.

Derinimas ir „WebAssembly“ programų profiliavimas

Viena iš sričių, kurioje „WebAssembly“ įrankiai vis dar yra ankstyviausi, yra palaikymas derinant ir profiliuojant.

Kol atsirado „JavaScript“ šaltinių žemėlapiai, į „JavaScript“ sukompiliuotas kalbas dažnai buvo sunku derinti, nes originalaus ir sukompiliuoto kodo nebuvo galima lengvai susieti. „WebAssembly“ turi keletą tų pačių problemų: jei parašote kodą C ir kompiliuojate į WASM, sunku nustatyti koreliacijas tarp šaltinio ir sukompiliuoto kodo.

„JavaScript“ šaltinio žemėlapiai nurodo, kurios šaltinio kodo eilutės atitinka kuriuos sukompiliuoto kodo regionus. Kai kurie „WebAssembly“ įrankiai, pvz., „Emscripten“, taip pat gali išleisti „JavaScript“ šaltinio žemėlapius sukompiliuotam kodui. Vienas iš ilgalaikių „WebAssembly“ planų yra šaltinio žemėlapių sistema, viršijanti tik tai, kas yra „JavaScript“, tačiau ji vis dar yra tik pasiūlymo stadijoje.

Šiuo metu paprasčiausias būdas derinti WASM kodą lauke yra naudojant žiniatinklio naršyklės derinimo konsolę. Šiame „WebAssemblyCode“ straipsnyje parodyta, kaip sugeneruoti WASM kodą naudojant šaltinio žemėlapį, padaryti jį prieinamą naršyklės derinimo įrankiams ir pereiti per kodą. Atminkite, kad aprašyti veiksmai priklauso nuo emcc WASM skleidimo įrankis. Gali tekti modifikuoti veiksmus atsižvelgiant į konkretų įrankių tinklą.

$config[zx-auto] not found$config[zx-overlay] not found