Tartalom
A legrosszabb ponttal kezdve, a 32 bites Android 5.0 azt mutatja, hogy a Java kód 296% -kal lassabb, mint a C, vagyis négyszer lassabb. Ne felejtsd el ismét, hogy az abszolút sebesség itt nem fontos, hanem inkább a Java kód futtatásához szükséges idő különbsége a C-kódhoz képest ugyanazon az eszközön. A 32 bites Android 4.4 KitKat és a Dalvik JVM egy kicsit gyorsabb, 237% -kal. Amint az Android 6.0-ra ugrik, a Marshmallow dolgai drámaian javulni kezdnek, a 64-bites Android 6.0-val a Java és C közötti különbség a legkisebb.
A második teszt az elsődleges szám teszt, osztással történő próba segítségével. Mint fentebb megjegyeztük, ez a kód 64 biteshosszú egész számok, és ezért a 64 bites processzorokat részesíti előnyben.
A várakozások szerint a legjobb eredmény az 64-bites processzorokon futó Androidról származik. A 64 bites Android 6.0 esetén a sebességkülönbség nagyon kicsi, mindössze 3%. Míg a 64 bites Android 5.0 esetén ez 38%. Ez szemlélteti az ART 5.0 az Android 5.0-on és a optimalizálása az ART által az Android 6.0-ban használt fordító. Mivel az Android 7.0 N még mindig fejlesztői béta, nem mutattam ki az eredményeket, ám általában teljesít, mint az Android 6.0 M, ha nem is jobb. A legrosszabb eredmények az Android 32 bites verziói, és furcsa módon a 32 bites Android 6.0 a csoport legrosszabb eredményeit eredményezi.
A harmadik és az utolsó teszt nehéz matematikai függvényt hajt végre egymillió iterációval. A függvény egész számtani és lebegőpontos számtani.
És itt először van olyan eredmény, amikor a Java valóban gyorsabban fut, mint a C! Ennek két lehetséges magyarázata van, és mindkettő az optimalizáláshoz és az O-hoz kapcsolódikptimizingfordító az ARM-től. Először az Optimizing A fordító optimalizáltabb kódot hozhatott volna létre az AArch64-hez, jobb regisztráció-elosztásával stb., mint az Android Studio C-fordítója. A jobb fordító mindig jobb teljesítményt jelent. Lehet, hogy van egy út is a kódon keresztül, amelyet az OptimizingA fordító által kiszámított optimalizálható, mivel nincs hatással a végső eredményre, de a C fordító ezt nem észlelte. Tudom, hogy ez a fajta optimalizálás volt az egyik legnagyobb fókuszpont az O számáraptimizingfordító az Android 6.0-ban. Mivel a funkció számomra csak egy tiszta találmány, lehet mód arra, hogy optimalizáljuk a kódot, amelyben néhány szakasz kihagyásra kerül, de ezt nem vettem észre.A másik ok az, hogy ennek a funkciónak a meghívása, akár egymilliószor, nem eredményezi a hulladékgyűjtő működését.
A primes-teszthez hasonlóan ez a teszt 64 biteshosszú egész számok, ezért a következő legjobb eredmény a 64 bites Android 5.0. Ezután jön a 32 bites Android 6.0, majd a 32 bites Android 5.0 és végül a 32 bites Android 4.4.
Wrap-up
Összességében a C gyorsabb, mint a Java, azonban a kettő közötti rést drasztikusan csökkentették a 64 bites Android 6.0 Marshmallow kiadásakor. Természetesen a való világban a Java vagy a C használatára vonatkozó döntés nem fekete-fehér. Míg a C-nek vannak bizonyos előnyei, az összes Android felhasználói felület, az összes Android szolgáltatás és az összes Android API felépítését úgy tervezték, hogy Javaból hívják. A C ténylegesen csak akkor használható, ha üres OpenGL vászonra van szükség, és rajzolni szeretne rajta, anélkül, hogy bármilyen Android API-t használni kellene.
Ha azonban az alkalmazásnak nehéz feladatai vannak, akkor ezeket az alkatrészeket át lehet helyezni a C-be, és előfordulhat, hogy a sebesség javul, bár nem annyira, mint valaha látta volna.
