În mod tradițional, aplicațiile Android sunt scrise în Java * datorită designului său elegant, orientat spre obiect și datorită faptului că AndroidSDK oferă opțiuni cross-platform în Java. Din când în când, dezvoltatorii trebuie să utilizeze interfața nativă Android, mai ales dacă gestionarea memoriei și performanța sunt parametri cheie. Interfața Android nativ este furnizat prin intermediul NDK, care sprijină dezvoltarea în C / C ++.
Există o mulțime de aplicații NDK pe piața de software Google. Pentru a reduce dimensiunea pachetului, unii furnizori independenți de software produc un singur fișier APK în loc FATAPK (APK unică conține fie ARM *, orice x86-bibliotecă, în timp ce FATAPK conține atât unul cât și celălalt). Totuși, FATAPK are avantaje evidente față de un singur APK. Este mai ușor accesul utilizatorilor finali, iar bibliotecile nu se suprapun între ele în timpul procesului de actualizare a aplicațiilor. Prin urmare, dezvoltatorii încearcă să utilizeze FATAPK pentru ecosistemul software al Android86. Dar cum reduc dimensiunea imensă a fișierelor FATAPK?
Zip * vs. LZMA
Graficul 1: Compararea dimensiunilor unice ale fișierelor după comprimare cu Zip * și LZMA1
Graficul 2: Comparația dimensiunilor fișierelor compuse (aceeași arhitectură CPU) după comprimarea cu Zip * și LZMA1
Graficul 3: Comparația dimensiunilor fișierelor compozite (diferite arhitecturi ale procesorului) după comprimarea cu Zip * și LZMA1
Graficul 4: Compararea dimensiunilor a trei fișiere identice după comprimare cu Zip * și LZMA1
Pe cele 4 grafice de mai sus, putem concluziona că LZMA poate reduce dramatic redundanța în fișiere, ceea ce este cel mai evident pentru trei fișiere identice. Acest lucru este minunat pentru comprimarea bibliotecilor native. În general, biblioteca nativ va utiliza același cod în arhitectura «armeabi», «armeabi-v7a», «x 86» și chiar și în bibliotecile «MIPS». Pentru «armeabi-v7a» - există cod ARMNEONi fără NEON. Aceste biblioteci au informații excesive din cauza aceluiași cod sursă. Chiar și în cazul diferitelor arhitecturi, de exemplu, libffmpeg_armv7_vfpv3.so și libffmpeg_x86.so, în care unul - ARMEABI, iar celălalt - x86, rata de compresie este de 40%, în timp ce pentru un singur fișier, cifra este de doar 20%.
SDK pentru comprimarea bibliotecilor native
API-ul acestui SDK este foarte simplu. Când rulați pentru prima dată aplicația, codul se despachetează întreaga bibliotecă nativă din directorul asserts.
static boolean NewInstance (Cont context, Handler hdl, boolean showProgress)
statică DecRawso GetInstance ()
String GetPath (String libname)
Se recomandă de a modifica codul sursă și adăugați numai newInstance, atunci când este lansată aplicația, apoi înlocuiți System.loadLibrary (***) pe system.load (DecRawso. GetInstance () .GetPath (***)). După aceste modificări minore, fișierul APK va deveni mai mic, dar va continua să funcționeze ca mai înainte.
În cazul în care dezvoltatorii pot oferi suficient răgaz între solicitarea NewInstancei prima încărcare a bibliotecilor native, acestea ar trebui sa apel (NewInstance (continuare, nul, fals)) fără un argument Handler. În caz contrar, ar trebui să fie vizualizate Handler pentru «decodeend» mesaje asincrone.
Funcția SDK avansată pentru comprimarea bibliotecilor native
În plus față de compresia LZMA, acest SDK oferă dezvoltatorilor funcționalități suplimentare pentru a le include în biblioteca nativă x86:
Yuming Li ([email protected]) este inginer de software pentru Intel Software and Services Group. În prezent, lucrează la aplicații multimedia și la optimizarea performanțelor, în special pe platformele mobile Android.
Articole similare
-
Crearea automată de aplicații Android pentru radioul Internet
-
Multitasking pentru Android deschide diferite aplicații în ferestre separate, raznosolie
Trimiteți-le prietenilor: