Country not specified
Unknown website Share

Apps4all

Страна: -
Город: -
Был онлайн: -
О себе:
 
08-07-2016, 11:14
Apps4all

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

Введение

Традиционно 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

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

53d752064c60b8.57991811.png

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

53d7528d55ed15.48616304.png

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

53d752babbe358.21144479.png

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

53d752d48450a1.08761811.png

График 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 по сжатию нативных библиотек

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 незаметен для конечного пользователя, поскольку декодирование происходит в фоновом режиме. Следующий график демонстрирует результаты сжатия. 

53d754fd3065d3.85625588.png

График 5: Сжатие MoboPlayer* FATAPK

Расширенный функционал SDK по сжатию нативных библиотек

Помимо сжатия LZMA, этот SDK обеспечивает разработчикам дополнительный функционал для включения его в нативную библиотеку x86:

  • 1. Облачное хранение: фирма-разработчик может хранить библиотеки x86 на облачном сервере, и эти библиотеки могут быть загружены с сервера после установки. Такое действие автоматически выполняется на x86-устройствах и возможно только при наличии Wi-Fi-соединения.
  • 2. Обнаружение отсутствующих библиотек: если библиотеки x86 отсутствуют, SDK автоматически произведет повторное извлечение ARM-библиотеки. Фирма-разработчик может скопировать библиотеку в директорию x86, чтобы избежать подобных ситуаций, но перед этим необходимо убедиться в отсутствии перекрестных ссылок между ARM и библиотеками x86.
  • 3. Java-упаковщик: JavaPackageTool обеспечивает конвертацию обычных APK в сжатые LZMAAPK. Инструмент поддерживает системы 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) – инженер по программному обеспечению приложений Intel Software and Services Group. На данный момент он работает над мультимедиа-приложениями и оптимизацией производительности, в частности, на мобильных платформах Android.

Оригинал статьи на Intel® Developer Zone: https://software.intel.com/en-us/android/articles...

 
Intel
SDK
0 0 0

Чтобы оставлять комментарии вам необходимо зарегистрироваться