Varför MeeGo är kvickare än Android

Intressant verkligen. Tänkte jag skulle kasta min LG Optimus X2 i skön ändå för det är skräp av något. Nokia har iaf genom åren haft kvalité lurar så varför i H*vete bytte jag..

Det verkar vara en del förvirring och missförstånd på och hur Android fungerar till skillnad från Meego.

1. Kodar man C/C++-applikationer i Android genom NDK så körs de native precis som på Meego (båda använder gcc och glibc). Den enda skillnaden är att binären paketeras i en apk på Android, precis som med dalvik-bytekoden; samt att man måste ha en java-main som kickar igång ens riktiga binär.

2. Ja, Java är för det mesta långsammare än C++ (även om det är väldigt lätt att skriva kass C++kod). Däremot så tror jag de flesta syftar på flytet i gränssnittet när man jämför Android och Meego. Däri ligger skillnaden att Android (Gingerbread 2.3 eller äldre) inte hade hårdvaruaccelererad 2D-grafik (vilket nu Android 3/4 har). Vissa program, som t.ex. Opera Mobile, renderar 2D-grafiken "manuellt" (ej nativewidgets, etc) genom OpenGL ES samt att de beräkningsintesiva delarna är skrivna i C++ (t.ex. XML-parsning och DOM-generering). De är minst lika snabba som motsvarande applikationer på Nokia N9/N950.

3. Applikationer utvecklade med Android NDK lider av samma problem som Qt-applikationer i C++: Nämligen att binärerna endast fungerar på en processorarkitektur. Utvecklaren som arbetar med C++-koden måste då kompilera och paketera sin applikation för flertalet processorarkitekturer. Prestandavinsten i att skriva något i C++ jämfört med Java är svårmotiverad om det inte är tyngre applikationer man sitter och utvecklar. Annars kan man likväl hålla sig till dalvikbytekod som fungerar på alla processorarkitekturer (som har en fungerande dalvikmotor).

4. En applikation skriven för t.ex. Meego går inte automatiskt att få att rulla i t.ex. Windows, men det är helt klart enklare att använda existerande kodbas för att göra en native-applikation för Windows/OSX/Linux i efterhand. Gränssnitten, storleken på skärmarna, etc, skiljer sig så markant mellan mobila enheter och en fullvärdig dator. API:erna är heller inte helt identiska mellan Qt och Qt Mobility.

Jag har rootad telefon nu men det är ju så nedrans ostabila roms där ute för just LGn så det blir att köpa ny telefon framöver så kan jag ha denna skräp telefonen som handhållen spel o nöjjes maskin typ som ett "psp" fast i fail format.

Nej, C/C++ koden kompileras till Dalvik bytekod och körs på en VM, det körs alltså inte som native kod.

"If you write native code, your applications are still packaged into an .apk file and they still run inside of a virtual machine on the device. The fundamental Android application model does not change."

http://developer.android.com/sdk/ndk/index.html

Nej, den kompileras inte till bytekod. Det står t.o.m. i en av länkarna som finns på sidan till det du länkade in:

"The NDK provides:

* A set of tools and build files used to generate native code libraries from C and C++ sources

...

The latest release of the NDK supports these ARM instruction sets:
ARMv5TE (including Thumb-1 instructions)
ARMv7-A (including Thumb-2 and VFPv3-D16 instructions, with optional support for NEON/VFPv3-D32 instructions)
x86 instructions (see CPU-ARCH-ABIS.HTML for more information)"

Hade det varit bytekod så hade NDK:t inte haft information om vilka instruktionsuppsättningar som stöds.

Däremot är dalvik helt ansvarig för att köra igång binärerna. De packas fortfarande i apk-filer och behöver en java-main som kan dra igång binären.

Är du förresten fortfarande tveksam så är det bara att skapa en NDK-applikation, extrahera binären och sedan köra följande i en linux-terminal:

$ readelf -h namnetpåminbinär