Country not specified
Unknown website Share

Apps4all

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

Полезные приемы по оптимизации Android-приложений на х86

​-march=​Intel® 64 и IA-32 Architectures Optimization Reference Manual .Intel заинтересован помочь разработчикам обеспечить хорошую (если не сказать, отличную) работу Android-приложений на базе архитектуры Intel. В то время как Intel обеспечивает поддержку по оптимизации Dalvik, Java, движка V8 и Bionic C, по содействию базе кодов и по предоставлению релизов 32- и 64-битного ядра Kernel для IA на уровне сообщества, компания также создает новые инструменты для помощи разработчикам Android. Многие из низ сфокусированы на улучшении производительности и доступны со стандартной ARM архитектурой для х86 – libhoudini.

Для начала выберите правильные инструменты. Существует 3 общих метода создания Android-приложений. Это приложения:

  • Скомпилированные через Java и использующие Android SDK API для работы в виртуальной машине Dalvik (статья по ART скоро будет доступна для AndroidL). Использование последней версии SDK избавляет вас от большей части отличий, хотя вам, возможно, стоит обратить внимание на выделение памяти на устройствах с высоким разрешением экрана. Тестирование пройдет быстрее, если вы ускорите ваше программное обеспечение для Android-эмуляции с помощью ​​Intel® ​HAXM (потребует Intel®; Virtualization Technology и XD, где оба установлены на ON).​
  • Сфокусированные на веб: ​HTML5 и ​​JavaScript​. Для получения информации по Android Open Source, зайдите на сайт ​Android-IA.
  • Созданные и портированные через NDK (на C++). Это наиболее предпочтительный метод, в случае если у вас есть ресурсоёмкие функции или уже есть код C++. Обычно нативный С++ код функционирует быстрее, поскольку «разговаривает» на одном языке с оборудованием, так как код уже скомпилирован в исполняемый формат непосредственно до применения. И он уже не требует интерпретации на машинный язык.

Эта статья будет освещать оптимизацию приложений на базе NDK. Это могут быть одиночные C/C++ коды или же включающие сторонние библиотеки и/или код ассемблера.

Важно: Если у вас все еще нет Android development environment (IDE), новый набор инструментов​ ​Intel® INDE (Intel® Integrated Native Developer Experience) загрузит выбранный Android IDE, а также установит многочисленные инструменты Intel, чтобы помочь вам создавать, компилировать, выявлять неполадки и публиковать Android-приложения. Пройдите по этим ссылкам на материалы по регистрации и установке ​Intel® INDE​настройке Eclipse IDE со ссылками на видео по установке NDK & SDK, Eclipse и работе эмулятора (включая методы по его ускорению) или устройств на базе архитектуры Intel®.

Высокоуровневая разработка на NDK включает следующие шаги и минимальные изменения для работы с архитектурой х86:

  • Создайте проект Android и директорию jni. Отредактируйте Application.mk для показа APP_ABI = all (если размер файла учитывается ARM, и x86 в том же пакете) или x86. Обратите внимание, что параметр APP_ABI также влияет на операции с плавающей запятой – см. ниже).​
  • Код. Любой нативный (C++) код может быть использован повторно. Перепишите любой линейный код ассемблера или специфический ARM код. Используйте javah для создания заголовочного файла JNI/нативного кода. Убедитесь в правильной интерпретации между стандартными условными обозначениями C++ Windows и Java/JNI, используя макросы JNIEXPORT и JNICALL.
  • Скомпилируйте/постройте библиотеки (обратитесь к библиотекам generates .so и поместите их в подходящие проектные директории). Используйте "ndk-build APP_ABI = X86 " с несколькими изменениями buildflags – см. ниже. Также убедитесь в рекомпиляции любых сторонних библиотек.
  • Вызовите его из Java. Пропишите в Java функциональные нативные ( C++) вызовы и загрузите общую библиотеку, используя System.loadlibrary().
  • Отладка. Отладка ndk-gdb может быть использована путем исполнения ndk-build с манифестом, установленным как debuggable. Убедитесь, что adb-директория добавлена в путь поиска исполняемых файлов, и только один объект находится в исполнении.

Помимо базового «портирования» доступны некоторые приемы оптимизации:

  • Ускорьте свой программный Android-эмулятор, используя​ ​Intel® HAXM​ для сопутствующей аппаратной эмуляции. Intel® HAXM потребует Intel® Virtualization Technology (Intel® VT) и XD, установленных как on.
  • Установите APP_ABI = x86 (создает один apk со всеми исполняемыми файлами) или = armeabi armeabi-v7ax86, в зависимости от лимита размера вашего файла (учтите, что x86 включает аппаратную плавающую запяутую, как это делает и armeabi-v7a-x86 в некоторой степени).
  • В процессе компиляции используйте gcc "-malign-double" (для выравнивания памяти – см. также #9).
  • В процессе компиляции добавьте подходящие поточные CPU flags: для характеристики мультипоточности процессора Intel® Atom™ пробуйте -mtune=atom -mssse3 -mfpmath=sse для немультипоточных (BYT, SLM, Merrifield) используйте -mtune=slm -msse4.2 -mfpmath=sse
  • используйте ​​-march= для ограничения к специфическому CPU (mtune работает на большем количестве моделей, однако оптимизируется под обозначенные типы)
  • -mavx неприменяется на Atom
  • Используйте little Endian (по умолчанию с NDK).
  • ARM поддерживает оба big и little Endian, Intel® Atom™ поддерживает только little, так что проверьте ваши gccflags.
  • Используйте gcc v 4.8.    2 toolchain paths (android-ndk\toolchains\arm-linux-androideabi-4.8 против x86 android-ndk\toolchains\x86-4.8)
  • Удостоверьтесь, что вы используете корректный JNIEXPORT метод подписи для установки метода записи в нативный код – (согласуйте функцию подписи файла заголовка, чтобы убедиться, что исходный код компилируется на Windows). JNIEXPORT; void; JNICALL; Java_ClassName_MethodName
  • После компиляции проверьте системный лог, чтобы удостовериться, что целевая нативная библиотека успешно загружается во время исполнения (в логе это будет выглядеть как "added shared lib //<path>").
  • Задайте явно выравнивание памяти, чтобы предотвратить ошибки загрузки и сетевые проблемы. ARM занимает 24 байта, однако требует 8-байтного выравнивания для 64-битных переменных, в то время, как x86 занимает 16 байт. Поэтому попробуйте обеспечить 16-байтное выравнивание структур данных. Затем используйте выравненные передачи (MOVAPS, MOVNTA) в процессе загрузки этой структуры в XMM регистры. Посмотрите ​​Reducing the impact of Misaligned Memory Accesses​.
  • Записывайте данные напрямую в основную память (потоковая передача хранит инструкции MOVNTPS, MOVNTQ), поскольку у процессора Intel® Atom™ нет L3 кэша. Это также экономит пропускную способность за счет избегания «грязных» буферов при вытеснении данных из кэш-памяти.
  • Избегайте остановок вследствие ограниченного кэша L2. За исключением специфических экземпляров класса (где загрузка и хранение по одному адресу, одного размера операнда, и проводится из регистра общего назначения), загрузка на процессоре Intel® Atom™ будет приостанавливаться в нескольких циклах для записи в кэш. Вдобавок, сохранение SSE операндов (из xmm регистров) никогда не переадресовывается на последующие загрузки. А значит, для обоих переадресованных и непереадресованных сценариев пытайтесь управлять данными внутри регистра, делая вычисления в xmm-регистрах. К примеру, в mp3-декодере есть цикл кодирования для аккумулирования/вычисления сумм в регистре и затем суммирования по всему регистру. Это приводит к задержке между записью 16 байт в массив pSum и чтением 4 байт из массива pSum. Чтобы этого избежать, вычисляйте горизонтальную сумму в xmm-регистрах, используя инструкции HADDPS или серию сложений и перетасовок (но имейте в виду, последовательность HADDPS быстрее на процессорах Intel® Atom™, но медленнее на многих процессорах Intel Core). Воспользуйтесь инструкциями SSE min и max для отсечения выборки, превышающей 16-битный диапазон.
  • Обнулите XMM-регистр целиком (MOVLPS, MOVHPS, PINSRW) перед использованием, поскольку некоторые инструкции загружают часть регистра, что может вызвать проблемы в коде, которые могут сохраниться в другой части.
  • ​Прочтите статьи по оптимизации SIMD-инструкций (IntelSSE против ARM NEON). Рассмотрите вариант использования библиотеки ​NEONvsSSE_5.h, доступной здесь (вместо arm_neon.h). В статье также упоминается о снижении производительности при работе с константами (не ставьте инициализацию в цикл, замените логическими/сравнительными операциями по возможности), и избегайте последовательного выполнения (используйте векторизацию).
  • Замените операции sqrt и операции деления, занимающие много циклов, любой операцией по табличному поиску, взаимной аппроксимацией (RCPPS-инструкция) или последовательностью Ньютона.
  • Следите за вызовами плавающей запятой. Используйте Float вместо Double (так как Double часто использует стандартную процедуру SW lib). Float - быстрее и сохраняет пропускную способность памяти на процессорах Intel® Atom™. Также APP_ABI установит, используется ли floatingpoint SW (armeabi) или HW (X86, armeabi-v7ax86). Вы не всегда захотите выполнять все вычисления HWFPU с использованием алгоритма x86 (к примеру, деление по степени двойки в целом коде – это быстрая операция, однако в рамках Android-оптимизации вы должны умножать обратно (y=x*.5 вместо y=x/2).
  • Снизьте накладные издержки небольших функций. Используйте Inline-функции в областях, включающих передачу параметров, установку новых стековых фреймов/ восстановление старых стековых фреймов/ сохранение стековых фреймов вызывающей программы, накладывающей адреса на стеки; возвращаемые значения и возвратные функции. Просмотрите также ​Intel® 64 и IA-32 Architectures Optimization Reference Manual .
 
Intel
разработчикам
разработка
0 0 0

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