Citat:
Ursprungligen inskrivet av
peterholm1
Jag har aldrig spelat på Android men det måste vara väldigt svårt att utvecka spel till den plattformen eftersom du inte vet vilken prestanda användaren sitter med? Någon har S3 och någon har ZTE Blade...
Inga problem.
Det är just det som gör Googles system så genialist, det finns inga problem med fragmentering, trots att folk sitter med helt olika enheter. Det är verklig bedrift.
I korthet funkar det så här:
* Om du vill göra ett Angry-Birdsliknande spel så använder du OpenGL 1.1 och kompilerar för android 2.1. Då kommer spelet att funka bra till alla androidtelefoner (om man inte sitter på nån uråldrig android 1.6 eller så. Det går naturligtvis att kompilera för allra första versionen av android om man vill det också.)
* Om du vill göra ett superavancerat grafikspel som bara funkar på värstingmodellerna så kan du istället sätta begränsningar på vilka som kan se appen i android market och installera den. T.ex. endast gingerbread och uppåt, kräver OpenGl ES 2.0, endast modeller med en viss kapacitet på grafikkretsen, endast vissa namngivna modeller etc.
* Som ett mellanläge så kan du välja att stödja fler telefoner men se till att de högupplösta texturerna endast läses upp man har minst 1GB RAM, se till att detaljnivån på trådsklettsmodellerna ställs ned om man har under 750 MB RAM etc.
* Om man vill stödja "alla" enheter på android som apputvecklare så måste man tillhandahålla tre olika texturer, ibland även olika layouts:
1) Låg PPI-texturer
2) Mellanhög PPI-texturer
3) Högupplöst PPI-texturer.
Som jämförelse så måste man som iOS-utvecklare stödja fyra olika texturer om man vill klara "alla" iOS-enheter:
* iPhone, låg upplösning (3gs t.ex)
* iPhone, hög upplösning (Ip4 etc.)
* iPad, låg upplösning (Ipad1 & 2)
* iPad, hög upplösning (Den nye Ipad)
Det är alltså i många fall enklare för en androidutvecklare.
Det är bara iOS-användare som har problem med fragmenteringen på android-sidan.
En annan sak som är smart på androidsidan är att med den här "generella" metoden med olika PPI-enheter som antroducerades med ICS så görs det inte längre någon egentlig skillnad mellan smartphone-appar och surfplatte-appar. Man behöver alltså inte utveckla separata appar för surfplattor (även om det alternativet fortfarande finns kvar). På Ios-sidan så måste man göra separata appar för Ipad, pga annan skärmupplösning. Det gör alltså ingenting att det inte finns så många appar särskilt utvecklade för surfplattor på android eftersom de vanliga apparna funkar bra.
Slutligen så är androids upplägg med Java, Bytekod och JIT väldigt smart. Gång på gång har detta upplägg visat sig kunna optimeras väldigt hårt, så idag finns det inte längre några prestandaförluster på att köra med ett "mellanlager" istället för att direktkompilera för en viss processor. Dagens processorer har ganska långa pipelines, och en modell med ett mellanlager är rätt bra på att ta på vara på det möjligheterna som den långa pipelinen ger. Det finns exempel på applikationer / problem där javas approach är mer effektiv än direktkompilering med ett c-liknande språk. Man kan jämföra med persondatorerna där C++/CLI blir en allt mer vanlig utvecklingsmiljö.