- - Hva er ART & Hvordan er det forskjellig fra Dalvik Virtual Machine på Android?

Hva er ART & Hvordan er det forskjellig fra Dalvik Virtual Machine på Android?

I verden av teknologi, nye terminologier ogforkortelser er ikke noe nytt, og til tider, med hver nye utgivelse av til og med eksisterende programvare, kan det hende du ser et nytt begrep som alle ser ut til å bruke og forstå. Problemet for nybegynnere og til og med mange tilfeldige brukere er imidlertid at de verken helt forstår hva den nye konnotasjonen betyr, og heller ikke kan de lett finne ut om det på egen hånd fra offisielle kilder, først og fremst på grunn av det faktum at utviklere ikke er t for opptatt av å forklare mange slike terminologier og deres tekniske detaljer. I beste fall vil du bli pekt på en offisiell lenke som gir en forklaring, men i så tekniske termer at det er ganske ubrukelig for en ikke-tekniker.

Vi i AddictiveTips har alltid stolt overdumme ned tekniske konsepter og gi svar på vilkår som er behagelige for den tilfeldige brukeren og den teknologiske nybegynneren. Da Google bestemte seg for å introdusere ART med Android 4.4 KitKat, så vi dette som en mulighet til å introdusere leserne våre for det nye runtime-miljøet og hjelpe alle til å forstå hva alt dette handler om, og hvordan skiller det seg fra den virtuelle Dalvik-maskinen som ART bygges for å erstatte.

Hva-er-ART_vs-Dalvik-Android-Runtime-miljøer

Hva er et kjøretidsmiljø?

Før vi kommer til å svare på det faktiske spørsmålet,vi må forstå hva et kjøretidsmiljø faktisk er. For å sette de enkleste vilkårene, består runtime av programvareinstruksjoner som kjøres når programmet ditt kjører, selv om de ikke egentlig er en del av koden til det stykke programvaren spesielt. Disse instruksjonene oversetter i utgangspunktet programvarens egen kode til koden datamaskinen er i stand til å kjøre. Derfor krever alle dataspråk et slags runtime-miljø som kan utføre koden skrevet på det språket på riktig måte.

Android bruker en virtuell maskin som sinruntime-miljø for å kjøre APK-filene som utgjør en Android-applikasjon. Fordelen med å bruke en virtuell maskin er todelt - for det første er app-koden isolert fra operativsystemet for kjernen, noe som sikrer at hvis noe går galt, er det inne i et isolert miljø og påvirker ikke det primære operativsystemet. Og for det andre gir det mulighet for krysskompatibilitet, noe som betyr at selv om en app er kompilert på en annen plattform (for eksempel en PC, som vanligvis er tilfelle med utvikling av mobile apper), kan de fremdeles kjøres på mobilplattformen ved hjelp av den virtuelle maskinen .

For Android, den virtuelle maskinbaserte runtimemiljøet som er brukt så langt er kjent som Dalvik Virtual Machine, som jeg er sikker på at alle som noen gang har gravet seg inn i detaljene i operativsystemet, er mer enn kjent med.

Hvorfor bruke en virtuell maskin i det hele tatt?

Det er faktisk poenget vi berørte rett over. Virtuelle maskiner går tregt, det er ikke noe som nekter for det, men de har faktisk et par fordeler som gjør dem til et foretrukket valg.

  • Virtuelle maskiner leverer et isolert miljøfor kodeutførelse. Selv om en app inneholder et ondsinnet stykke kode som kan skade kjerne OS, vil det derfor ikke påvirke systemfilene direkte, og dermed vil ikke kjernens OS bli skadet. Den store fordelen er mer stabilitet og pålitelighet for operativsystemet.
  • App-APK-ene som blir levert gjennom Play Store(eller noen annen kilde, for den saks skyld) er ukompilerte instruksjoner som utviklere er avhengige av at den virtuelle maskinen skal kompilere før kjøringen og kjøres på enheten. Dette gir mer kompatibilitet; Hvis utvikleren skulle tilby allerede kompilert kode og den ble kompilert for en Snapdragon-basert prosessor, kan det hende at den ikke kjører riktig på en Tegra-brikke. Derfor samler denne enheten på dette problemet.

Så, hva er Dalvik, og hva er galt med det?

Det er spørsmålet å stille, er det ikke? Dalvik har vært der siden Android startet i 2007, og det har ikke endret seg mye siden den gang, bortsett fra Just-In-Time (JIT) -tilnærmingsmetoden som ble introdusert i Android 2.2 Froyo, som i utgangspunktet kompilerer apper akkurat når de er lansert, eller når brukeren leverer de nødvendige instruksjonene. Det er nyttig, så vel som en forbedring i forhold til den forrige konvensjonelle tolke-tilnærmingen som kompilerte og kjørte kode linje for linje mens den kjørte, men ulempen er et stort overhead når appen lanseres for første gang.

Dette er fordi systemet trenger å trekke seg sammenalle nødvendige filer, kompiler appen og last den inn i RAM. Så lenge den kompilerte appen forblir innenfor RAM-en, vil den fortsette å svare snapp, men når du laster inn flere apper og RAM-en går tom, blir den første losset, og følgelig, etter påfølgende lansering, starter hele prosessen. Tilnærmingen gir mening på papiret, og har faktisk fungert fint til nå for plattformen. Imidlertid lider eldre enheter med begrenset RAM mest, fordi laste- / lossingssyklusen fortsetter oftere, og følgelig føles systemet tregt med tanke på generell respons. Det er her den nye virtuelle maskinen, ART, kommer inn.

Hva er ART & Hvordan forbedrer det ting?

ART eller Android RunTime (ganske halt navn, ja,vi vet) er en ny eksperimentell virtuell maskin som Google har introdusert med Android 4.4 KitKat som et utvikleralternativ (med Dalvik som fortsatt er det settet som standard for nå). Den primære forskjellen mellom ART og Dalvik er samlingen tilnærming som begge disse bruker - ART benytter et nytt Ahead-Of-Time-konsept (AOT) i strid med Dalviks JIT, som i utgangspunktet kompilerer apper før de til og med lanseres. Hva dette betyr er at førstegangsinstallasjoner vil ta lengre tid, og apper vil ta mer plass på intern lagring, men samtidig, siden appen vil bli fullstendig kompilert så snart den er installert, vil lanseringstidene være mye raskere. På samme måte, siden kompileringsdelen er ivaretatt bare en gang ved installasjon, er prosessoravgift lavere, noe som resulterer i bedre batterilevetid og generell ytelse.

Dalvik Vs. KUNST - Sammenligning

La oss bare gjøre en rask sammenligning av begge de virtuelle maskinene før vi går videre.

Dalvik

KUNST

Bruker Just-In-Time (JIT) tilnærming, noe som resulterer i lavere lagringsplassforbruk, men lengre belastningstider for appenBruker AOT-Of-Time (AOT) -tilnærming, som kompilerer apper når de er installert, noe som resulterer i raskere belastningstid og lavere prosessorbruk
Cache bygger seg opp over tid, så oppstartstidene er raskereCache er bygget ved første oppstart, og det tar derfor betydelig lengre omstart av enheten
Fungerer bedre for lavere interne lagringsenheter ettersom det er mindre plassForbruker mye mer intern lagringsplass siden den lagrer kompilerte apper i tillegg til APK-ene
Er stabil og tidstestet - VM valgt for apputviklereEr veldig eksperimentell og ny - ikke mye støtte fra apputviklere ennå

Du sier at ART er eksperimentelt ...

Ja, og akkurat nå er den bare tilgjengelig påenheter med Snapdragon-brikkesett og kjører Android 4.4 KitKat. Du har muligheten til å bytte fra Dalvik til ART fra de skjulte utvikleralternativene, hvis du ønsker det, men vær oppmerksom på at noen av appene dine kanskje ikke fungerer som de skal. Hvis det allerede er en app-cache som er bygget under Dalvik, kan det hende at den første omstarten etter at du har byttet kan ta opptil en halv time.

Google har først og fremst gjort ART tilgjengelig medKitKat for utviklere å leke med og etablere grunnlag for en permanent bytte i fremtiden. Og dette innebærer på ingen måte at ART er klar til bruk i dag. Det vil være i fremtiden, men foreløpig er den eksperimentell og ikke egnet for daglig bruk av sluttbrukeren.

Når det gjelder fordelene med ART, er det blandederapporter. For de fleste anmeldere består testenhetene av firkjerneprosessorer med over 2 spillejobber, som er et mer enn tilstrekkelig oppsett for å virkelig observere hastighetsgevinstene fra ART. Likevel rapporterer tilfeldige brukere om gevinst oppover på 50% i hastighet og mer enn 30% i batterilevetid. Atter andre hevder at det ikke er mer enn en placebo-effekt.

I all rettferdighet kan ingenting sies før detblir tilgjengelig for masser og mister den eksperimentelle koden. Derfor vil vi redde debatten til senere. Det som kan sies på dette punktet med sikkerhet, er at ART er fremtiden. Google kommer til å følge med på forhånd for å samsvare med iOS, det er den største motparten, og ART kommer til å bane vei. Uansett hvor dumt navnet kan virke eller hvor ufullstendig det er akkurat nå, fortsetter vi å se ART mer og mer.

kommentarer