Ответ 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.

Ответ 2

Android Studio: приложение \build\source\r\debug\com.example.app\R.java

Почему эти пути различны? Почему мой R.java находится в папке отладки в Android Studio? Это может привести к некоторым ошибкам на раннем этапе, и если кто-нибудь сможет понять эти различия, я буду благодарен им.

Проще говоря, Android Studio настроен на создание отладки Тип сборки в вашей системе.

Eclipse/ADT предназначен для поддержки единой сборки за раз (из того, что я могу сказать). Одна из основных целей новой системы сборки (из руководства пользователя):

Make it easy to create several variants of an application, 
either for multi-apk distribution or for different flavors of an application

Итак, где, поскольку Eclipse/ADT может генерировать один файл R.java, Android Studio поддерживает несколько. Сгенерированный R.java находится в папке debug, потому что по умолчанию новая система сборки поддерживает debug и release типы сборки с места в карьер. Если вы изменили свой вариант сборки (кнопка, нижний левый угол AS), чтобы освободить AS, вы создадите R.java в каталоге release.

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

Наш проект поддерживает 4 варианта с двумя типами сборки (отладка и выпуск), поддерживая в общей сложности 8 различных комбинаций APK. И каждая из этих комбинаций имеет несколько разные конфигурации, поэтому эта система сборки действительно сработала для нас. Моя студия Android установлена ​​на другой машине, но если память правильно служит мне, файл R.java существует в build/source/<flavor>/r/<build type>/package/R.java. Когда наш сервер CI создает файлы APK, он использует каждый из этих файлов R.java для создания отдельных пакетов.

Ответ 3

Google Отмените поддержку для Android Developer Tools (ADT) в Eclipse заканчивается в нашем объявлении. Вы должны мигрировать ваши проекты разработки приложений в Android Studio как можно скорее. Дополнительные сведения о переходе на Android Studio см. В разделе Миграция для Android Studio.

Лучше всего для Android-разработчика для Android Studio только для всей будущей поддержки Android M ---

Ответ 4

Для android Studio 3.0.1 и выбраны все функции:

• Android O последний
• Android Auto
• Android-вещи
• Одежда для Android
• Android TV
• Поддержка C++
• Поддержка Котлина

Структура в версии 3.0.1 не выглядит совсем как все остальные ответы.

Недавняя структура отображается в 2018 году, Android Studio 3.0.1 01/2018.

Newbie kinda нашел что-то похожее на полезную в подкаталоге функции:

Обновите свой Android Studio 3.0.1 01_2018:

ToolTip: