Ответ 1
Тайна: Структура проекта Android и система сборки
Я не знаю, связано ли это с системой сборки Gradle (я бы сделал ставку), но я расскажу вам, что я понял до сих пор.
Обновление 4: 2014/09/11 Добавлен Cheat Sheet для BuildTypes, Flavors и Variants (я, наконец, уверен, что напишу следующее: D )
Обновление 3: 2014/09/11 Обновленные рабочие пространства и проекты для сравнения
Обновление 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. Модуль проекта
Это фактический проект. ex: HelloWorld, если вы указали свое имя приложения HelloWorld
4. gradle
Здесь используется фреймворк java системы сборки Gradle, т.е. этот jar - это то, как AS общается с Gradle, установленным в Windows (ОС в моем случае).
5. Внешние библиотеки
Это не папка, а место, где показаны ссылочные библиотеки (Eclipse Land:). Здесь, где показана целевая платформа и т.д.
[ Боковое примечание: Это, когда многие из нас в Eclipse Land использовали для удаления библиотек, на которые ссылаются, и Fix Project Properties, чтобы исправить опорные ошибки, помните?]
Подробная папка проекта
Это номер № 3 в приведенном выше списке. Имеет следующие подразделы
1. построить
У этого есть весь полный вывод процесса make, то есть classes.dex, скомпилированные классы и ресурсы и т.д.
В графическом интерфейсе Android Studio отображаются только несколько папок. Важная часть состоит в том, что ваш R.java находится здесь под build/source/<flavor>/r/<build type(optional)>/<package>/R.java
2. LIBS
Это стандартная папка libs, которую вы видите в Eclipse land тоже
3. ЦСИ
Здесь вы видите только папку java и res, которая соответствует папке src и папке res в Eclipse Land. Это очень приветствуемое упрощение IMHO.
Примечание по модулям:
Модули похожи на проекты Eclipse Land. Здесь идея состоит в том, что у вас есть один проект приложения (модуль № 3 в списке выше) и несколько проектов библиотек (в виде отдельных модулей в папке глобального проекта (№1 в приведенном выше списке)), от которого зависит проект приложения. Как эти проекты библиотеки могут быть повторно использованы в других приложениях, я до сих пор не обнаружил.
[ Боковое примечание:Вся реорганизация имеет некоторые преимущества, такие как упрощения в папке src, но так много осложнений. Усложнения в основном объясняются ОЧЕНЬ ОЧЕНЬ тонкой документацией по этой новой компоновке проекта.]
Новая система сборки
Руководство пользователя для новой системы сборки
Объяснение вкусов и buildTypes и т.д. - Что такое hullabaloo?
CheatSheet для ароматизаторов и buildTypes
BuildType: debug и release доступны BuildTypes по умолчанию для всех проектов. Они предназначены для создания/компиляции SAME CODE для создания разных 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, так как по умолчанию вкус безымянный/пустой:
отладки
релиз
Сравните это с Intellij Project Structure, если это помогает:
Папка .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.
