Sisältö
Alkaen pahimmasta pisteestä, 32-bittinen Android 5.0, osoittaa, että Java-koodi juoksi 296% hitaammin kuin C, toisin sanoen 4 kertaa hitaammin. Muista taas, että absoluuttinen nopeus ei ole tässä tärkeä, vaan pikemminkin ero Java-koodin suorittamiseen C-koodiin verrattuna samassa laitteessa. 32-bittinen Android 4.4 KitKat ja sen Dalvik JVM ovat hiukan nopeammat 237%. Kun hyppy on tehty Android 6.0 -käyttöjärjestelmään, Marshmallow-asiat alkavat parantua dramaattisesti, 64-bittisellä Android 6.0: lla on pienin ero Java: n ja C: n välillä.
Toinen testi on alkuluku, käyttäen kokeilujakoa. Kuten edellä todettiin, tämä koodi käyttää 64-bittistäpitkä kokonaislukuja ja suosii siksi 64-bittisiä prosessoreita.
Odotetusti parhaat tulokset tulevat Androidin käyttäessä 64-bittisissä prosessoreissa. 64-bittisessä Android 6.0: ssa nopeusero on hyvin pieni, vain 3%. 64-bittisessä Android 5.0: ssa se on 38%. Tämä osoittaa parannukset Android 5.0: n ja ART: n välillä optimoiminen kääntäjä, jota ART on käyttänyt Android 6.0: ssa. Koska Android 7.0 N on edelleen kehittämisbeeta, en ole näyttänyt tuloksia, mutta se yleensä toimii yhtä hyvin kuin Android 6.0 M, ellei parempi. Huonommat tulokset ovat Androidin 32-bittisillä versioilla ja omituisella 32-bittisellä Android 6.0 tuottaa ryhmän huonoimmat tulokset.
Kolmas ja viimeinen testi suorittaa raskaan matemaattisen funktion miljoonalle iteraatiolle. Toiminto suorittaa kokonaislukuaritmeettista sekä liukulukuaritmeettista.
Ja täällä meillä on ensimmäistä kertaa tulos, jossa Java todella toimii nopeammin kuin C! Tälle on kaksi mahdollista selitystä, ja molemmat liittyvät optimointiin ja O: hanptimizingkääntäjä ARM: lta. Ensinnäkin Optimizing kääntäjä olisi voinut tuottaa AArch64: lle optimaalisemman koodin, paremmalla rekisterin allokoinnilla jne. kuin Android Studion C-kääntäjä. Parempi kääntäjä tarkoittaa aina parempaa suorituskykyä. Lisäksi voi olla polku koodin läpi, jonka Optimizingkääntäjä on laskenut voidaan optimoida pois, koska sillä ei ole vaikutusta lopputulokseen, mutta C-kääntäjä ei ole huomannut tätä optimointia. Tiedän, että tällainen optimointi oli yksi isoista painopistealueista O: lleptimizingkääntäjä Android 6.0: ssa. Koska toiminto on omalta osaltaan vain puhdas keksintö, voisi olla tapa optimoida koodi, joka jättää joitain osia, mutta en ole huomannut sitä.Toinen syy on, että tämän toiminnon kutsuminen, jopa miljoona kertaa, ei aiheuta roskien kerääjää.
Kuten primes-testi, tämä testi käyttää 64-bittistäpitkä kokonaislukuja, minkä vuoksi seuraavaksi paras pistemäärä tulee 64-bittisestä Android 5.0: sta. Sitten tulee 32-bittinen Android 6.0, jota seuraa 32-bittinen Android 5.0 ja lopulta 32-bittinen Android 4.4.
Paketoida
Kaiken kaikkiaan C on Javaa nopeampi, mutta ero näiden kahden välillä on vähentynyt huomattavasti julkaisemalla 64-bittinen Android 6.0 Marshmallow. Tietenkin todellisessa maailmassa päätös käyttää Java tai C ei ole mustavalkoinen. Vaikka C: llä on joitain etuja, kaikki Android-käyttöliittymä, kaikki Android-palvelut ja kaikki Android-sovellusliittymät on suunniteltu kutsuttaviksi Java-palvelusta. C: tä voidaan todella käyttää vain, kun haluat tyhjän OpenGL-kankaan ja haluat piirtää tuon kankaan käyttämättä Android-sovellusliittymiä.
Jos sovelluksessasi on kuitenkin raskasta nostamista, kyseiset osat voidaan siirtää C: hen ja saatat nähdä nopeuden paranemisen, mutta ei niin paljon kuin olet aiemmin voinut nähdä.
