Teemu Laitila
8. joulukuuta, 2011 17:56
Googlen Android-käyttöjärjestelmän suunnittelun parissa työskentelevä insinööri Diane Hackborn on kirjoittanut kattavan selvityksen Androidin nykyisestä ja menneestä tuesta käyttöliittymän rautakiihdytykselle.
Selonteolla Hackborn kertoo haluavansa korjata netissä jatkuvasti vastaantulevia täysin virheellisiä väittämiä Androidin laitteistokiihdytykseen liittyen. Ensimmäiseksi Hackborn selventää, että Android on jo 1.0 versiosta alkaen tukenut rautakiihdytystä ainakin jossain määrin. Laitteisto- tai rautakiihdytyksellä viitataan erillisen näytönohjaimen hyödyntämiseen grafiikan piirtämisessä pelkän prosessorin laskentatehoon nojautumisen sijaan.
Vaikka esimerkiksi ruudun yläosassa näkyvää tilapalkkia ja sen sisältämiä animaatioita ei piirretäkkään näytönohjaimen avulla, monien valikoiden liikkeet kuten tilapalkin laajentamisen animaatio on jo alusta alkaen hoidettu laitteistokiihdytyksellä. Ikkunoiden sisustat kuten valikoiden selaaminen voidaan nykyäänkin hoitaa pelkästään prosessorin laskentatehoa hyödyntämällä, sillä nykypuhelinten teho riittää 480x800 pikselin pyörittämiseen 60 fps nopeudella mainiosti.
Uuden Android 4.0 Ice Cream Sandwichin mainitaan monesti tuovan "todellisen" laitteistokiihdytyksen Androidiin. Hackbornin mukaan jo tableteille tarkoitetun Honeycomb-version laitteistokiihdytys oli yhtä "todellinen" ja ainut muuttunut asia on laitteistokiihdytyksen automaattinen käyttö niissä sovelluksissa, jotka on julkaistu nimenomaan uudelle alustalle.
Lisäksi Hackborn selittää, että laitteistokiihdytys ei ole automaattinen avain onneen. Grafiikkakiihdytyksessä käytetyn OpenGL-rajapinnan käyttö sovelluksessa kasvattaa sovelluksen kuluttaman muistimäärän moninkertaiseksi, joka lisäksi kertautuu jokaisen uuden kiihdytetyn sovelluksen kohdalla. Hackbornin mukaan esimerkiksi Nexus S -puhelimessa päädyttiin kasvattamaan suorituskykyä poistamalla käytöstä grafiikkakiihdytys niissä kohteissa, joissa sen käyttö ei ole täysin pakollista. Käyttäjä ei Hackbornin mukaan huomaa eroa, prosessori hoitaa suuren osan töistä sulavalla 60 fps nopeudella.
Kiihdytyksestäkään huolimatta sovelluksen käyttöliittymä ei välttämättä toimi aina sulavasti. Sujuvuuteen vaikuttaa moni asia, kuten kernelin tasolla tapahtuva säikeiden ja tehtävien ajoitus sekä eri tehtävien priorisointi. 60 fps nopeuden saavuttaminen tarkoittaa sitä, että jokaisen ruudun piirtämiseen on aikaa vain 20 millisekuntia. Sulavaan ruudunpäivitykseen johtavasta aikataulusta voidaan myöhästyä esimerkiksi siksi, että sovellus kuluttaa tuhottomasti aikaa flash-muistiin kirjoittamiseen.
Android-laitteiden näyttöjen resoluution kasvaessa tulevaisuudessa laitteistokiihdytys nousee kuitenkin aiempaa suurempaan rooliin. Esimerkiksi Googlen pian markkinoille saapuvan Galaxy Nexuksen ruudunpäivitys hyytyisi pahan kerran, jos koko homma jätettäisiin prosessorin harteille. Hackborn painottaakin eri laitteiden vertailun vaikeutta, jos näyttöjen resoluutiot poikkeavat toisistaan merkittävästi. Verrattuna Samsungin Galaxy S II -malliin, Galaxy Nexus joutuu isomman resoluutionsa vuoksi piirtämään ruudulle 2,4 kertaa enemmän pikseleitä, joka ei suju sulavasti ilman näytönohjaimen apua. Jos käytetty sovellus ei hyödynnä näytönohjaimen laskentatehoa, huippunopea Galaxy Nexus jää sulavuudessa jälkeen monelle nykyiselle Android-luurille.