Country not specified
Unknown website Share

Apps4all

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

​Будет ли мое Android-приложение работать с ART вместо Dalvik?

ART – это виртуальная машина, работающая по принципу ahead of time («впереди времени»). Это означает, что dex2oat используется единожды в процессе первичной установки приложения. Dalvik работал по принципу just in time («во время»), производя компиляцию уже в момент запуска приложения.

В обмен на более длительный процесс установки, ART освобождает процессор уже к моменту запуска приложения. Вдобавок, новый менеджер памяти и сборщик мусора сокращают число и длительность пауз. Другими словами, ART обеспечивает лучшую отзывчивость и меньшее энергопотребление приложения. Но помните, что уменьшение количества памяти, используемого в процессе работы означает и увеличение объема приложения, связанное с необходимостью хранить скомпилированные исполнительные файлы. ART будет работать с архитектурами ARM, x86 и MIPS, также ART демонстрирует явное улучшение процессов вычислений с плавающей запятой.

Что же меняется для кодинга? Хорошая новость: ART обладает обратной совместимостью и использует формат байт-кода Dex (применяемый в Dalvik). Это означает, что большинство приложений будет работать, и при этом гораздо лучше.

Тем не менее, есть несколько вещей, которые необходимо проверить и, возможно, оптимизировать:

1) Проверьте значение, возвращаемое функцией System.getProperty("java.vm.version"). ART - "2.0.0" или выше.

2) Если вы используете JNI для запуска кода C/C++, убедитесь в использовании CheckJNI (установите debuggable="true" в манифесте). См. статью “Debugging Android JNI withCheckJNI” (примечание – эта опция предназначена для отладки во время разработки. Её не следует использовать в релизном варианте кода).

3) Обновите все используемые инструменты до последней версии. ARTосуществляет более жесткую верификацию байт-кода, нежели Dalvik. Код, созданный с помощью инструментов Android, должен работать, однако некоторые пост-процессинговые инструменты могут создавать файлы с ошибками (что приемлемо Dalvik и непригодно для ART).

4) Подумайте, возможно ли отменить некоторые проверки исключений (которые могут больше не понадобиться, поскольку ART анализирует весь код сразу; но при этом не забывайте, что Dalvik еще будет использоваться какое-то время).

5) Удалите большую часть вызовов System.gc(), в особенности те, что используются для минимизации количества вызовов типа GC_FOR_ALLOC или фрагментации.

6) Не сохраняйте ссылки на данные объектов и не запускайте измененные ссылки в Release...ArrayElements(). Программа-сборщик мусора (уже есть в AOSP) может перемещать объекты в памяти, и запуск Get и Release в ArrayElements() может повлечь повреждение информации в памяти. Если вы производите какие-либо изменения в возвращаемых элементах массива, вам необходимо вызвать одну из следующих функций:

  • изменения отсутствуют > используйте режим JNI_ABORT (освободите память, без copyback)
  • произведены изменения, но нет необходимости на них ссылаться > используйте код 0 (обновляет массив элементов и освобождает копию)
  • произведены изменения, и необходимо зафиксировать их > используйте JNI_COMMIT (который обновляет базовый массив объектов и сохраняет копию)

7) Поля Object теперь являются приватными. В процессе итерации классовой иерархии как части фреймворка сериализации, остановитесь, когда Class.getSuperclass()==java.lang.Object.class (не продолжайте, пока возвращаемое значение не будет равно 0)

8) Используйте дополнительную обработку ошибок и протоколирование в ART:

  • Улучшенное перемещение и протоколирование NoSuchMethodError: из GetMethodID(), GetStaticMethodID(), и RegisterNatives call (что вызвано, вероятно, исключением метода инструментом вроде ProGuard)
  • NoSuchFieldError (вместо 0) из GetFieldID() и GetStaticFieldID()
  • Предупреждение, когда субклассы пытаются переопределить package-private методы. Для переопределения метода класса пропишите метод как публичный или защищенный.
  • Прочие проблемы, о которых сигнализирует верификатор ART, включают:
    • А) неверное управление процессом
    • Б) несбалансированный monitоrenter/monitorexit
    • В) список типов параметров с нулевой длиной

9) Обращайте внимание на более строгое применение JNI: методы CallNonvirtual---Method() требуют, чтобы метод декларировал класс, а не субкласс.

10) Следите за размером объединенного стека ART, который должен быть примерно равен двум стекам Dalvik (по умолчанию 32 Кб для стека Java и 1 Мб для нативного стека). Проверку размера стека необходимо осуществлять и в участках, где его размер задаётся явно – включая вызовы ThreadConstructorс увеличением размера стека (при появлении ошибки StackOverflowError).

11) Следите за размером pthread (pthreat_attr_setstack() и pthreat_attr_setstacksize()), поскольку вызовы, включающие AttachCurrentThread(), могут повлечь за собой ошибку.

12) Удалите любые зависимости на установленных файлах формата .odex в system/framework, /data/dalvik-cache или в оптимизированной output-директории DexClassLoader. В то время как ARTследует таким же правилам наименования и блокировки в ELF, приложения не должны зависеть от формата файла.

13) Используйте последнюю версию Mockito для того, чтобы ProxyInvocationHandler.invoke() возвращал 0 (вместо пустого массива) в случае, если аргументы отсутствуют.

14) Проверяйте все посылаемые вами уведомления. В AndroidL доступна новая цветовая схема.

  • Используйте android.app.Norification.Builder.setColor() для установки акцентированного цвета в кружке за изображением вашей иконки.
  • Не забывайте использовать исключительно альфа-каналы для главной иконки уведомлений и иконок действий.
  • Проверяйте уведомления Heads up (те, что используют fullScreenIntent или уведомления высокого приоритета с рингтоном или вибрацией)
 
Intel
разработка
разработчикам
Android
0 0 0

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