Android Go er Googles nedstrippede versjon av Android Oreo 8.1 for nye enheter med lite RAM. Som det viser seg, kan det hjelpe tilpasset ROM-utvikling på eldre enheter også.
Android Go er Googles nedstrippede versjon av Android basert på Android 8.1 Oreo, og den har som mål å være en optimalisert versjon av Android for low-end-enheter med 1 GB RAM eller lavere. Det ble annonsert i mai i fjor på Google I/O Developer-konferansen, og til slutt ble flere detaljer avslørt i desember senere samme år. Det ble sagt å være laget for neste generasjons enheter på inngangsnivå, for å sikre at de som er i utviklingsland kan fortsatt bruke fungerende smarttelefoner for å få tilgang til internett og bruke apper.
Go har et bredt utvalg av ytelsesoptimaliseringer og forbedringer, inkludert å ta opp 50 prosent mindre lagringsplass enn en gjennomsnittlig Android Oreo-installasjon. Takket være Android Runtime (ART) og kjerneoptimalisering også, vil en enhet som kjører Android Go i gjennomsnitt kjøre 15 prosent raskere enn på en vanlig Android Oreo-installasjon på samme enhet. Disse optimaliseringene er gjort gjennom en rekke spesialiserte byggekonfigurasjoner laget av Google, som vi kommer til å forklare senere.
Android Go drar også nytte av spesielle "Go"-applikasjoner, som f.eks Files Go, YouTube Go og Google Maps Go. Dette er lette versjoner av applikasjoner laget av Google, som har reduserte krav til å kjøre mer effektivt. Dette betyr at de med Android Go-enheter kan nyte de fleste av de samme fordelene som vanlige Android Oreo-brukere også kan, noe som gjør bruk av Googles programpakke uten å måtte bruke mye penger på et flaggskip eller til og med litt dyrere budsjett enhet.
Det handler om at Google utvider markedet sitt. Likevel reiser det spørsmålet at hvis Android Go for det meste består av en byggekonfigurasjon og en pakke med optimaliserte Google-apper, kan utviklere lage sine egne builds av Android Go? Kort oppsummert, Ja vi kan.
Noen få LineageOS-utviklere bygger allerede Android Go-optimaliserte tilpassede ROM-er
Vi ser allerede noe av en oppgang i Android Go fra noen tilpassede ROM-utviklere, for eksempel av XDA Recognized Developer AdrianDC, med sitt arbeid på LineageOS 15.1 med Android Go byggekonfigurasjoner for flere gamle Sony-telefoner. Enhetene det er snakk om er Sony Xperia SP, Sony Xperia T, Sony Xperia V og Sony Xperia TX. Alle disse enhetene dateres tilbake til årene 2012 og 2013, men de vil motta LineageOS 15.1 basert på Android 8.1 Oreo med en Android Go build-konfigurasjon, som kan tillate enhetene å kjøre Google 'Go'-apper flytende, dersom et Android Go-sett med Gapps til slutt løslatt.
Enhver individuell LOS-vedlikeholder bør kunne introdusere en Android Go-konfigurert bygg, med det som et sett med byggekonfigurasjoner og andre optimaliseringer. Hva dette betyr er at de som kan ha kjøpt Sony Xperia T for eksempel, en enhet som kjører Android 4.0.4 Ice Cream Sandwich ved lansering, vil kunne bruke en bedre optimalisert konstruksjon av Android 8.1 Oreo på enheten, ved å bruke applikasjoner som YouTube Go og Google Maps Go. Det kommer ikke til å kjøre på flaggskipsnivåer av ytelse, men det burde være brukbar– spesielt for en enhet som dateres tilbake til 2012.
Hvordan Android Go kan hjelpe eldre Android-telefoner med å kjøre Android Oreo
Byggkonfigurasjoner på Android er et sett med parametere som gjelder ulike aspekter av Android-systemet som brukes når systembildet kompileres for å blinke på en enhet. Vanligvis endrer disse hvordan systemet oppfører seg, og Android Gos viktigste optimaliseringer kommer fra disse byggekonfigurasjonene.
Jeg snakket med XDA Recognized Developer joshuous, som hjalp meg veldig med å forstå endringene som fant sted – hva som virkelig får Android Go til å fungere. Noen av disse byggekonfigurasjonene kan ikke endres uten å rekompilere, og er en del av planen til selve ROM-en. Dette er flaggene med store bokstaver.
Alle disse flaggene gjelder imidlertid mange forskjellige aspekter av Android knyttet til lagring og minnebruk. Disse inkluderer automatisk lagringshåndtering, Androids morder med lavt minne, dex (dalvik eksecutable filer) optimizer og RAM-grenser for å kjøre apper. APK-filer består av disse DEX-filene, så på en måte er det mulig å tenke på en APK-fil som bare en ZIP-fil som inneholder mange .dex-filer, som faktisk er det Android kjører når den kjører en applikasjon. Automatisk lagringsadministrasjon vil i stedet bli kontrollert av Files Go-applikasjonen, ikke Android-systemet.
Android Go Utilities Androids Low RAM-modus
I Android 4.4 KitKat introduserte Google et nytt flagg kalt "lav-ram", som var rettet mot å støtte enheter med 512 MB RAM. Det gjør en rekke optimaliseringer av systemet. Disse endringene er svært fordelaktige for enheter med lavere RAM.
Forbedret minnehåndtering
- Validerte minnebesparende kjernekonfigurasjoner: Bytt til ZRAM.
- Drep hurtigbufrede prosesser hvis de er i ferd med å bli ubufrede og for store.
- Ikke la store tjenester sette seg tilbake i A Services (slik at de ikke kan føre til at starteren blir drept).
- Drep prosesser (selv uavlivbare prosesser som den nåværende IME) som blir for store i inaktivt vedlikehold.
- Serialiser lanseringen av bakgrunnstjenester.
- Justert minnebruk av enheter med lite RAM: strammere justeringsnivåer for tomt for minne (OOM), mindre grafikkbuffer osv.
Disse endringene ovenfor sikrer i utgangspunktet at systemet sørger for å bruke komprimert RAM der det er mulig, gjennom bruk av ZRAM. ZRAM er i utgangspunktet en RAMdisk (et lagringsmedium som bruker RAM, mye raskere enn å bruke vanlig lagring på enheten) som en byttefil. En byttefil brukes når RAM-bruken er høy og programmer fortsatt krever minne. Dette er mye, mye tregere enn RAM og bør unngås der det er mulig. I hovedsak komprimerer den ganske enkelt innholdet i minnet.
Redusert systemminne
- Trimmet system_server og SystemUI-prosesser (lagret flere MB).
- Forhåndslast dex-cacher i Dalvik (lagret flere MB).
- Validert JIT-off-alternativ (sparer opptil 1,5 MB per prosess).
- Redusert per-prosess fontbuffer overhead.
- Introduserte ArrayMap/ArraySet og brukes mye i rammeverk som en erstatning for HashMap/HashSet med lettere fotavtrykk.
Det som stort sett skjer her er bare redusert minneforbruk fra ulike prosesser som kjører på enheten, for å være så konservativ som mulig. Essensielle systemtjenester har blitt strippet for å bruke så lite minne som mulig i bakgrunnen, siden hver megabyte med RAM er viktig.
Android Go bruker en modifisert lavminnekiller og dex-optimaliseringer
Gitt at Android Go hovedsakelig er for enheter med 1 GB RAM eller mindre, må det være mer aggressiv minnebehandling. Android Go modifiserer Low Memory Killer (LMK) på noen forskjellige måter. For det første, når en høy mengde RAM er brukt opp, går lavminnemorderen til en "kritisk press" stat. Dette er fordi når minnebruken er høy, vil systemet bli tregt på grunn av konstant forsøk på å få tilgang til en byttefil på enhetens lagring. Å holde RAM-minnet klart vil forhindre at systemet trenger å bruke denne swap-filen og forhindre minnetrasking. Memory thrashing oppstår når enhetens minne er fullt, og hele tiden må søke i swap-filen på enhetens lagring, noe som svekker ytelsen kraftig.
Tjenester og WiFi-tjenester er satt til "hastighetsprofil," som betyr at utvalgte metoder i disse tjenestene er Ahead-of-Time (AOT) kompilert. (En metode refererer til et sett med kode som kan kalles når som helst ved navn.) Dette reduserer RAM-bruk og lagring, da Android-systemet ikke trenger å kontinuerlig rekompilere viktige tjenester som kjører på enhet. I mellomtiden er delte APK-er satt til "quicken", som er designet for å gi ekstra batterilevetid og ekstra CPU-sykluser ved å optimalisere dex-instruksjoner for å få bedre ytelse.
Når det gjelder dex-optimaliseringer, gjør Android Go ganske mye. For det første, etter 10 dager vil det nedgradere en applikasjon hvis den ikke brukes for å spare plass. Nedgradering her refererer ikke til at det faktiske versjonsnummeret til applikasjonen synker, men det betyr snarere at dalvik_cachen for appen blir slettet. Dalvik-cachen brukes slik at enheten ikke trenger å rekompilere apper, i stedet kompilerer den bare de mest nødvendige delene av den og cacher den. Resten kompileres ved hjelp av Just in Time (JIT) kompilatoren når applikasjonen kjøres. Hvis applikasjonen imidlertid ikke brukes på 10 dager, fjernes også de vesentlige delene av applikasjonen som er forhåndskompilert. Dette gjøres for å frigjøre mest mulig plass. En annen enkel endring er å ikke tillate at RAM-bruken til en app overskrider 256 MB, slik at en app ikke kan bruke all RAM-en på enheten.
Er Android Go fremtiden for tilpasset ROM-utvikling på low-end-enheter?
Foreløpig vet vi ikke svaret på dette, men fremtiden ser lys ut for tilpasset ROM-utvikling på eldre enheter. Det kan være andre problemer med å få en nyere versjon av Android til å kjøre på en enhet, men i teorien er det en oppgradering til en mer optimalisert Android Go basert på Android Oreo bør få en eldre, low-end enhet til å fungere bedre.