Innehåll
Från och med den sämsta poängen, 32-bitars Android 5.0, visar att Java-koden var 296% långsammare än C, eller med andra ord fyra gånger långsammare. Kom ihåg igen att den absoluta hastigheten inte är viktig här, utan snarare skillnaden i den tid det tar att köra Java-koden jämfört med C-koden på samma enhet. 32-bitars Android 4.4 KitKat med sin Dalvik JVM är lite snabbare på 237%. När hoppet har gjorts till Android 6.0 Marshmallow börjar saker och ting förbättras dramatiskt, med 64-bitars Android 6.0 som ger den minsta skillnaden mellan Java och C.
Det andra testet är primtesttestet, med hjälp av prov per division. Som nämnts ovan använder denna kod 64-bitarslång heltal och kommer därför att gynna 64-bitars processorer.
Som förväntat kommer de bästa resultaten från Android som körs på 64-bitars processorer. För 64-bitars Android 6.0 är hastighetsskillnaden mycket liten, bara 3%. För 64-bitars Android 5.0 är det 38%. Detta visar förbättringarna mellan ART på Android 5.0 och Optimerande kompilator som används av ART i Android 6.0. Eftersom Android 7.0 N fortfarande är en utvecklingsbeta har jag inte visat resultaten, men det fungerar generellt såväl som Android 6.0 M, om inte bättre. De sämre resultaten är för 32-bitarsversionerna av Android och konstigt 32-bitars Android 6.0 ger gruppens värsta resultat.
Det tredje och sista testet utför en tung matematisk funktion för en miljon iterationer. Funktionen gör både heltals aritmetik och flyttalsaritmetik.
Och här för första gången har vi ett resultat där Java faktiskt springer snabbare än C! Det finns två möjliga förklaringar till detta och båda har att göra med optimering och Optimizingkompilator från ARM. Först Optimizing kompilator kunde ha producerat mer optimal kod för AArch64, med bättre registerallokering etc., än C-kompilatorn i Android Studio. En bättre kompilator betyder alltid bättre prestanda. Det kan också finnas en väg genom koden som Optimizingkompilatorn har beräknat kan optimeras bort eftersom den inte har någon påverkan på det slutliga resultatet, men C-kompilatorn har inte upptäckt denna optimering. Jag vet att denna typ av optimering var ett av de stora fokusen för Optimizingkompilator i Android 6.0. Eftersom funktionen bara är en ren uppfinning från min sida kan det finnas ett sätt att optimera koden som utelämnar vissa avsnitt, men jag har inte upptäckt den.Det andra skälet är att om du kallar denna funktion, till och med en miljon gånger, får inte skräpfångaren att köra.
Liksom med primtestet använder detta test 64-bitarslång heltal, varför nästa bästa poäng kommer från 64-bitars Android 5.0. Sedan kommer 32-bitars Android 6.0, följt av 32-bitars Android 5.0 och slutligen 32-bitars Android 4.4.
Sammanfatta
Totalt sett är C snabbare än Java, men klyftan mellan de två har minskat drastiskt med utgivningen av 64-bitars Android 6.0 Marshmallow. Naturligtvis i den verkliga världen är beslutet att använda Java eller C inte svartvitt. Även om C har några fördelar är alla Android-gränssnitt, alla Android-tjänster och alla Android-API: er utformade för att ringa från Java. C kan egentligen bara användas när du vill ha en tom OpenGL-duk och du vill rita på den duken utan att använda några Android-API: er.
Men om din app har lite tunga lyft att göra, kan dessa delar överföras till C och du kan se en hastighetsförbättring, dock inte så mycket som du en gång kunde ha sett.
