Indhold
Start med den dårligste score, 32-bit Android 5.0, viser, at Java-koden løb 296% langsommere end C, eller med andre ord 4 gange langsommere. Husk igen, at den absolutte hastighed ikke er vigtig her, men snarere forskellen i den tid, det tager at køre Java-koden sammenlignet med C-koden, på den samme enhed. 32-bit Android 4.4 KitKat med sin Dalvik JVM er lidt hurtigere på 237%. Når springet er gjort til Android 6.0 Marshmallow, begynder tingene at forbedre sig dramatisk, idet 64-bit Android 6.0 giver den mindste forskel mellem Java og C.
Den anden test er primtallstesten ved hjælp af prøve efter opdeling. Som bemærket ovenfor bruger denne kode 64-bitlang heltal og vil derfor favorisere 64-bit processorer.
Som forventet kommer de bedste resultater fra Android, der kører på 64-bit-processorer. For 64-bit Android 6.0 er hastighedsforskellen meget lille, kun 3%. Mens det til 64-bit Android 5.0 er 38%. Dette demonstrerer forbedringerne mellem ART på Android 5.0 og Optimering kompilator brugt af ART i Android 6.0. Da Android 7.0 N stadig er en udviklingsbeta, har jeg ikke vist resultaterne, men det fungerer generelt såvel som Android 6.0 M, hvis ikke bedre. De værre resultater er for 32-bit versionerne af Android, og underligt 32-bit Android 6.0 giver gruppens dårligste resultater.
Den tredje og sidste test udfører en tung matematisk funktion for en million iterationer. Funktionen udgør heltalearitmetik såvel som flydepunktaritmetik.
Og her for første gang har vi et resultat, hvor Java faktisk kører hurtigere end C! Der er to mulige forklaringer på dette, og begge har at gøre med optimering og Optimizingkompilator fra ARM. For det første Optimizing compiler kunne have produceret mere optimal kode til AArch64 med bedre registertildeling osv. end C-kompilatoren i Android Studio. En bedre kompilator betyder altid bedre ydelse. Der kan også være en sti gennem den kode, som Optimizingkompilatoren har beregnet kan optimeres væk, fordi den ikke har nogen indflydelse på det endelige resultat, men C-kompilatoren har ikke set denne optimering. Jeg ved, at denne form for optimering var et af de store fokus for Optimizingkompilator i Android 6.0. Da funktionen kun er en ren opfindelse fra min side, kan der være en måde at optimere koden, der udelader nogle sektioner, men jeg har ikke set den.Den anden grund er, at det at kalde denne funktion, selv ikke en million gange, ikke får affaldssamleren til at køre.
Som med primes-testen bruger denne test 64-bitlang heltal, hvorfor den næste bedste score kommer fra 64-bit Android 5.0. Derefter kommer 32-bit Android 6.0, efterfulgt af 32-bit Android 5.0 og til sidst 32-bit Android 4.4.
Wrap-up
Generelt er C hurtigere end Java, men kløften mellem de to er drastisk reduceret med frigivelsen af 64-bit Android 6.0 Marshmallow. I den virkelige verden er beslutningen om at bruge Java eller C naturligvis ikke sort / hvid. Selvom C har nogle fordele, er alle Android UI, alle Android-tjenester og alle Android API'er designet til at blive opkaldt fra Java. C kan virkelig kun bruges, når du vil have et tomt OpenGL-lærred, og du vil trække på det lærred uden at bruge Android API'er.
Men hvis din app har nogle tunge løft at gøre, så kunne disse dele blive sendt til C, og du kan se en forbedring af hastigheden, dog ikke så meget, som du engang kunne have set.
