ARM brengt gratis toolkit voor Android-ontwikkelaars uit

Chipontwerper ARM heeft een community edition van zijn ontwikkelaarstoolkit DS-5 uitgebracht. De gratis software moet ontwikkelaars van Android-applicaties bijstaan bij het schrijven van native applicaties in C en C++.

De Community Edition van DS-5 is een aanvulling op de bestaande sdk en ndk van Android, zegt ARM. De toolkit laat zich integreren in de Eclipse-ontwikkelomgeving die gebruikt wordt voor applicatieontwikkeling op Android en biedt verschillende tools die moeten helpen bij het optimaliseren van native code. Het gros van de Android-applicaties wordt in Java geschreven, maar het is ook mogelijk om met C en C++ te werken voor meer prestaties.

De gratis versie van de DS-5-toolkit biedt daarvoor onder andere een nieuwe grafische debugger en de Streamline Performance Analyzer, die moet helpen bij het vinden van pijnpunten in de code. De tool is gratis te downloaden voor bedrijven die minder dan 100.000 dollar per jaar omzetten en minder dan 10 medewerkers hebben.

Reacties (28)

[Marthyn1990]

Oh tof dit is wel vet, C/C++ is natuurlijk veel sneller als Java en kan ervoor zorgen dat de wat minder snelle Android phones beter kunnen presteren

[killingdjef]

Dat vind ik erg kort door de bocht. Performance is wellicht een tikkie beter maar laten we wel wezen; als je met de Java library niet uit de voeten komt doe je gewoon iets fundamenteels fout.

Native progammeren voor Android is er om net het laatste beetje kracht uit te persen voor een uitgebreide 3D game. Niet om bijv. een Angry Birds of Sudoku kloon te laten draaien op een G1.

In de regel zou 99% van alle apps veel vlotter en beter draaien als men ook daadwerkelijk nadacht over resource gebruikt. Een handset heeft gewoon niet de luxe van een desktop PC. Helaas zie ik erg vaak dat iemand gewoon een app in elkaar draait en als het werkt dan is het af. "Moet je maar een snellere telefoon kopen!". Nu klopt het dat je gemiddeld genomen om de 2 jaar een flinke boost hebt bij je gebruikers maar ik vind het wel een erg makkelijk excuus en eigelijk ook lui.

Een tip voor Android dev's; gebruik StrictMode om je app meer te streamlinen:
http://developer.android....ndroid/os/StrictMode.html

Daarnaast is native programmeren een stuk lastiger omdat je je VM abstratielaag mist. Denk aan bijvoorbeeld exotische hardware componenten. Tot slot; nog wel het belangrijkste punt om af te wegen, native ontwikkelen kost veel meer tijd. Zoals eerder gezegd, het kantelmoment om native te ontwikkelen zou eigelijk moeten zijn als je een grafisch zeer intensieve app maakt en net die paar extra frames nodig hebt.

[Verwijderd]

"Daarnaast is native programmeren een stuk lastiger omdat je je VM abstratielaag mist. Denk aan bijvoorbeeld exotische hardware componenten."

Aan de andere kant wordt het uitbreiden van de abstractielaag daardoor makkelijker.
Ik denk dat dit de deur opent voor allerlei interessante tweaks.

Verder zou het kunnen dat de eventueel inbegrepen units / libraries zorgen voor de abstractie die gewenst is. Op sommige punten schiet de java vm ook gewoon tekort en voldoet de abstractielaag niet.

Waarschijnlijk is binnen de C++ code nog steeds de java abstractielaag toegankelijk via bijvoorbeeld een directive waarmee je de compiler vertelt dat er een stukje java code volgt. Of juist andersom, dat je vanuit je java code een stukje C++ aanroept. En anders zal dat ongetwijfeld nog komen.

[Reactie gewijzigd door Verwijderd op 25 juli 2024 00:21]

[rboerdijk]

of als je een portable library/game in C hebt en dus met relatief weinig moeite op deze manier naar android kunt switchen

[ooowyeah]

Mee eens, echter ik zie het nut hier toch van in. Maar dan om bijvoorbeeld bestaande applicaties te porten naar Android. Waarom denk je dat de TomTom app zolang op zich laat wachten, die herschrijf je niet even snel in Java

Dat wil je trouwens ook niet want Navcore heeft al genoeg resources nodig "as is".

[pibara]

De performance problemen zitten niet in de taal maar in de virtual machine. Het gaat dan niet om 'het laatste beetje kracht' maar om hinderlijke onderbrekingen in de user experience t.g.v de garbgage collector. Als je GC in kunt ruilen voor RAII dan levert dat om magere hardware specs enorme verbeteringen op in de subjecieve beleving van de snelheid van de applicaties. Ik baal er enorm van dat ik mijn oude symbian telefoon heb vervangen door een SG1 omdat de user experience but is, en Nokia Symbian (waar applicatie ontwikkeling in een kreupele C++ variant moest) heeft doodverklaart en ik dus ook niet meer terug kan.
Ik vind dit echt goed nieuws, voor mij een teken dat Android eindelijk volwassen wordt.

[Finraziel]

Shows what you know... de NDK, native development kit, bestaat al tijden en je kunt dus ook al tijden in C/C++ coden als je dat per se wil. ARM biedt daar nou alleen een uitbreiding op.

[Verwijderd]

Native ontwikkelen hoeft helemaal niet meer tijd te kosten, dat hangt een beetje van je platform af. Mijn werkgever maakt iOS en Android apps, en in veel gevallen ruimen we voor beide even veel tijd in en gaan de projecten gelijk op qua ontwikkeling. En dan is het niet zo dat de Android developers heel slecht zijn of ontzettend langzaam werken.

Wel is duidelijk te zien dat sommige dingen op iOS weer makkelijker te ontwikkelen zijn terwijl andere zaken op Android weer wat eenvoudiger gaan, maar per saldo ontloopt het elkaar niets.

[SuperDre]

maar dan denk ik niet dat je echt puur native bezig bent, aangezien het dan alleen maar zou werken op bepaalde Apple producten of bepaalde android devices..

Maar je hebt wel gelijk, welk platform je ook voor ontwikkeld, je loopt vaak tegen verschillende problemen aan die op het ene platform niet aanwezig zijn en andere weer wel. en natuurlijk zijn er ook altijd wel platformen die weer zo exotisch zijn, en dat zijn weer eigenlijk de leukste platformen voor een developer die graag zo veel mogelijk uit de hardware wil halen(omdat het platform dus toch zo exotisch is)..

[Verwijderd]

Misschien kon mijn post iets duidelijker. Voor iOS gebruiken we dus objective C, wat dus compileert naar native code. Voor iOS is objective C native, net als dat c++ en c dat zijn, maar die sluiten niet prettig aan op Apple's libraries. Voor Android gebruiken we Java, wat dus strikt gesproken niet 'native' is, omdat het compileert naar bytecode.

Volgens de geldende opvattingen zou het ontwikkelen voor een managed omgeving, wat Andoid met z'n VM is, sneller en makkelijker moeten gaan dan voor native omgevingen, maar in de praktijk valt dat dus heel erg mee en ontwikkelen we op het native iOS net zo snel als op het managed Android.

[Dreamvoid]

Objective-C/CLang/etc is ook vrij "high level" en zit tegenwoordig wel vrij dicht tegen 'managed' aan, met alle sandboxing en API-restricties die er bij een App Store goedkeuring bij komen kijken.

[peponline]

Ik dacht dat dit zowiezo al mogelijk was door de NDK van Google zelf?

[jecede]

het (voor mij) grootste nadeel van de NDK is de zeer gebrekkige debugging ondersteuning. In java kun je gewoon een breakpoint zetten en dan door je code steppen en je variabelen zien, en krijg je nette stacktraces. In de ndk heb je dat nauwelijks tot niet (moet je veel voor prutsen). dat maakt dat ik veel langzamer in de ndk werk dan in de sdk. Ik hoop dat deze toolset dit probleem oplost. ga het eens uitproberen, want dat zou echt een enorme verbetering zijn.

[Reactie gewijzigd door jecede op 25 juli 2024 00:21]

[Wolfos]

Klopt, maar die compileert het gewoon naar zo'n zelfde Android executable en voert het ook uit in de Dalvik VM. Als ik het goed begrijp compileert deze toolkit wel naar ARM binary.

[Reactie gewijzigd door Wolfos op 25 juli 2024 00:21]

[Quipeace]

Zover ik weet wordt de gecompileerde native code uit de NKD niet binnen de dalvik VM gedraaid, maar is dat gewoon een native lib.
(waar komt anders de enorme performancewinst vandaan:
http://marakana.com/forums/android/examples/96.html)

[MSalters]

Da's onzin. "Native" code is per definitie code die niet in een VM draait. De NDK compileert dus naar native (ARM) code.

Wat deze toolkit toevoegt is "onder andere een nieuwe grafische debugger en de Streamline Performance Analyzer", en dat zit dus niet in de NDK.

[Djerro123]

Het grote voordeel is ook nog dat het gemakkelijker is om apps te maken voor zowel iOS als Android. Nu is het nog compleet andere koek namelijk.

[Verwijderd]

En dat blijft het ook, met name voor user interface code. Deze is voor beide platforms totaal verschillend. Mobile apps doen uiteindelijk vaak niet zo veel rekenwerk op het device zelf, dus de hoeveelheid gemeenschappelijke code tussen de platforms zal ook wel beperkt zijn en vaak niet opwegen tegen de extra ontwikkel effort om voor beide platforms (iOS en Android) een alternatieve taal te gaan gebruiken (Objective C is immers geen C)

[pibara]

Apps die alleen UI zijn voor een remote backend schrijf je natuurlijk gewoon in javascript, dan zijn ze direct cross-platform. Voor echte apps zou het echter zinnig zijn als je de business logic in een taal zou kunnen schrijven. Jammer genoeg zijn C++ en Objective-C NIET de zelfde taal.

[pibara]

Dacht dat IOS 'Objectice C' was. C++ en Objective-C zijn toch ook echt heel erg andere beestjes.

[Nardon]

Wel beter, native support voor andere programmeertalen dan alleen Java. C++ en zo is toch iets sneller, denk dat vooral gameontwikkelaars hier wel gebruik van willen maken.

[SuperDre]

Nadeel van native support is wel dat je je beperkt tot de devices welke op de specifieke ARM hardware draait, ofwel je spel werkt dan bv niet op alle android 4.0 devices.

Maar echt native supporten (als het goed gebeurd) levert zeker snelheidswinst op, maar ik denk dat de gemiddelde gameontwikkelaar voor mobile devices daar niet echt moeite in gaan stoppen omdat ze dus dan een te beperkte groep kunnen bedienen. Makkelijker is dan dus een multiplatform engine..

Mij zou dit in iedergeval wel meer interesseren, lekker weer eens proberen zoveel mogelijk uit de hardware te krijgen..

[Miauw]

Echt super dit. Ik wilde al een native app maken ! Betekend ook dat ik meer prestaties kan krijgen wanneer ik een emulator maak (n64 FTW)

[Reactie gewijzigd door Miauw op 25 juli 2024 00:21]

[MSalters]

Nee, juist minder.

Als je een Android emulator bouwt, dan port je typisch de Dalvik VM (ipv die te emuleren). Het gevolg is dat alle code die in de Dalvik VM draait ook niet geëmuleerd wordt. Aangenomen dat je een goede port hebt gemaakt, is dat significant sneller.

[Mellow Jack]

en meer je best doen om het werkend te krijgen op al de verschillende telefoons of niet?

[- peter -]

Iedereen doet hier of het iets nieuws is dat er C of C++ kan worden geschreven. Dat kan al heel lang met de NDK. En ja, de code wordt in een apk gestopt en draait binnen de VM, vanwege de app lifecycle, maar wordt wel degelijk als ARM code uitgevoerd. Veel games gebruiken dit, bijv voor Box2d, physics lib.

ARM bied alleen nu meer tools hiervoor.