SDK по сжатию нативных библиотек для приложений Android*

Download as PDF

Введение

Традиционно Android-приложения пишутся на Java* из-за ее элегантного объектно-ориентированного дизайна, а также по причине того, что AndroidSDKпредлагает кросс-платформенные опции именно на Java. Время от времени разработчикам необходимо использовать нативный интерфейс Android, особенно если управление памятью и производительность являются ключевыми параметрами. Нативный интерфейс Androidпредоставляется через NDK, поддерживающий разработку на C/C++.

В Googlesoftwaremarketочень много NDK-приложений. Чтобы снизить размер пакета, некоторые независимые поставщики программного обеспечения выпускают одиночный APKвместо FATAPK (одиночный APKсодержит либо ARM*, либо х86-библиотеку, в то время как FATAPKсодержит и то, и другое). Однако у FATAPKесть очевидные преимущества над одиночным APK. Он проще для доступа конечным пользователям, а библиотеки не накладываются друг на друга в процессе обновления приложения. Поэтому разработчики стремятся использовать FATAPKдля программной экосистемы Androidх86. Но как им уменьшить огромные размеры файлов FATAPK?


 

Zip* против LZMA

Чтобы решить проблему с размером FATAPK, автор разработал нативный SDK для сжатия библиотек. В базовой идее используется цепной алгоритм Lempel–Ziv–Markov (LZMA) (http://www.7-zip.org/sdk.html) для сжатия нативных библиотек. Googleиспользует Zipдля сжатия всего контента. И в то время как Zipявляется быстрым, его показатель сжатия ниже, чем у LZMA. LZMA, к слову, особенно хорош для сжатия крупных словарных файлов, найденных в нативных библиотеках. График показывает разницу в размерах файлов после применения сжатия с помощью Zipи LZMA.



 

Image may be NSFW.
Clik here to view.

Рисунок 1: Сравнение размеров одиночных файлов после сжатия с Zip* и LZMA¹



 

Image may be NSFW.
Clik here to view.

Рисунок 2: Сравнение размеров составных файлов (той же CPU-архитектуры) после сжатия с Zip* и LZMA¹



 

Image may be NSFW.
Clik here to view.

Рисунок 3: Сравнение размеров составных файлов (различной CPU-архитектуры) после сжатия с Zip* и LZMA¹

Image may be NSFW.
Clik here to view.

Рисунок 4: Сравнение размеров трех идентичных файлов после сжатия с  Zip* and LZMA¹

По 4 вышеуказанным графикам мы можем сделать вывод, что LZMAможет разительно снизить избыточность в файлах, что в наибольшей степени проявляется для трех идентичных файлов. Это отлично подходит для сжатия нативных библиотек. В целом, нативная библиотека будет использовать один и тот же код в архитектуре «armeabi», «armeabi-v7a», «x86» и даже в библиотеках «mips». Для «armeabi-v7a» - есть ARMNEONи код без NEON. Эти библиотеки имеют излишки информации из-за того же исходного кода. Даже в случае с другой архитектурой, к примеру, libffmpeg_armv7_vfpv3.soи libffmpeg_x86.so, где один – ARMEABI, а другой - x86, показатель сжатия составляет 40%, в то время как для одиночного файла этот показатель равен всего 20%.

SDKпо сжатию нативных библиотек

SDKпо сжатию нативных библиотек, разработанный автором, может помочь разработчику приложений интегрировать сжатие нативных библиотек LZMAдля получения файлов меньшего размера. Главная идея этого SDK– сжатие всей нативной библиотеки в каталог asserts, как показано ниже.

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в MoboPlayerна планшете с процессором Intel® Atom™ Z2760. Код вызывает NewInstanceв методе синхронизации, когда пользователи запускают приложение и отображается стартовый экран. Запрос NewInstanceнезаметен для конечного пользователя, поскольку декодирование происходит в фоновом режиме. Следующий график демонстрирует результаты сжатия.

Image may be NSFW.
Clik here to view.

Table 5: MoboPlayer* FAT APK size compression¹

Enhanced Functions of Native Library Compression SDK

Besides the LZMA compression, this SDK provides additional functions to encourage developers to include an x86 native library with the following:

1. Облачное хранение: фирма-разработчик может хранить библиотеки x86 на облачном сервере, и эти библиотеки могут быть загружены с сервера после установки. Такое действие автоматически выполняется на x86-устройствах и возможно только при наличии Wi-Fi-соединения.
2. Обнаружение отсутствующих библиотек: если библиотеки x86 отсутствуют, SDK автоматически произведет повторное извлечение ARM-библиотеки. Фирма-разработчик может скопировать библиотеку в директорию x86, чтобы избежать подобных ситуаций, но перед этим необходимо убедиться в отсутствии перекрестных ссылок между ARM и библиотеками x86.
3. Java-упаковщик: Java Package Tool обеспечивает конвертацию обычных APK в сжатые LZMA APK. Инструмент поддерживает системы Windows*, Linux* и Mac. Вы сможете использовать его так: ComPressApk.jar -a C:/my/test.APK -k c:/key *** ### alias. Если «-k» отсутствует (то есть вы запрашиваете просто ComPressApk.jar -a C:/my/test.APK), для подписи этого APK по умолчанию будет использован тестовый ключ Eclipse. Этот инструмент может быть интегрирован в скрипт сборки ants для автоматической поддержки компиляции и публикации.
4. Фильтр: функция ConfigureFilter позволяет вам извлекать только нужные библиотеки. К примеру, ввод ConfigureFilter("libffmpeg", "libffmpeg_armv7_neon.so") означает извлечение только libffmpeg_armv7_neon.so среди всех библиотек, которые начинаются с «libffmpeg». Это помогает снизить размер приложения после установки.

Выводы

Использование SDK по сжатию нативных библиотек для ваших Android-приложений может значительно снизить размер пакета нативной библиотеки, что приносит неоспоримую выгоду приложениям с объемными библиотеками (видео-плеерам, браузерам и 3D-играм). По вопросам источников и технической поддержки обращайтесь к автору.

Об авторе

Юминг Ли (Yuming.li@intel.com) – инженер по программному обеспечению приложений IntelSoftwareandServicesGroup. На данный момент он работает над мультимедиа-приложениями и оптимизацией производительности, в частности, на мобильных платформах Android.

¹Эти данные были получены в результате анализа внутренних тестов Intel® и приведены исключетльно для справки. Любые отличия в аппаратной и программной конфигурации могут влиять на производительность.