Dat RAM neemt afstand van andere dingen, zoals het aantal van de achtergrond processen die kunnen worden draaiende gehouden, mogelijk te vertragen dingen als app switching. • Door de overhead van OpenGL, men kan heel goed niet willen gebruiken voor het tekenen. Bijvoorbeeld een deel van het werk dat we doen om Android 4.0 te draaien goed op de Nexus S is betrokken uitschakelen van hardware versnelde tekening in delen van de UI, zodat we niet 8MB RAM-geheugen te verliezen in het systeem proces, een ander 8MB in de telefoon proces, een 8MB in het systeem UI proces, enz.
Geloof me, u zult niet in de gaten - er is gewoon geen voordeel op dat apparaat in het gebruik van OpenGL om iets als de statusbalk te trekken, zelfs met mooie animaties gaande daar. • Hardware versnelde tekening is niet een magische zilveren kogel boter gladde UI. Er zijn veel verschillende inspanningen die zijn gaande in de richting van deze, zoals een betere planning van de voorgrond vs. achtergrond threads in 1.6, het herschrijven van de input-systeem in 2.3, de strikte modus, gelijktijdige garbage collection, laders, etc.
Als je wilt bereiken 60fps , moet je 20 milliseconden om elk frame te behandelen. Dit is niet veel tijd. Gewoon aanraken van de flash-opslag-systeem in de thread waarop de UI kan in sommige gevallen te introduceren een vertraging die je steekt van die timing venster, vooral als u het schrijven naar opslag. • Een recent voorbeeld van het soort interessante dingen die invloed UI gladheid: wij hebben gemerkt dat ICS op Nexus S was eigenlijk minder soepel bij het scrollen door lijsten dan het was op Gingerbread.
Het bleek dat de reden voor dit te wijten was aan subtiele veranderingen in de timing, zodat soms ICS als de app is het ophalen aanraakgebeurtenissen en tekenen op het scherm, zou het gaan om de volgende evenement iets voordat het klaar was te krijgen, waardoor het zichtbaar missen van een frame terwijl het volgen van de vinger ook al was het tekenen op het scherm op een stevige 60fps. • Als mensen in het verl