Sannheten om maskinvareakselerasjon på Android

Android-maskinvareakselerasjon

Når den relativt åpne Android-plattformen sammenlignes med et tett kontrollert system som iOS, er en av de første forskjellene folk bemerker den overlegne glattheten til apper på iOS. Dette er noe Android har slet med siden starten, men mange av antagelsene om Android's grafiske system, og hvordan det er relatert til glatt grensesnitt, er feil. Googles ingeniør Dianne Hackborn forklarte nyheten om Android-maskinvareakselerasjonen nylig Google+ innlegg, og det er kanskje ikke den magiske kulen alle håpet på.

I motsetning til det vi alltid har hørt, har Android hatt det noen maskinvareakselerasjon for tegning av 2D UI-elementer siden før 1.0. Mange av animasjonene vi ser hver dag på Android har blitt akselerert maskinvare hele tiden. For eksempel trekkes menyer opp, dialogbokser, skyves ned på varslingslinjen og overgang mellom aktiviteter tegnes ved hjelp av GPU.

All 'vinduskomposering' gjøres ved hjelp av GPU-basert maskinvaregjengivelse. Vi kan tenke på dette som å tegne nye elementer på skjermen. Når du trykker på menyknappen, håndteres det resulterende overlegget av GPU. Hvis det overlegget endres, som om en knapp er uthevet eller trykkes, blir den endringen gjengitt i programvare, og de fleste telefoner er mer enn i stand til å trykke på disse pikslene. Når hele vinduet endres, er det en GPU-oppgave.



Så hva endrer seg i Iskremsandwich (ICS)? I følge Hackborn er det vi vil se i Android 4.0 “full” maskinvareakselerasjon. Alle brukergrensesnittelementer i windows og tredjepartsapper har tilgang til GPU for gjengivelse. Android 3.0 hadde det samme systemet, men nå vil utviklere kunne målrette spesifikt Android 4.0 med maskinvareakselerasjon. Google oppfordrer utviklere til å oppdatere apper for å være fullt kompatible med dette systemet ved å legge til maskinvareakselerasjonskoden i manifestet til en app.

Dette vil sannsynligvis ta tid ettersom utviklere sertifiserer appene sine på ICS, men Google har tatt med en bryter i Android-innstillingene for å tvinge frem maskinvare. Hackborn advarer om at i uprøvde apper har dette potensialet til å bryte ting på subtile eller grunnleggende måter. Dette er bare det første mulige problemet med maskinvareakselerasjon på Android.

Android Ice Cream SandwichVed å gjengi alle appens animasjoner og brukergrensesnitt med GPUen, tar systemet et treff for minnebruk. Å laste opp OpenGL-driverne for hver prosess tar minnebruk på omtrent 2 MB, og øker den til 8 MB. På enheter med begrenset RAM kan dette være et reelt problem. Når mer RAM spises opp, må systemet nødvendigvis lukke flere bakgrunnsoppgaver for å spare minne. Noen utviklere vil kanskje ikke bruke GPU til å tegne som et resultat.

Målet med maskinvar rendering for grensesnittet er å få jevnere drift, men hvis det ikke håndteres riktig, kan Android-enheter faktisk fungere dårligere. Ved å bruke eksemplet på Tegra 2, som kan gjengi alle piksler på en 1280 × 800 skjerm 2,5 ganger per sekund ved 60FPS, er problemet klart. GPU berører hver piksel en gang for bakgrunnen, en gang for ikoner og widgets, en gang til for etiketter, og så er det animasjoner å håndtere. Det er ingen måte å nå 60FPS på å gjøre ting på en slik måte.

Android gjør maskinvareakselerasjon med en rekke triks, og utviklere bør ta oppmerksom på det. For det første kopieres separate vinduer i grensesnittet til enhetlige overlegg for mer effektiv GPU-tilgang. Android gjengir også bakgrunnen som en stor bitmappe som ikke trenger å gjengis på nytt når brukeren blar rundt.

Utviklere må være forsiktige når det gjelder håndtering av maskinvareakselerasjon. Bare å tegne alt med GPU kan føre til dårlig ytelse på eksisterende telefoner. For fremtiden, jo høyere oppløsningen på en enhet er, desto mer relatert GPU-hastighet vil være den generelle jevnheten og nærheten til den 60FPS-terskelen. Den begrensende faktoren for enhetens hastighet vil ofte være GPU-minnebussbåndbredden fremover.

Copyright © Alle Rettigheter Reservert | 2007es.com