Skillnad mellan att optimera android och iOS??

Permalänk
Medlem

Skillnad mellan att optimera android och iOS??

Hej!
Skulle behöva hjälp att kunna förklara vad det är för skillnad att optimera i android och iOS! Nån som kan hjälpa mig?

Permalänk
Medlem

Beror på vad för optimering du ska göra?

Optimering är alltid optimering

Visa signatur

Corsair 16GB (4x4096MB) CL9 1600Mhz | Asus P8Z77-V PRO |
Samsung SSD Basic 830-Series 256GB | Intel Core i7 3770K 3,5Ghz |
Asus Xonar Essence STX | Noctua NH-U9B SE2 | Antec Performance One P280 | Corsair HX 850W 80+ Gold Modulär | MSI GTX 770

Permalänk
Medlem

Nja tänkte t.ex om optimeringen skiljer sig mellan de olika enheterna? Finns det t.ex inbyggda funktioner i i iOS eller Android som gör att man behöver optimera mindre?

Permalänk

Tror du får förklara vad det är som ska optimeras. Appar? Systemet?

Visa signatur

Citera om du vill få svar!

Permalänk
Medlem

eftersom du kan göra/ställa till det i Andriod så är nog det mer optimerings vänlig emot iOS sen om det gehövs vette tusan..Tycker min Andriod lur rullar på bra utan optimering

Sen tror jag faktiskt inte iOS behövs optimeras då det är en väldigt bra och optimerat OS för mobil från scratch.

Visa signatur

╔ Corsair 32GB DDR4 CL15 3000Mhz VENGEANCE RGB ■
╠ ASUS-ROG-MAXIMUS-X-HERO ■ ASUS-ROG-STRIX-RTX2070-OC ■ i7 8700K
╠ DeepCool Captain 280EX RGB ■ 2x Samsung 970 EVO 500GB■
╠ Deepcool NEW ARK 90 Electro Limited Edition NR58 ■ XFX PRO1000W Limited Black Edition
╚ Samsung SE790C 34" Ultrawide 3440x1440@75Hz

Permalänk
Medlem

Det finns väldigt många android mobiler med olika hårdvara i, så det är svårare att optimera mot hårdvaran än med Ios där det finns färre hårdvarukonfigurationer.

Visa signatur

Speldator: i5 4670k stock | 8GB ram | Asus Z87-plus | Xonar Essence STX | SSD: Intel g2 , Samsung 830 256gb | R9 290 Tri-x | Define R4| Win 8 | Noctua nh-u12p | Qpad Mk-50
marinlik.wordpress.com/ Min blogg för nedbrytning av spel och diverse andra artiklar om NFL
500px.com/niclasbrundell

Permalänk
Medlem

Det beror ju helt på vad för optimering som menas. Om man själv gör ett program så gäller det ju att välja bra algoritmer beroende på vad man ska lösa för problem eller vad programmet ska göra. Gör man en egen sorteringsalgoritm där man jämför varje värde onödigt många gånger så är det säkert något man kan optimera och det har ju inget att göra med om det är Android eller iOS.

Permalänk
Medlem
Skrivet av progr:

Nja tänkte t.ex om optimeringen skiljer sig mellan de olika enheterna? Finns det t.ex inbyggda funktioner i i iOS eller Android som gör att man behöver optimera mindre?

Optimera vad?

Visa signatur

ηλί, ηλί, λαμά σαβαχθανί!?

Permalänk
Medlem

Förlåt.. Var lite otydlig. När man programmerar en app, i xCode eller Eclipse. Vad kan det då vara för skillnad mellan att optimera koden i de olika enheterna?

Permalänk
Medlem

frågan är fortfarande otydlig tycker jag

optimering i Eclipse eller annan utvecklingsmiljö är densamma, vissa har inbyggda linters eller som plugin som kan hjälpa dig att i vissa fall optimera

generell optimering handlar ju mer om att utnyttja resurser så liten tid som möjligt etc, coarse location finns(eller fanns förr iaf) i android om du inte är intresserad av nogrannare position, men jag vet inte om det är mer optimerat, sånt får man nästan kolla upp i specifika fall.

Permalänk
Medlem

Jag skulle säga att optimering handlar om hur bra du är på logiskt tänkande och hur bra du kan systemet du utvecklar för

Permalänk
Medlem
Skrivet av progr:

Förlåt.. Var lite otydlig. När man programmerar en app, i xCode eller Eclipse. Vad kan det då vara för skillnad mellan att optimera koden i de olika enheterna?

Skrivet av gothxx:

frågan är fortfarande otydlig tycker jag

optimering i Eclipse eller annan utvecklingsmiljö är densamma, vissa har inbyggda linters eller som plugin som kan hjälpa dig att i vissa fall optimera

generell optimering handlar ju mer om att utnyttja resurser så liten tid som möjligt etc, coarse location finns(eller fanns förr iaf) i android om du inte är intresserad av nogrannare position, men jag vet inte om det är mer optimerat, sånt får man nästan kolla upp i specifika fall.

Kort och gott: optimering av kod har egentligen ingenting med ett IDE att göra (det kan möjligtvis vara lättare att navigera runt i ett projekt med ett bra utvecklingsverktyg, vilket i sin tur kan resultera i bättre kod).

Visa signatur

Kom-pa-TI-bilitet

Permalänk
Datavetare

Några prestanda relaterade saker jag märkt med Android på den minimala tid jag än lyckats lägga på min "Dalvik benchmark" som jag håller på att skriva är

  • Det är dyrt att skapa många kortlivade objekt, mycket dyrare än vad det blir i samma program körandes på en "vanlig" JVM. Det skiljer en till två tiopotenser mellan OpenJDK7 och Dalvik på Android 4.0. Detta är inte så svårt att förklara, Dalvik är optimerad till att vara väldigt aggresiv med sin skräpsammling då mobila enheter typiskt har ganska begränsat med RAM jämfört med de server-maskiner som typiskt kör JVM:erm med "hotspot" optimering.

  • Ren aritmetik (beräkningar) är däremot i princip lika snabbt under Dalvik som under OpenJDK7. Och OpenJDK är snabb, helt i nivå med kod skrivet i C/C++.

  • Hopp orsakade av jämförelser (if-satser) verkar också vara effektivt, d.v.s i nivå med OpenJDK

  • Primitiver för lås och atomära variabler är inte fullt lika effektiva under Dalvik som under OpenJDK7, men helst ska man undvika alla sådana operation i alla fall om man vill att programmet ska skala väl över flera CPU-kärnor

Det jag har kvar att skriva är tester för kostnad av funktionsanrop, både rekursiva och icke-rekursiva anrop. Här kan jag tänka mig att en "hotspot" JVM har en del fördel, men vem vet...

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem

[QUOTE=Yoshman;13370645]Några prestanda relaterade saker jag märkt med Android på den minimala tid jag än lyckats lägga på min "Dalvik benchmark" som jag håller på att skriva är

  • Det är dyrt att skapa många kortlivade objekt, mycket dyrare än vad det blir i samma program körandes på en "vanlig" JVM. Det skiljer en till två tiopotenser mellan OpenJDK7 och Dalvik på Android 4.0. Detta är inte så svårt att förklara, Dalvik är optimerad till att vara väldigt aggresiv med sin skräpsammling då mobila enheter typiskt har ganska begränsat med RAM jämfört med de server-maskiner som typiskt kör JVM:erm med "hotspot" optimering.

  • Ren aritmetik (beräkningar) är däremot i princip lika snabbt under Dalvik som under OpenJDK7. Och OpenJDK är snabb, helt i nivå med kod skrivet i C/C++.

  • Hopp orsakade av jämförelser (if-satser) verkar också vara effektivt, d.v.s i nivå med OpenJDK

  • Primitiver för lås och atomära variabler är inte fullt lika effektiva under Dalvik som under OpenJDK7, men helst ska man undvika alla sådana operation i alla fall om man vill att programmet ska skala väl över flera CPU-kärnor

Det jag har kvar att skriva är tester för kostnad av funktionsanrop, både rekursiva och icke-rekursiva anrop. Här kan jag tänka mig att en "hotspot" JVM har en del fördel, men vem vet...[/QUOTE]

Angående funktionsanrop. Detta är saxat från "Apress - Beginning Android Development"

"Method calls have a larger associated cost in Dalvik than in other VMs. Use static methods if you can, as those perform best. Static methods are generally regarded as evil, much like static variables, as they promote bad design. So try to keep your design as clean as possible. You should maybe avoid getters and setters as well. Direct field access is about three times faster than method invocations without the JIT, and about seven times faster with the JIT. Again, think of your design before removing all your getters and setters, though."

Visa signatur

ηλί, ηλί, λαμά σαβαχθανί!?

Permalänk
Medlem

Tack för alla svar!

Permalänk
Datavetare
Skrivet av Leedow:

Angående funktionsanrop. Detta är saxat från "Apress - Beginning Android Development"

"Method calls have a larger associated cost in Dalvik than in other VMs. Use static methods if you can, as those perform best. Static methods are generally regarded as evil, much like static variables, as they promote bad design. So try to keep your design as clean as possible. You should maybe avoid getters and setters as well. Direct field access is about three times faster than method invocations without the JIT, and about seven times faster with the JIT. Again, think of your design before removing all your getters and setters, though."

Kanske inte så förvånande om man tänker lite på det. Dels kan en hotspot JVM optimera bort vissa funktionsanrop alt. inse att det är alltid underliggande typ som anropas och man kan ersätta det indirekta anropet via funktionspekaren associerad med metoden för underliggande typ med ett direkt anrop (vilket är exakt vad man får vid hopp till en statisk metod).

En annan anledning är nog att Dalvik, till skillnad från "vanliga" Java och även CLR (virtuella maskinen i .Net), är en registerbaserad JVM medan de andra är stackbaserade. Att göra funktionsanrop i en registerbaserad VM kräver att man sparar "callee save" register och den anropade funktionen måste spara "caller save" register, något som kostar extra instruktioner och därmed tid. I en stackbaserad JVM finns inte det problemet.

Dalvik kör säkert med registerbaserad VM då det bättre återspeglar ARM arkitekturen (och således kräver en mindre avancerad JIT-kompilator, JIT kan dra en del resurser), är egentligen bara x86 som kan hantera en stackbaserad JVM riktigt effektivt (både Intel sedan Pentium M och AMD sedan i alla fall Phenom II har dedikerat kiselyta explicit för vissa instruktioner som jobbar mot stacken).

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Datavetare
Skrivet av Leedow:

Angående funktionsanrop. Detta är saxat från "Apress - Beginning Android Development"

"Method calls have a larger associated cost in Dalvik than in other VMs. Use static methods if you can, as those perform best. Static methods are generally regarded as evil, much like static variables, as they promote bad design. So try to keep your design as clean as possible. You should maybe avoid getters and setters as well. Direct field access is about three times faster than method invocations without the JIT, and about seven times faster with the JIT. Again, think of your design before removing all your getters and setters, though."

Har testat detta i min benchmark och föga oväntat ser jag precis det man nämner i "Beginning Android Development". I det test-case jag skapade för min benchmark tar det en faktor 16 så lång tid att köra programmet i Dalvik jämfört med OpenJDK7. Det kvittar om metoden är static eller ej i Dalvik, skillnaden var faktiskt lite större för static metoder (en faktor 17 mot OpenJDK7).

Så det man ska undvika i Dalvik är små korta metoder samt skapa väldigt många kortlivade objekt, för det är väldigt dyrt jämfört med en "vanlig" JVM.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem
Skrivet av Yoshman:

Har testat detta i min benchmark och föga oväntat ser jag precis det man nämner i "Beginning Android Development". I det test-case jag skapade för min benchmark tar det en faktor 16 så lång tid att köra programmet i Dalvik jämfört med OpenJDK7. Det kvittar om metoden är static eller ej i Dalvik, skillnaden var faktiskt lite större för static metoder (en faktor 17 mot OpenJDK7).

Så det man ska undvika i Dalvik är små korta metoder samt skapa väldigt många kortlivade objekt, för det är väldigt dyrt jämfört med en "vanlig" JVM.

Det var riktigt tråkigt det. Tror du det skulle vara möjligt att optimera Dalvik så den hanterar "ordentlig Java" bättre? ODEX-verktyg borde kunna göra vissa optimeringar tycker jag.

Visa signatur

Kom-pa-TI-bilitet

Permalänk
Datavetare
Skrivet av Teknocide:

Det var riktigt tråkigt det. Tror du det skulle vara möjligt att optimera Dalvik så den hanterar "ordentlig Java" bättre? ODEX-verktyg borde kunna göra vissa optimeringar tycker jag.

Som jag skrev ovan, Dalvik har andra designkriterier jämfört med "vanliga" Java. Davik är optimerad för interaktiva applikationer som ska köras på relativt svaga inbyggda system (telefoner och pekplattor). "Vanliga" Java är numera väldigt fokuserat på back-end system som typiskt är väldigt CPU-starka system med massor med RAM.

Den andra stora skillnaden är att "vanliga" Java-program typiskt kör väldigt länge så "hotspot" optimeringar är väl värda kostnaden medan Android program måste vara interaktiva direkt och körs typiskt ganska kort tid (CPU-tidsmässigt).

Men jämför man Android och iOS så tycker i alla fall jag att Java med de begränsningar/egenskaper som man får med Dalvik ändå är en rätt mycket trevligare miljö jämfört med ObjC/Cocoa. Är problemet riktigt CPU-begränsat så kan man alltid ta till NDK på Android och använda C eller C++.

Ska kanske tillägga att jag kör jämfört Dalvik/OpenJDK på Atom som nog hanterar den stackbaserade design som "vanlig" Java använder lite mer effektivt än vad en ARM CPU skulle göra. Har kört Dalvik koden även på ARM, relativt prestanda i andra benchmarks så är Dalvik något mer effektivt på ARM i anrops-testet (kanske inte så oväntat då bytekoden i Dalvik verkar rätt ARM centrerad), men det handlar ändå om 15-16 gånger längre körtid på en 1GHz Cortex A9 på Dalvik jämfört med vad Atom på 1.6GHz får på OpenJDK7. I många andra benchmarks så är Atom system definitivt snabbare även i Dalvik men i detta test är det jämt skägg tidsmässigt.

Det andra testet som Dalvik var riktigt uselt jämfört med OpenJDK, skapandet av många temporära objekt, så var Dalvik/Atom-systemet mer än dubbelt så snabb som Dalvik/ARM systemet. Men båda var typ två tiopotenser långsammare än OpenJDK7/Atom.

Kommer göra hela programmet och all källkod för min benchmark tillgänglig här på SweC när den är tillräckligt klar. Är mest ett projekt jag jobbar med nu för att lära mig grunderna i Android-programmering, men var också intresserad att se hur pass bra/dåligt Dalvik är för x86 jämfört med ARM.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer