Тайна: структура проекта и система сборки Android Studio
Я не знаю, из-за ли это системы сборки Gradle (держу пари), но я скажу вам то, что я понял до сих пор.
Обновление 4: 2014/09/11 Добавлено Шпаргалка для BuildTypes
, Flavors
и Variants
(я , наконец , чувствовать себя уверенно , чтобы написать это: D)
Update 3: 2014/09/11 Обновлены сравнения рабочих областей и проектов , чтобы быть точным
Update 2: 2014/04/17 Добавлены дополнительные сведения в структуру проекта AS.
Обновление 1: 2013/07/29 Добавлена структура проекта IntelliJ.
Структура проекта IntelliJ (показанная в конце) предназначена для IntelliJ с подключаемым модулем Android. Однако в Android Studio структура проекта разделена следующим образом:
Структура: проекты и модули
модуль в Android Studio похож на проект в Eclipse
проект в Android Studio похож на рабочее пространство в Eclipse (точнее, рабочее пространство с взаимозависимыми проектами)
Из документации (Android Studio основана на Intellij IDEA):
Что бы вы ни делали в IntelliJ IDEA, вы делаете это в контексте проекта. Проект - это организационная единица, которая представляет собой законченное программное решение.
Готовый продукт может быть разбит на серию дискретных, изолированных модулей, но это определение проекта, которое объединяет их и связывает в единое целое.
Для Android это означает один проект на приложение и один модуль на библиотеку и каждое тестовое приложение.
Если вы попытаетесь создать несколько приложений в одном проекте, возникнет несколько проблем. Это возможно, но если вы попробуете (как я), вы увидите, что почти все предназначено для работы с одним приложением для каждого проекта.
Например, есть возможность «перестроить проект», что не имеет смысла для нескольких приложений, многие другие настройки проекта будут бесполезны, а встроенная система VCS не очень хороша, когда у вас есть несколько репозиториев.
Структура: структура папки
Папки верхнего уровня
1. Основной проект
Это будет весь контекст проекта ( Eclipse Land: как ваше рабочее пространство, но ограничено тем, что имеет отношение к вашему проекту). Пример: HelloWorldProject
если имя приложения, которое вы указали, былоHelloWorld
2. .idea
Здесь Android Studio (AS) хранит метаданные конкретного проекта. ( Eclipse Land: project.properties
файл)
3. Модуль проекта
Это реальный проект. пример: HelloWorld
если имя вашего приложения, которое вы указали, было HelloWorld
4. градиент
Это то место, где находится оболочка jar системы сборки gradle, т.е. эта jar - это то, как AS взаимодействует с gradle, установленным в Windows (ОС в моем случае).
5. Внешние библиотеки
На самом деле это не папка, а место, где отображаются ссылки на библиотеки ( Eclipse Land: Ссылки на библиотеки). Здесь показана целевая платформа и т. Д.
[ Боковое примечание: здесь многие из нас в Eclipse Land использовали для удаления ссылочных библиотек и исправления свойств проекта, чтобы исправить ошибки ссылок, помните?]
Папка проекта в деталях
Это номер 3 в приведенном выше списке. Имеет следующие поддиректории
1. построить
Здесь есть все выходные данные make
процесса, то есть classes.dex, скомпилированные классы и ресурсы и т. Д.
В графическом интерфейсе Android Studio отображается только несколько папок. Важная часть заключается в том, что ваш R.java находится здесь, вbuild/source/<flavor>/r/<build type(optional)>/<package>/R.java
2. библиотеки
Это стандартные библиотеки папки , которые вы видите в затмении земле тоже
3. src
Здесь вы видите только java
и res
папки , которые соответствуют в src
папку и res
папку в Eclipse , Земля . Это очень приветствуемое упрощение ИМХО.
Примечание по модулям:
Модули похожи на проекты Eclipse Land . Здесь идея состоит в том, что у вас есть один проект приложения (модуль № 3 в списке выше) и несколько проектов библиотеки (как отдельные модули в папке глобального проекта (№ 1 в списке выше)), от которых зависит проект приложения. Как эти библиотечные проекты можно повторно использовать в других приложениях, я до сих пор не выяснил.
[ Примечание: вся реорганизация имеет некоторые преимущества, такие как упрощение папки src, но так много сложностей. Сложности в основном связаны с ОЧЕНЬ тонкой документацией по этому новому макету проекта.]
Новая система сборки
Руководство пользователя новой системы сборки
Объяснение ароматов, типов сборки и т. Д. - О чем такой шум?
CheatSheet для ароматов и типов сборки
BuildType: debug
и release
являются buildTypes
доступны по умолчанию на всех проектах. Они предназначены для строительства / компиляции того же кода для генерации различных файлов APK. Например, в release
APK-файлах вы захотите запустить proguard (для обфускации), подписать его своим ключом (в отличие от ключа отладки), запустить оптимизацию (возможно, с помощью proguard или других инструментов), использовать немного другое packageNames
(мы используем com.company.product
для release
и com.company.product.debug
для debug
), и т. д. Мы также используем флаг отладки ( BuildConfig.DEBUG
), чтобы отключить запись в logcat (поскольку это замедляет работу приложения) при release
сборках. Это обеспечивает более быструю debug
сборку во время разработки, а также оптимизирует release
сборку для размещения в игровом магазине.
Вкус продукта: нет доступных по умолчанию ароматов (или, если быть точным, вкус по умолчанию пустой / безымянный). Flavors
может быть бесплатная версия или платная версия, где у них ДРУГОЙ КОД . Они используют один и тот же Main
код, но разные версии (или не версии) нескольких файлов или ресурсов исходного кода.
BuildVariant: A buildVariant
- это то, чему фактически соответствует сгенерированный APK. Называются они так (по порядку) Product Flavor
+ Build Type
=Build Variant
.
Пример 1: если у вас есть free
и paid
как два вкуса. Вы можете получить следующие варианты сборки:
Бесплатная - отладка
Бесплатная -
Платная версия -
Платная отладка - выпуск
Итак, это 4 возможные конфигурации APK. Несколько конфигураций не могут иметь смысл в конкретном проекте, но они являются доступны.
Пример 2: (для новых проектов / без вариантов) У вас есть 2 buildVariants
или APK, так как вариант по умолчанию безымянный / пустой:
отладочная
версия
Папка .idea (1) содержит несколько подпапок, в основном с внутренней информацией IntelliJ IDEA.
Папка src (2) содержит исходный код файла MyActivity.java (3), который реализует функциональность вашего приложения. Файл принадлежит пакету com.example.
Папка res (4) содержит различные визуальные ресурсы.
Файл layout / main.xml (5) определяет внешний вид приложения, состоящего из ресурсов различных типов.
Папка значений (6) предназначена для хранения файлов .xml, описывающих ресурсы разных типов. В настоящее время в папке находится файл strings.xml с определениями ресурсов String. Как вы увидите в разделе «Добавление цвета», папка макета также может содержать, например, дескриптор цветов.
Выдвижная папка (7) содержит изображения.
Папка gen (8) содержит файл R.java (9), который связывает визуальные ресурсы и исходный код Java. Как вы увидите из разделов ниже, IntelliJ IDEA поддерживает тесную интеграцию между статическими ресурсами и R.java. Как только какие-либо ресурсы добавляются или удаляются, соответствующие классы и поля классов в R.java автоматически создаются или удаляются соответственно. Файл R.java также принадлежит пакету com.example.