Conţinut
Începând cu cel mai slab scor, Android 5.0 pe 32 de biți, arată că codul Java a rulat cu 296% mai lent decât C, sau cu alte cuvinte de 4 ori mai lent. Din nou, amintiți-vă că viteza absolută nu este importantă aici, ci mai degrabă diferența de timp necesară pentru a rula codul Java în comparație cu codul C, de pe același dispozitiv. Android 4.4 KitKat pe 32 de biți cu JVM Dalvik este puțin mai rapid la 237%. Odată ce saltul pe Android 6.0 Marshmallow lucrurile încep să se îmbunătățească dramatic, Android 6.0 pe 64 de biți produce cea mai mică diferență între Java și C.
Al doilea test este testul cu număr prim, folosind proba pe diviziune. După cum sa menționat mai sus, acest cod folosește 64 de bițilung întregi și, prin urmare, vor favoriza procesoare pe 64 de biți.
După cum era de așteptat, cele mai bune rezultate provin de la Android care rulează pe procesoare pe 64 de biți. Pentru Android 6.0 pe 64 de biți, diferența de viteză este foarte mică, doar 3%. În timp ce pentru Android 5.0 pe 64 de biți este de 38%. Acest lucru demonstrează îmbunătățirile dintre ART pe Android 5.0 și Optimizarea compilator folosit de ART în Android 6.0. Având în vedere că Android 7.0 N este încă o versiune beta de dezvoltare, nu am arătat rezultatele, dar în general este performant la fel de bine cu Android 6.0 M, dacă nu mai bine. Rezultatele mai proaste sunt pentru versiunile Android pe 32 de biți, iar Android 6.0 ciudat pe 32 de biți produce cele mai proaste rezultate ale grupului.
Al treilea și ultimul test execută o funcție matematică grea pentru un milion de iterații. Funcția face aritmetica întreagă, precum și aritmetica cu punct flotant.
Și aici pentru prima dată avem un rezultat în care Java rulează de fapt mai repede decât C! Există două explicații posibile pentru aceasta și ambele se referă la optimizare și la Optimizingcompilator de la ARM. În primul rând, Optimizing compilatorul ar fi putut produce un cod mai optim pentru AArch64, cu o alocare a registrelor mai bună, decât compilatorul C din Android Studio. Un compilator mai bun înseamnă întotdeauna o performanță mai bună. De asemenea, ar putea exista o cale prin codul pe care Optimizingcompilatorul a calculat poate fi optimizat, deoarece nu are nicio influență asupra rezultatului final, dar compilatorul C nu a identificat această optimizare. Știu că acest tip de optimizare a fost unul dintre accentele majore pentru Optimizingcompilator în Android 6.0. Întrucât funcția este doar o invenție pură din partea mea, ar putea exista o modalitate de a optimiza codul care omite anumite secțiuni, dar nu l-am reperat.Celălalt motiv este că apelarea acestei funcții, chiar și de un milion de ori, nu determină să funcționeze colectorul de gunoi.
Ca și în cazul testului primes, acest test folosește 64 bițilung numere întregi, motiv pentru care următorul punctaj cel mai bun vine de la Android 5.0 pe 64 de biți. Apoi, Android 6.0 pe 32 de biți, urmat de Android 5.0 pe 32 de biți, iar în final Android 4.4 pe 32 de biți.
Învelire
În general, C este mai rapid decât Java, însă decalajul dintre cei doi a fost redus drastic odată cu lansarea Android 6.0 Marshmallow pe 64 de biți. Desigur, în lumea reală, decizia de a utiliza Java sau C nu este alb-negru. În timp ce C are câteva avantaje, toate UI-ul pentru Android, toate serviciile Android și toate API-urile Android sunt proiectate pentru a fi apelate de la Java. C poate fi folosit cu adevărat doar atunci când doriți o pânză OpenGL goală și doriți să vă atrageți pe panza respectivă fără a utiliza API-uri Android.
Cu toate acestea, dacă aplicația dvs. are unele operații de ridicare grele, atunci acele părți ar putea fi portate la C și s-ar putea să observați o îmbunătățire a vitezei, însă nu atât cât ați putut vedea odată.
