Традиційно Android-додатки пишуться на Java * через її елегантного об'єктно-орієнтованого дизайну, а також у зв'язку з тим, що AndroidSDK пропонує крос-платформні опції саме на Java. Час від часу організатори повинні використовувати нативний інтерфейс Android, особливо якщо управління пам'яттю і продуктивність є ключовими параметрами. Нативний інтерфейс Android надається через NDK, що підтримує розробку на C / C ++.
В Google software market дуже багато NDK-додатків. Щоб знизити розмір пакета, деякі незалежні постачальники програмного забезпечення випускають одиночний APK замість FATAPK (одиночний APK містить або ARM *, або х86-бібліотеку, в той час як FATAPK містить і те, і інше). Однак у FATAPK є очевидні переваги над одиночним APK. Він простіше для доступу кінцевим користувачам, а бібліотеки не накладаються один на одного в процесі оновлення програми. Тому розробники прагнуть використовувати FATAPK для програмної екосистеми Androidх86. Але як їм зменшити величезні розміри файлів FATAPK?
Zip * протівLZMA
Графік 1: Порівняння розмірів одиночних файлів після стиснення сZip * іLZMA1
Графік 2: Порівняння розмірів складових файлів (тієї жеCPU-архітектури) після стиснення сZip * іLZMA1
Графік 3: Порівняння розмірів складових файлів (разлічнойCPU-архітектури) після стиснення сZip * іLZMA1
Графік 4: Порівняння розмірів трьох ідентичних файлів після стиснення сZip * іLZMA1
За 4 вищевказаним графіками ми можемо зробити висновок, що LZMA може разюче знизити надмірність в файлах, що найбільшою мірою проявляється для трьох ідентичних файлів. Це відмінно підходить для стиснення нативних бібліотек. В цілому, нативная бібліотека буде використовувати один і той же код в архітектурі «armeabi», «armeabi-v7a», «x86» і навіть в бібліотеках «mips». Для «armeabi-v7a» - є ARMNEONі код без NEON. Ці бібліотеки мають надлишки інформації через те ж вихідного коду. Навіть у випадку з іншою архітектурою, наприклад, libffmpeg_armv7_vfpv3.so і libffmpeg_x86.so, де один - ARMEABI, а інший - x86, показник стиснення складає 40%, в той час як для одиночного файлу цей показник дорівнює всього 20%.
SDK зі стиснення нативних бібліотек
API цього SDK дуже простий. Під час першої активації код розпаковує всю нативную бібліотеку з каталогу asserts.
static boolean NewInstance (Context cont, Handler hdl, boolean showProgress)
static DecRawso GetInstance ()
String GetPath (String libname)
Рекомендується модифікувати вихідний код і додавати тільки NewInstance, коли додаток запускається, потім замінити system.loadlibrary (***) на system.load (DecRawso. GetInstance () .GetPath (***)). Після цих незначних змін APK стане менше, але функціонувати продовжить як раніше.
Якщо розробники можуть забезпечити достатню відстрочку між запитом NewInstanceі першим завантаженням нативной бібліотеки, вони повинні викликати (NewInstance (cont, null, false)) без аргументу Handler. В іншому випадку слід переглядати Handler для отримання асинхронного повідомлення «decodeend».
Розширений функціонал SDK зі стиснення нативних бібліотек
Крім стиснення LZMA, цей SDK забезпечує розробникам додатковий функціонал для включення його в нативну бібліотеку x86:
Юмінг Лі ([email protected]) - інженер з програмного забезпечення додатків Intel Software and Services Group. На даний момент він працює над мультимедіа-додатками і оптимізацією продуктивності, зокрема, на мобільних платформах Android.