Android studio properties где найти

Полный список

Давайте посмотрим, как в Андроид приложениях формируется то, что мы видим на экране.

Урок обновлен 07.07.2017

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

Содержимое Activity формируется из различных компонентов, называемых View. Самые распространенные View — это кнопка, поле ввода, чекбокс и т.д.

Примерно это можно изобразить так:

Необходимо заметить, что View обычно размещаются в ViewGroup. Самый распространенный пример ViewGroup – это Layout. Layout бывает различных типов и отвечает за то, как будут расположены его дочерние View на экране (таблицей, строкой, столбцом …)

Также, в версии 3.0 в Android появилась новая сущность – Fragment. Но тему фрагментов мы рассмотрим в более поздних уроках, чтобы сейчас не усложнять материал.

Наверно уже запутал новыми словами и терминами, давайте посмотрим это все на практике.

Создадим приложение к этому уроку. Для этого запускайте Android Studio и открывайте проект Android lessons, который мы создали на прошлом уроке. Скорее всего, этот проект сразу откроется у вас по умолчанию.

Напомню, что мы решили создавать в этом проекте все модули (приложения) для уроков. А не создавать отдельный проект под каждый урок.

Создадим модуль. В меню File >New > New Module. Все шаги аналогичны тем, что мы проделывали на прошлом уроке, только будут другие названия приложения и модуля

Application/Library name: BasicViews
Module name: p0041basicviews
Package name: ru.startandroid.p0041basicviews

Модуль p0041basicviews создан и виден в списке модулей слева:

В этом модуле нам интересен файл: res > layout > activity_main.xml

Это layout-файл. В нем мы определяем набор и расположение View компонентов, которые хотим видеть на экране. При запуске приложения, Activity читает этот файл и отображает нам то, что мы настроили. Скорее всего, он у вас уже открыт на редактирование, но на всякий случай давайте еще раз откроем его двойным кликом и посмотрим, как он выглядит.

Куча кнопок, надписей и т.п. Я отметил важные зоны цифрами (с 1 по 6). Пройдемся по ним

1) Design и Text

Desing — это графическое представление экрана. Оно сейчас открыто. А Text — это текстовое представление. Оно выглядит так:

Мало что понятно. Мы пока что будем использовать только Design-представление.

2) Режимы отображения экрана

На скриншоте в области 3 вы видите два экрана. Обычный белый и рядом с ним какой-то синий. Это один и тот же экран, но он отображен в двух разных режимах:
Design — в нем мы видим View компоненты так, как они обычно выглядят на экране.
Blueprint — отображаются только контуры View компонентов

Кнопки в области 2 позволяют вам переключать режимы:
— Design
— Blueprint
— Design + Blueprint

Я в уроках обычно буду использовать Design режим. Вы можете использовать, какой вам удобнее.

3) Экран

Здесь вы можете видеть, как выглядит экран вашего приложения. Сюда мы будем добавлять различные компоненты из области 4.

4) Палитра

Это список всех View компонентов, которые вы можете добавлять на ваш экран: кнопки, поля ввода, чекбоксы, прогрессбары и прочее.

5) Дерево компонентов

Здесь представлена иерархия View компонентов вашего экрана. Сейчас, например, корневой элемент — это ConstraintLayout. А в него вложен TextView.

6) Свойства

Эта область пока пуста. При работе с каким либо View компонентом здесь будут отображаться свойства этого компонента. С помощью свойств вы сможете настраивать внешний вид, расположение и содержимое View компонента.

Чтобы вы понимали, о чем дальше пойдет речь, посмотрите пожалуйста этот урок:

Он хоть и под номером 180, но написан просто и понятно. В нем вы научитесь добавлять View компоненты на экран. После прочтения возвращайтесь сюда и продолжим.

Теперь, когда вы знаете, как добавлять компоненты на экран, мы можем продолжить.

Сейчас у нас на экране только TextView. Давайте добавим еще несколько компонентов. Например, Button и CheckBox.

Настройте им какие-нибудь привязки, чтобы они не уехали при запуске.

Обратите внимание, что компоненты появились в Component Tree

Значения button и checkBox — это ID, которые были присвоены компонентам автоматически. Пока оставим их такими, позднее научимся их менять и будем делать более осмысленными.

Теперь давайте изменим надписи на этих компонентах. Во вкладке Component Tree (слева-снизу) жмем на TextView, чтобы выделить этот компонент.

Теперь нам нужна вкладка Properties (справа). На скриншоте она была обозначена, как область 6. Здесь мы можем настроить свойства выделенного в Component Tree (или на экране) View компонента.

Найдем во вкладке Properties свойство text. Сейчас там прописан текст Hello World!, который и отображается на экране. Давайте поменяем его на свой текст. Поставьте курсор в это поле и напишите там, например, “Google Android”.

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

Текст на экране изменился. Был Hello World! Стал Google Android.

Аналогично вы можете изменить тексты на кнопке и чекбоксе. Просто выделяйте эти компоненты на экране или в Component Tree, в Properties ищите свойство text и пишите там свой текст. Можно даже на русском языке.

Все, что вы настроили в этом экране, сохранится в файле res > layout > activity_main.xml.

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

Студия спросит вас, запускать ли эмулятор

Выберите эмулятор и жмите OK. Название эмулятора у вас может быть другим

Ждем пока запускается эмулятор и, затем, любуемся результатом

Все ваши новые тексты должны отобразится на экране

Приложение отображает нам MainActivity, а оно в свою очередь читает файл activity_main.xml и отображает все View, которые мы в нем создавали и настраивали.

На следующем уроке мы:

рассмотрим layout-файл с другого ракурса – XML
разберем, откуда Activity знает, какой layout-файл надо читать и попробуем настроить на чтение другого файла
узнаем, какой layout-файл используется при смене ориентации экрана (горизонтальная/вертикальная)

Присоединяйтесь к нам в Telegram:

— в канале StartAndroid публикуются ссылки на новые статьи с сайта startandroid.ru и интересные материалы с хабра, medium.com и т.п.

— в чатах решаем возникающие вопросы и проблемы по различным темам: Android, Kotlin, RxJava, Dagger, Тестирование

— ну и если просто хочется поговорить с коллегами по разработке, то есть чат Флудильня

— новый чат Performance для обсуждения проблем производительности и для ваших пожеланий по содержанию курса по этой теме

Источник

Уменьшаем время сборки ваших Android-проектов

Доброе утро! Начинаем понедельник с материала, перевод которого подготовлен специально для студентов курса «Android-разработчик. Продвинутый курс».

Недавно я переносил кодовую базу Android в Kure на AndroidX. Мне показалось, что это прекрасная возможность поработать над скоростью сборки проекта. У Gradle всегда была плохая репутация из-за медлительности и ресурсоемкости, но я был очень удивлен, что незначительные изменения в конфигурации сборки могут так значительно увеличить ее скорость.

Посмотрите на показатели сканирования сборки до/после оптимизации

до оптимизации

после оптимизации ️️

Снизились с 5,5 минут до 17 секунд?? С ума сойти!

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

Прежде всего!

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

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

На сайте есть довольно много опций, но для краткости мы рассмотрим только то, что является наиболее важным.

В Summary отображается сводная информация о выполненных задачах и времени их выполнения. Но что нас здесь интересует, так это раздел Performance. Он делает более подробную разбивку общего времени сборки, как показано ниже.

В разделе Performance есть вкладка Settings and suggestions, в которой приведены рекомендации по улучшению скорости сборки. Давайте посмотрим на них.

В этом разделе мы можем найти несколько простых исправлений для повышения скорости. Итак, давайте продолжим и применим эти исправления в нашем проекте.

Шаг № 1: Обновите инструменты

Команда Android постоянно совершенствует и развивает систему сборки. Таким образом, в большинстве случаев вы можете получить значительное улучшение, просто установив последнюю версию инструментария.

Во время этого рефакторинга наш проект был на версии 3.2.1 плагина Gradle для Android Studio (на несколько версий старше, чем последний выпуск).

Вы можете перейти по этой ссылке, чтобы получить последнюю версию Gradle Plugin. На момент написания этого поста последней была версия 3.4.0.

Но здесь есть подвох, о котором мы должны помнить:

(Примечание: При использовании Gradle версии 5.0 или выше размер памяти демона Gradle по умолчанию уменьшается с 1 ГБ до 512 МБ. Это может привести к снижению производительности сборки. Чтобы переопределить этот параметр по умолчанию, укажите размер памяти для демона Gradle в файле gradle.properties вашего проекта.)

При использовании Gradle 5.0 и выше нам нужно будет явно увеличить размер памяти, чтобы скорость нашей сборки не ухудшилась. Мы вернемся к этому через минуту.

Откройте файл build.gradle верхнего уровня, который вы найдете в корне вашего проекта, и добавьте следующую строку в раздел зависимостей:

Вам также необходимо обновить distribution URL-адрес в файле свойств Gradle Wrapper, который находится по адресу gradle/wrapper/gradle-wrapper.properties . Обновите URL-адрес до следующего.

Вы столкнетесь с ошибкой при использовании Kotlin, если версия плагина Kotlin Gradle меньше 1.3.0. Если это так, воспользуйтесь подсказкой IDE, чтобы обновить Gradle плагин для Kotlin до последней версии (на момент написания этой статьи это версия 1.3.31).

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

Шаг № 2: Обновите конфигурации

Итак, мы смогли срезать около 2,5 минут от времени сборки, но это все еще недостаточно хорошо. Изучив логи сборки в терминале, я наткнулся на одну строку, которая нас заинтересует:

Gradle может отключить инкрементную компиляцию, так как следующие процессоры аннотаций не являются инкрементными: butterknife-compiler-10.1.0.jar (com.jakewharton:butterknife-compiler:10.1.0), dagger-compiler-2.9.jar (com.google.dagger:dagger-compiler:2.9).

Рассмотрите возможность установки экспериментального флага android.enableSeparateAnnotationProcessing-true в файле gradle.properties для запуска обработки аннотаций в отдельной задаче и выполнения инкрементной компиляции.)

Инкрементная компиляция в основном предотвращает расточительную компиляцию всего набора исходных файлов и вместо этого компилирует только те файлы, которые были изменены. Из логов видно, что мы не пользуемся этой функцией. Он предлагает нам использовать android.enableSeparateAnnotationProcessing=true , но, в любом случае, мы не должны использовать конфигурацию «annotationProcessor» поскольку в нашем проекте используется Kotlin.

К счастью, в версии 1.3.30 Kotlin добавлена поддержка пошаговой обработки аннотаций.

(Инкрементная обработка аннотаций (с 1.3.30)

Начиная с версии 1.3.30, kapt поддерживает инкрементную обработку аннотаций в качестве экспериментальной функции. В настоящее время обработка аннотаций может выполняться инкрементально, только если все используемые процессоры аннотаций являются инкрементными.
Чтобы включить инкрементную обработку аннотаций, добавьте эту строку в файл gradle.properties :

Обратите внимание, что инкрементная обработка аннотаций требует, чтобы инкрементная компиляция также была включена.)

1. 1. Измените конфигурацию annotationProcessor на kapt
2. 2. Включите экспериментальный флаг инкрементной обработки аннотации

Откройте файл build.gradle уровня вашего модуля и добавьте следующую строку в начало файла:

apply plugin: ‘kotlin-kapt’

Затем измените все конфигурации annotationProcessor в разделе зависимостей для использования kapt. Например:

//До
annotationProcessor ‘com.google.dagger:dagger-compiler:2.9’
//После
kapt ‘com.google.dagger:dagger-compiler:2.9’

Теперь откройте файл gradle.properties, расположенный в корне вашего проекта, и добавьте следующую строку:

Давайте снова запустим сборку.

Хорошо, похоже, мы еще немного продвинулись.

Шаг № 3: свойства Gradle

Мы на последнем этапе. Помните подвох, с которым мы столкнулись при обновлении версии плагина Gradle? Оказывается, более новые версии Gradle уменьшают размер используемой памяти до 512 МБ. Это сделано для того, чтобы слабые машины не расходовали слишком много памяти. У меня компьютер с 16 гигабайтами оперативной памяти, поэтому я могу позволить себе скормить около 2-3 гигов демону Gradle, но ваши цифры могут отличаться.

Откройте файл gradle.properties, расположенный в корне вашего проекта, и добавьте следующую строку. Не забудьте выбрать размер в соответствии с вашими требованиями и спецификацией компьютера.

org.gradle.jvmargs=-Xmx3072m -XX:MaxPermSize=512m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8

Пока мы это делаем, давайте также включим параллельные сборки и настройку по требованию в свойствах.

Вот как выглядит мой окончательный вариант файла gradle.properties :

• org.gradle.parallel — этот флаг позволяет Gradle собирать модули внутри проекта параллельно, а не последовательно. Это полезно только для многомодульных проектов.
• org.gradle.configureondemand — этот флаг настраивает только те модули, которые необходимы для проекта, а не собирает их все.

Сделав это, давайте посмотрим, какие у нас теперь показатели скорости сборки:

Заключительные замечания

Это ни в коем случае не обширный охват всех способов оптимизации скорости сборки. Есть множество других вещей, которые я не рассмотрел в этом посте, таких как использование minSdk 21 при использовании MultiDex, предварительная индексация библиотек, отключение сжатия PNG и т. д., — это всего лишь некоторые из них.

Но большинство из этих конфигураций требуют более глубокого понимания системы сборки Android и опыта работы с крупными многомодульными проектами (где преимущества наиболее очевидны). Шаги, которые я упомянул выше, легко внедряются в проект даже джуниор разработчиками и имеют значительные выгоды. Я надеюсь, что это поможет вам увеличить скорость сборки!

Источник