Low-level iOS, hogyan lehetne gyorsabb?

Tue, 10 May 2011 02:00:00 +0200

A mai Meetup-on tartott előadásommal kapcsolatos fejlesztői infók, kódokkal.

Látványos eredmény megfelelő szálkezeléssel, UIKit frissítés optimalizációval és ARM Assembly-vel érhető el.
A szoftver a király: sokkal több erőforrás takarítható meg jó kóddal, mint mondjuk egy új szuper GHz kétmagos CPU-val.
Ha egyébként rendben van a kód. Például használjunk "tiszta" C-t Objective-C objektumok helyett, ha lehetséges.

Hogyan mérjük a terhelést?

Instruments: elsősorban RAM, szivárgás és Core Animation mérésre. CPU-hoz nem jó, abból eleve sokat eszik, az apró különbségek nem látszanak.
Csak a teljes, rendszerszintű idle idő számít. Mérése kódból megoldható (csatoltam).
A felhasználó a teljes rendszer terhelését érzi, nem az alkalmazásunkét. Könnyű "átvinni" a terhelést a saját kódból az OS-hez (user % -> sys %), de ez nem szabadít fel semmit.

Ökölszabály

25-30% szabad CPU mindig kell, különben "akadozik" az élmény.

NSRunLoop

A main thread NSRunLoop-ja fontos. Többek között ez fogadja az érintés és egyéb felhasználói eseményeket.
Ha nincs 25-30% szabad CPU, akkor későn fut, későn érkeznek az események - akad.
Main thread/main run loop blokkolására ügyelni, események lehető leggyorsabb feldolgozása, külön thread, ha kell.

Szálkezelés

Fontos a megfelelő prioritás, időszelet (mennyi CPU-t használhat adott időtartam alatt) és stratégia (FIFO, RR, OTHER) beállítása.
Nincs rá jó SDK megoldás (NSThread setThreadPriority nem megfelelő), hibrid mach/pthread kód kell. Csatoltam.
Ezzel lehetséges olyan szál futtatása, ami csak a "szabadidőben" fut (idle CPU).

UIKit

Egy UIKit objektum (pl. UIButton) módosítása "költséges", az UIKit a legtöbb esetben blokkol, amíg be nem fejezte a grafikát.
Összegyűjteni a módosításokat (pl. UIButton.highlighted), és végrehajtani később, nem a touch event kezelésekor.
CADisplayLink! Ezzel lehet időzíteni a frissítéseket.
Az iPhone utálja az átlátszóságot, alpha csatornákat, belassul.
A legtöbb objektum átlátszatlan legyen, opaque-ra Interface Builder-ben pipa (igen, végig kell kattintgatni az összeset).
Még így se "halmozzuk egymásra" az objektumokat.
Ha opaque egy objektum, de alpha-s PNG kép van benne, akkor átlátszó lesz így is...
Irtsuk ki az alpha csatornát a felhasznált képeknél, ha lehet.
A szövegek, UILabel módosítása költséges. Saját drawRect metódus és [self.text drawInRect: vagy CGContextShowTextAtPointsokat segít.
A saját drawRect metódusok sokszor gyorsabbak.
Instruments - Core Animation - Flash Updated Regions. Meg fogsz lepődni.

Thumb mód

ARM CPU-k, kétféle futási mód: Thumb és ARM.
Thumb mód: kisebb kód és más utasításkészlet, ezért kisebb memória sávszél igény - gyorsabb futás, régi eszközökön (nem iPhone).
Nem tud lebegőpontos számítást, ilyenkor a fordító átkapcsolja a CPU-t ARM módba, aztán pedig vissza. Ez lassú.
iOS fordító: a Thumb mód alapértelmezett, kapcsoljuk ki. Iterációknál sokat számíthat.

Iterációk optimalizálása - ha az Assembly "túl sok" lenne

Nézzük meg, hogy a compiler milyen kódot gyárt.
Elé és mögé inline asm sorok ( __asm__ volatile ("#innen"); ), majd pedig Build - Show Assembly Code.
Próba: "register" kulcsszó néhány fontos változónál, mennyit változik az Assembly kód. Nem kell annyit töltögetni a memóriából.
A compiler nem mindig jó a regiszterek hatékony elosztásában, csak néhányat használ.
Egyszeres lebegőpontos számokat érdemes használni (sima, 32-bites float), hogy a compiler használja a lebegőpontos egységet.
A memóriahozzáférés sokkal drágább, mint az asztali gépekben. A memcpy is!

Assembly

XCode-ban lehet inline Assembly-t írni.
A C-változatot is meg kell hagyni, mert a Simulatorhoz felesleges külön Assembly verzió. A Simulator x86-os, a régebbi iOS eszközök-ok ARM6-os (VFP), iPhone 3GS-től felfelé pedig ARM7-es (Neon) kódot kérnek.
Universal binary kell (Build Settings - Architectures - Standard (armv7 armv7), illetve -mfloat-abi=softfp -mfpu=neon kapcsolók (Other C Flags).
Az Assembly-be átírás nem triviális, ne "automatikusan" csináljuk. Jó Assembly kód csak "kézműves" munka eredménye lehet.
A regiszterek hatékony kihasználása, a lehető legkevesebb memóriahozzáférés (és lehetőleg blokkban), valamint az utasítások ciklusszámának ismerete sokszoros sebességkülönbséget jelent!
Minden utasítást adott számú ciklus alatt hajt végre a processzor, de képes többet párhuzamosan is!
Használjuk az "egybeépített" segédprocesszort, lebegőpontos számításokra (32 bit float), főleg vektorokhoz, mátrixokhoz. Egy ilyen szorzás pl. 8 ciklus alatt megy végbe, ez idő alatt mást is csinálhat a CPU, ha a következő utasítás nem a szorzás által használt regisztereken dolgozik (párhuzamosítás).

Példa: DJ PLAYER keverő (mixer) kód iPhone 2G-n

C: 18% CPU.
VFP Assembly, a ciklusszámok figyelembe vétele nélkül: 8% CPU.
Végleges, optimalizált változat: 2% CPU.

Kódok

Szálkezelés. Idle CPU mérés.

Red Bull BPM Launch Event

Fri, 04 Mar 2011 01:00:00 +0100

A sajtó meggyőzése fontos, ezért különleges bulikkal próbáljuk lekenyerezni őket. Egy Red Bull BPM Launch Event mindig sokkal érdekesebb, mint egy sajtótájékoztató, vagy bármi, amit általában szoftverek körül szoktak rendezni.

Minden ilyen esemény egy sajtótájékoztatóval kezdődik, ahol egy műsorvezető segítségével rövid bemutatót tartunk (Ralf vagy én), majd pedig az aktuális sztár is megmutat néhány érdekességet, ami igen vicces szokott lenni, mert eddig szinte mindig csak őrültekkel volt dolunk.

Ezután van egy fél/egyórás lazaság a nagyközönség beengedéséig, ez idő alatt próbálunk meg válaszolni a legáltalánosabb kérdésekre. Ez már nem színpados/konferencia-szerű szerencsétlenkedés, hanem lemegyünk és mutogatunk, ilyesmi. Természetesen Red Bull módra minden igen precízen meg van szervezve, kaja/pia pedig bőven akad, messze feljebb a pogi/aprósüti szintnél - az újságírók különösen szeretik a jó ingyenkaját.

Ez a laza rész így nézett ki a hollandoknál:

Végül beengedik a jónépet, akik általában valami nyereményjáték vagy egyéb részvételi izé keretében szereztek jegyet, elkezdődik a show. Általában két helyen van zene (nagyterem, kisterem), plusz ott a demószoba tele iPad-ekkel és iPhone-okkal.

A legnagyobb a legelső Launch Event volt Amszterdam-ban, ott kilenctől éjfélig ki sem tudtam jönni a demószobából, demózni kellett és válaszolni, folyamatos volt a roham. Jöttek újságírók, fejlesztők, hírességek, mindenféle emberek. A sajtó kb. 150 fővel volt jelen, ehhez jött még 1000 fél tízkor. Nem egy átlagos szoftverbemutató...

Kb. éjféltől pedig már csak a bulizás volt téma, például így:

A londoni bulira is el tudtam menni (kalandos 14 óra volt odajutni az óriási 5 centis hó miatt), ott a közönség nemigazán akarta elhinni, hogy Sinden meg én a tánctér közepéről, mászkálás közben játszunk mindenféle kábelek nélkül, érzékelhető késleltetés nélkül. Mókás volt bevonni mindenkit a játékba, direkt megkértük az embereket, hogy nyúlkáljanak az effektekbe. Volt nagy rötyögés meg meglepetés, mikor az iPad megérintése azonnal hatással volt a többezer W-os hangrendszeren keresztül a tömegre.

A berlini és a madridi eseményekről sajnos lemaradtam, nem volt rá időm. A madridi nagyon szép, múzeum-szerű helyen volt, Forma-1-es pilótákkal meg ibizai rezidens DJ-kel. A berliniek pedig nem normálisak, pont karácsony előtt volt a buli, mert ott ez nagy divat.

Madrid slideshow, szép!

Ezúton is köszönöm a szervezőknek, hogy ilyen puccos rendezvényt tesznek a seggünk alá. Nem volt semmi látni, amikor 50 ember rohangál, fúr, farag, telepít, fuvarozza a VIP-ket a reptérről és hasonlók. Mindig egy igen részletes, több oldalas táblázat tartalmazza a teendőket melósokra leosztva, aztán persze mindig csúszunk, úgyhogy be kell szállni pl. a DJ pult építésébe. :-)

Jelenleg a márciusi nagy eseményre készülünk, egészen konkrétan az SXSW konferencia kellős közepén, 15-én Austin-ban USA Launch Event, Felix da Housecat, DJ Manny, meg persze mi. Nem kell ragoznom, hogy ez miért fontos. Április végén pedig irány Párizs, úgy haknizunk, mintha valami falunapos mulatósbanda lennénk.

A galériában: így készül az amszterdami esemény, nekem pedig feltétlenül be kell magolnom az aktuális, feltétlenül elhangzandó kulcsszavakat.

szantog.com - címlap