Как ускорить работу android studio

Оптимизация разработки под Android

На сегодняшний день, Android Studio является популярнейшей средой разработки под ОС Android. Поэтому узнав несколько трюков и инструментов для разработки, вы значительно увеличите вашу продуктивность.

Начну с банальных и баянистых советов, которые не знают разве что новички:
-Не используйте мелкий шрифт, ведь его трудно читать
-Поставьте себе тему Darcula, потому что темный фон снижает напряжение для глаз
-И используйте стандартный Code Style, например AOSP Codestyle

Когда с простыми советами покончено, можно переходить и к чему-то посложнее.
Шпаргалка с горячими клавишами для Android Studio пригодится вам, чтобы увеличить скорость вашего взаимодействия со средой разработки.

Использование Live Templates в Android Studio также ускорит вашу разработку:

• newInstance — создает статическую функцию newInstance внутри фрагмента
• Toast — создает Toast.makeText(context, «», Toast.LENGTH_SHORT).show();
• fbc — findViewById с кастом
• const – определение интовой константы
• logd — генерация Log.d(TAG, «»);
• logm — имя текущего метода и его аргументы в лог
• logt – статическая TAG-строка с именем класса для лога
• psf — public static final
• soutm — печатает текущие имена классов и методов в System.out
• soutp — выводит имена и значения метода в System.out
• visible — установить видимость (true/false)
• gone — Установите видимость View GONE

Теперь, поговорим об использовании плагинов для Android Studio. Их огромное множество, но здесь я расскажу о самых полезных из них.

Данный плагин позволяет изменять стиль текста (camelCase, kebab-lowercase, KEBAB-UPPERCASE и т.д.), кодировать / декодировать, увеличивать / уменьшать, сортировать, фильтровать и выравнивать.

Rainbow Brackets
Вместо того, чтобы часами искать скобки, которые вы забыли закрыть, просто раскрасьте их с помощью данного плагина. Сэкономленные нервные клетки и часы работы гарантируются.

Project Lombok
Это Java-библиотека, которая генерирует шаблонный код за вас, сохраняя ваш код лаконичным и читабельным. Поскольку Lombok является библиотекой времени компиляции, он не сделает ваше приложение более тяжеловесным.

Vector Drawable Thumbnails
Расширение позволит вам открыть ваши векторные рисунки по одному щелчку мыши, вместо того, чтобы открывать отдельное приложение для этого.

Android Input
Данный плагин позволит вам вводить текст прямо в ваше Android-устройство или эмулятор. Также запоминает последний введенный текст.

Если этого материала вам было мало, вот еще две записи на Английском, относящихся к теме моей статьи:

• Встроенный терминал в Android Studio
• Настройка Android Studio

Источник

Оптимизация ресурсов в Android. Ускорение сборки и уменьшение размера APK

Привет. Меня зовут Кирилл Розов и вы если вы интересуетесь разработкой под Android, то скорее всего слышали о Telegram канале «Android Broadcast», с ежедневными новостями для Android разработчиков, и одноимённом YouTube канале. Этот пост является текстовой расшифровкой видео на канале

Система ресурсов в Android очень богата своими возможностями, которые позволяет нам описывать строки, хранить картинки и различные значения. Одной из очень удобных возможностей является эффективное определение ресурсов для различных конфигураций устройства (через квалификаторы): размера экрана, ориентации, локали, код оператора и множество другого. Есть в этом механизме узкое место для скорости сборки ваших проектов — R классы. Сегодня я расскажу вам откуда возникает такая проблема и как её решили в Google, разделив R классы.

Что такое R класс

Все ресурсы Android описываются в XML либо сохраняются файлами, например, drawable или raw ресурсы. Чтобы использовать ресурсы из кода, нам нужен какой способ ссылаться на них. Да, можно было бы хардкорно забивать строки в виде пути к ресурсу, как это сделано для ресурсов в JAR, но в Google сделали иной подход — генерация идентификаторов для каждого ресурса в коде. Для этого создаётся специальный R класс, который содержит вложенные классы по типам ресурсов: string, drawable, integer и др. После этого мы можем передавать идентификатор в специальные методы Resources или Context и получить необходимый ресурс.

Почему ресурсы из библиотек попадают в R класс приложения

Основной момент в R классе, то все подключенные Android Gradle модули или AAB файлы тоже могут содержать ресурсы и все их идентификаторы попадают в модуль, к которому они подключены. Это называется транзитивный R класс. Реализация этого аспекта была связана с удобством доступа ко всем ресурсам и отсутствием необходимости работы со множеством R файлов. Представьте как было бы организовывать доступ ко множеству R классов в Java коде? Пришлось бы использовать полные имена классов либо делать статические импорты для констант.

С Kotlin ситуация совсем другая, так как есть именованные импорты, что позволяют управлять легче, но Kotlin появился не сразу в Android.

Одна из причин появления префиксов у ресурсов в библиотеках — необходимость чтобы их имена были максимально уникальными, например в библиотеке Jetpack AppCompat для ресурсов используются префиксы abc

Нетранзитивные R классы

С одной стороны мы получили удобство, а с другой — проблему для скорости сборки проектов. Фактически при любом добавление ресурсу приходится генерировать R класс для вашего модуля, а затем смёржить его со R классами из зависимостей. Представьте какой размер R файла получается в app модуле? А что если попробовать разделить классы и управлять и генерировать R классы независимо друг от друга? И в Google это сделали. Назвали такую фичу — нетранзитивные R классы. Теперь к ресурсам каждой android зависимости создаётся свой независимый R класс, но это не будет распространяться на уже скомпилированные Android библиотеки.

Преимущества

К сожалению, у меня нету проекта, где я бы смог проверить эту фичу, но вот я пообщался с человеком, которые переводили свой проект на нетранзитивные R классы. Что за проект не могу рассказать, но он достаточно большой и с legacy. На экране вы можете видеть результаты по оптимизации и они улучшились по всем параметрам, начиная со скорости сборки, заканчивая размером приложения и файлов сборки.

Результаты оптимизации на реальном большом проекте

Как перевести проект

Я думаю что вас уже заинтересовала миграция. Чтобы это сделать вам необходимо в gradle.properties вашего проекта выставить в true значение property android.nonTransitiveRClass

Также вам надо выполнить миграцию в коде, чтобы обращаться к ресурсам из зависимостей через их R класс. Для этого вам нужно либо использовать полные имена пакетов, либо использовать alias для импортов в Kotlin (надеюсь что вы уже с ним)

Автоматическая миграция на нетранзитивные R классы в Android Studio

Проходится руками по всей кодовой базе сложно и никто не станет этого. Чтобы упростить это в Android Studio 2020.3 Arctic Fox добавили возможность автоматической миграции. Одна кнопка, предпросмотр изменений и нажатие «Refactor» позволит вам получить преимущества, о которых я рассказал.

В комментариях я буду рад услышать пробовали ли нетранзитивные R классы и какие у вас результаты оптимизации после миграции, а также если вы поделитесь опытом автоматической миграции с помощью Android Studio.

Источник

Как разогнать эмулятор Android

Каждый, кто хоть раз работал с эмулятором для разработки приложений под Android, знает, что даже на современном железе эмулятор тормозит так, что для его использования нужно нечеловеческое терпение. То есть, наверное, надо самому стать андроидом-киборгом.

Но есть и еще один метод – попроще.

Intel Hardware Accelerated Execution Manager (Intel HAXM) — это решение, использующее аппаратные возможности виртуализации (Intel VT) и позволяющее значительно ускорить работу эмулятора Android.

Данное решение работает в паре с эмулятором Android для х86 устройств. При этом, эмулятор будет работать со скоростью, приближенной к скорости работы реального устройства, что поможет сократить время на запуск и отладку приложения.

В случае разработки приложения, использующего только Dalvik разработчику не придется ничего менять, т.к. приложение не заметит разницы. В случае с NDK приложением необходимо будет добавить поддержку x86 архитектуры к списку собираемых библиотек. Сделать это несложно, нужно просто добавить поддержку x86 в make файл.

Системные требования

Поддерживаемые ОС

Установка

Intel HAXM можно установить как вручную, так и используя Android SDK Manager.

Установка вручную

Зайдите на сайт software.intel.com/ru-ru/android и скачайте установочный пакет для вашей платформы. Далее запустите установку и следуйте подсказкам мастера установки.

Установка с помощью Android SDK Manager

1. Запустите Android SDK Manager
2. В разделе Extras выберите «Intel Hardware Accelerated Execution Manager»
3. Отметьте его галочкой и нажмите «Install package…»
4. Далее подтвердите соглашение с лицензией и нажмите кнопку «Install»
5. SDK Manager скачает и распакует пакет в каталог extras, находящийся в каталоге, в который был установлен Android SDK
6. Перейдите в этот каталог и запустите установку Intel HAXM

Установка Intel HAXM

В процессе установки вам предложат определить объем выделяемой оперативной памяти. Вы можете оставить значение, предложенное по умолчанию. Если в процессе работы вы захотите изменить это значение – запустите установку еще раз.

В процессе установки может возникнуть и такое

В этом случае проверьте настройки в BIOS, возможно виртуализация поддерживается вашей системой, но по-умолчанию отключена.

Для того, чтобы проверить, что все установлено верно и работает, необходимо в командной строке выполнить:

sc query intelhaxm

После выполнения данной команды вы увидите текущий статус службы

Так же может пригодится способ остановить службу:

sc stop intelhaxm

sc start intelhaxm

Установка эмулятора Android x86

Описанное выше было не что иное, как подготовка почвы. Теперь необходимо установить сам эмулятор, который мы хотим «разогнать» с помощью Intel HAXM. В настоящий момент их два:

• Android 4.0.3 (API 15)
• Android 2.3.3 (API 10)

Устанавливаются они с помощью Android SDK Manager. Запускаем, отмечаем галочками интересующие нас образы и устанавливаем.

Создание виртуального устройства

После установки образа эмулятора Android для x86 необходимо создать новое виртуальное устройство с помощью Android Virtual Device Manager. Для этого:

• Запускаем ADV Manager
• Выбираем создание новойго устройства «New. »

1. В окне свойств задаем произвольное название, например «Intel_Android»
2. Выбираем версию, в моем случае версия «Android 4.0.3 – API Level 15»
3. Устанавливаем остальные параметры (размер и наличие SD карты, разрешение и т.д.)
4. Далее следует добавить обязательный параметр в раздел «Hardware» — «GPU Emulation» (кнопка «New», в списке «Property» необходимо выбрать «GPU Emulation», затем «ОК») и установить его в «yes»

Готово! Теперь осталось запустить и проверить все ли настроено верно. Выбираем созданный эмулятор и запускаем его кнопкой «Start». Далее идем в настройки и смотрим название устройства. Если все было сделано правильно, то для нашего примера, в поле «Model number» мы увидим строку «Android SDK Build for x86».

Конец мучениям и долгим ожиданиям! Наш эмулятор начал работать быстрее, причем настолько, что можно прямо из него просматривать видео с Youtube в режиме реального времени, а не как раньше в режиме слайд-шоу.

Источник

Пять шагов по оптимизации производительности приложения для Андроид

В этой небольшой статье я хочу поделиться с вами опытом, как программно оптимизировать производительность приложения Андроид за 5 простых шагов на примере создания цифровой версии игры «Корона Эмбера».

До создания серьезных приложения со сложной структурой View и Layout’ов мы особо не задумывались над тем, как простые и логичные действия в стиле «смотрите, я набросал дизайн из лэйаутов» могут серьезно замедлить работу всей программы.

Помимо прочего, задача с «Короной Эмбера» осложнялась еще и тем, что игра, которую мы задумали перенести на Андроид платформу, была сама по себе достаточно насыщенной различными компонентами, которые как-то надо было умещать на игровом поле или рядом с ним.

В статье я собрал наш успешный опыт и облёк его в удобную и читабельную форму, полезную для тех, кто все еще гуглит «как программно оптимизировать приложение под Андроид» или «почему мое приложение лагает».

Итак. Исходная точка (то, как это все выглядело ДО оптимизации)

Дизайн приложения был создан из «правильной» кучи около двух сотен View и десятка Layout’ов. Загрузка игрового поля происходила около 5 секунд, а почти каждое действие зависало еще на 1-2 секунды. И если на прогрессивных устройствах и эмуляторах лаги были практически незаметны, то на большинстве менее современных устройств картина выглядела достаточно печальной.

Понятно, что это не устраивало ни меня, ни нашу команду, ни тестеров. И хотя мы были искреннее уверены, что все оптимизировано дальше некуда, мы принялись искать информацию.

Часть знаний, которыми я хочу поделиться, мы нашли здесь — классные видео-уроки с русскими субтитрами (рекомендую), часть — на Хабре, часть — в глубинах Интернета, на том же сайте Google Developers.

Причем, каждый раз получая новую порцию и проводя очередную оптимизацию, мы были уверены «все теперь дальше некуда, быстрее не будет» и с каждым шагом открывали для себя все больше и больше нового.

И вот, как это происходило.

Шаг 1. Измерение

По сути это даже не шаг, а настойчивая рекомендация постоянно измерять свою производительность. Для этого в Андроид Студио предусмотрено несколько специальных программ: Android Device Monitor с HierarhyViewer, SystemTracing, Method Profiling; Android Monitor с Memory, CPU и GPU мониторами. Описывать их работу не цель данной статьи, вы легко можете найти гайды здесь же, на Хабре, или в упомянутых видео-уроках.

Суть в том, что чтобы оптимизировать производительность, нужно сначала понять где же она «спотыкается».

Хотя, даже без измерения, есть несколько вещей, на которые необходимо обращать внимание каждому разработчику и мы шагаем дальше.

Шаг 2. Оптимизация иерархии и снижение веса

Основная потеря производительности приложений происходит при пересчете и перерисовке отображенных Layout’ов. Причем чем «тяжелее» лэйаут — тем дольше происходит перерасчет его показателей. И тут надо обратить внимание на следующие моменты:

— в вашей иерархии не должно быть вложенных LinearLayout с параметрами «weigh» (вес). Измерение такого лэйаута занимает в два (три, четыре! — в зависимости от вложенности) больше времени. Лучше заменить эту конструкцию на GridLayout (или support.v7.GridLayout для API меньше 21);
— некоторые LinearLayout можно заменить на RelativeLayout, тем самым убрав дополнительные вложения, например;
— оказывается, RelativeLayout также измеряется дважды. Где возможно — его нужно заменить на более «легкий» FrameLayout.

Изучив нашу разметку мы с ужасом обнаружили, что в ней есть вложенные до четырех (!) раз LinearLayout с параметром вес, игровое поле состоит из почти сотни RelativeLayout (клетки поля), а некоторые Layout просто не нужны.

(Зеленым отмечено допустимое вложение, желтым — нежелательное, оранжевым — опасное, красным — «никогда-так-не-делайте!»)

После этого мы немного переработали структуру. «Персонажа» вынесли в отдельный фрагмент с RelativeLayout, все вложенные Linear заменили на (один!) support.v7.GridLayout, а все RelativeLayout (на скрине их не видно — это клетки поля) заменили на FrameLayout. Получилось и симпатишней и производительней.

Однако до конца наши проблемы это не решило, и мы пошли дальше.

Шаг 3. Лишняя перерисовка (Overdraw)

Оказалось, что Андроид тщательно прорисовывает каждую картинку, каждый background у каждого View на экране. Здесь он, конечно, молодец. Но что делать, если одни изображения перекрывают другие, бэкграунды накладываются и часть этой прорисовки становится абсолютно ненужной? Правильно — отключать все, что не видно и не нужно.

Измерить наложение перерисовки оказывается очень просто: на своем устройстве в «Параметрах разработчика» нужно включить «Показывать превышение GPU», запустить приложение и посмотреть на экран.

Цвета View-элементов покажут, насколько у вас все хорошо (или плохо).

Свой цвет — уровень 0, «идеально»
Синий цвет — уровень 1, «нормально.
Зеленый цвет — уровень 2, „допустимо“.
Светло-красный цвет — уровень 3, „нежелательно“.
Красный цвет — уровень 4+, „не дай бог“.

Наша картинка вновь ввергла нас в ужас:

Нам пришлось снова пройтись по всей разметке и отключить background там, где он оказался лишним. Не забыли и про основной бэк приложения — одной простой строчкой:

В теме приложения выключили и его. И вот что получилось в итоге. Может и не везде идеально, но вполне допустимо. (Почти все View опустились на 3 уровня!)

Шаг 4. Кэширование — ключ к успеху

Тоже вполне очевидная вещь, которая не казалась обязательной — это кэширование. В частности (в данном случае) кэширование шрифта.
Как вы уже наверное обратили внимание, везде, включая логи, используется свой шрифт и, о (опять) ужас!, каждый раз, для каждого нового текста он подгружается заново из Assets. Каждый раз, Карл! (черным цветом — основной потом, коричневым — работа Assesnager’а).

С кэшированием до этого никто из нас не сталкивался, но тут нас выручил один хороший человек со StackOverflow и подсказал простой код:

Применив который, лично я вообще практически забыл, что такое лаги.

Шаг 5. „А это — под укроп!“

Как в анекдоте, где мужику сказали, что он получит под надел столько земли, сколько сам сможет измерить и он скакал, бежал, шел, полз и в конце изможденный снял с себя шапку и кинул на сколько смог со словами: „А это — под укроп“, так и мы стремились максимально до мельчайших деталей оптимизировать производительность.

Поэтому пришло время оптимизации кода. Конечно, то как пишется код — это уже больше дело правильной привычки, и тут можно только дать несколько общих рекомендаций (более подробно их можно найти в любой статье по программной оптимизации). Вот с чем столкнулась наша команда:

— создавайте поменьше „ненужных“ циклов. Если что-то можно сделать без них — делайте без них;
— не создавайте переменных в цикле. Лучше создать их за его пределами, а в цикле просто обновлять;
— если есть необходимость обратиться к ресурсам неоднократно (с помощью gerResources() или же просто в другой класс/массив, например, myList.get (0)) — лучше запишите полученный результат в новую переменную и используйте ее: int myItem = myList.get(0); — это тоже подарит вашему приложению миллисекунды свободного времени;
— по возможности используйте статические методы (если нет необходимости обращаться к самому классу);
— ну и классический способ: на финальном этапе программирования убирайте инкапсуляцию (геттеры и сеттеры) и обращайтесь к переменной напрямую.

Подводя итог

Уверен, что сделанные шаги не являются окончательными и всегда будет „место под укроп“, до которого мы не добрались. Всегда готов узнать о шаге №6, 7… и даже №157, если вы захотите ими поделиться в комментариях. Более того, за „науку“ буду благодарен.

А пока, резюмируем, что же нужно сделать, чтобы ваше приложение начало „летать“:

1. Измерьте производительность своего приложения и найдите источник проблемы. Может у вас это будет не шрифт, а, например, утечка памяти (включаем Memory Monitor);
2. Оптимизируйте структуру и иерархию View (включаем HierarhyViewer и здравый смысл);
3. Убираем везде все ненужные бэки, включая background приложения (в этом случае учтите, что для корректного отображения вам все равно понадобится общий бэк);
4. Смотрим на часто используемые ресурсы/загрузки/картинки/шрифты и кэшируем их;
5. Делаем оптимизацию программного кода.

В итоге, после всех этих шагов, картинка трассинга приложения стала выглядеть вот так:

задержки практически исчезли (или стали незаметны), что нас вполне устроило.

Ну и конечно, первая мысль, которая пришла ко мне в голову после всей нашей оптимизации: „Вау! Теперь же можно добавить еще больше View и Layout на основной экран!“

Источник