У чому різниця між завданнями збірки gradle та збірки gradle?

83

Якщо я не помиляюся gradle assemble, працює gradle assembleDebugі gradle assembleRelease, але я вважаю, що gradle buildробить те саме, то чим вони між собою відрізняються?

android  android-gradle-plugin 
— Покірний студент
джерело
2
Коли я запускаю, buildReleaseя не отримую .apkфайли, а лише файли журналів. Тим НЕ менше, при роботі assembleRelease, я робити отримати .apkфайли. Непарні
— Джошуа Пінтер

Відповіді:

101

Assemble створить ваші артефакти, а build - збере ваші артефакти за допомогою додаткових перевірок.

buildзалежить від assemble, тому buildє свого роду надмножиноюassemble

Ви можете поглянути на завдання, які будуть виконані за допомогою --dry-runпрапора. напр

gradlew build --dry-run

Ви побачите, що крім assembleтакож lintі testбуде виконано.

— Девід Меденяк
джерело
3
Дякую за відповідь. Я вважаю, що біг із --dry-run - це спосіб мати подальші нестабільні ситуації
— Покірний студент
Що ви маєте на увазі під словом "додаткові перевірки"
— Ajay S
3
@AjayS lintandtest
— David Medenjak
2
З мого останнього досвіду, ця відповідь неправильна. Коли я запускаю assembleRelease, я отримую вихідний apk. Коли я запускаю buildRelease, apk не генерується. Крім того, я запускаю обидва завдання за допомогою --dry-run, як було запропоновано вище, і здається, що збірка не працює збірка внизу.
— rideronthestorm
Цікаво, чи реалізує плагін Android збірку / збірку інакше, ніж плагін Java. Я щойно розмістив відповідь на це запитання, що показує дві суперечливі схеми. Але один обговорює Android, а інший Java.
— Колін Д Беннетт,
16

Від gradle tasks --all:

Build tasks
-----------
assemble - Assembles the outputs of this project.
build - Assembles and tests this project.

buildє ефективно assemble+ check(і checkє test+ будь-якими завданнями зв’язування).

— Лоуренс Гонсалвес
джерело
13

Це правда, що, згідно з gradle tasksним, виглядає як buildнадмножина assemble, включаючи тести. Але (!) З мого короткого досвіду справді здається, що це не так.

Тож я запустив ці 2 команди в командному рядку, використовуючи оболонку gradle з прапором --scan після кожного запуску чистої роботи. Ось порівняння:

  1. Бажані вбудовані файли:
    • Після запуску assembleDebugя отримав усі вбудовані файли, які хотів - *.apkі *.aarфайли.
    • Після запуску buildDebugя не мав жодного з цих файлів.
  2. Кількість виконаних завдань відповідно до сканувань:
    • assembleDebug - 109 завдань
    • buildDebug - 91 завдання
  3. Кількість залежностей за даними сканування:
    • assembleDebug - 172 з 20 конфігурацій
    • buildDebug - 104 з 18 конфігурацій
    • Здається, причина, по якій вони відрізняються, полягає в тому, що в assembleDebug2 з 3 моїх підпроектів (які є бібліотеками Java, а не додатком) є ще одна конфігурація, яка називається lintClassPath. Ця конфігурація відсутня в buildDebug.
  4. Ще один момент, який слід згадати, полягає в тому, що коли я шукав у списку завдань, здавалося, buildDebugщо не викликав assembleDebugзавдання і assembleDebugне викликав buildDebugзавдання.
  5. І останнє цікаве, що слід згадати в цьому контексті, це те, що коли я запускав збірку з Android Studio ( Build -> Make Project), я бачу під час сканування, що команда, яка насправді виконувалася, була assembleDebug. Точніше, він пробіг :app:assembleDebug.

Як бачите, я сам насправді не розумію відмінностей, але це я дізнався. Якщо хтось може пояснити це мені та іншим користувачам, які читають тут, це може бути чудово :) Дякую!

— Дорон Го
джерело
9

Існує суперечлива інформація про те, чи buildмає це залежати assemble.

З одного боку, Розуміння Gradle: Життєвий цикл збірки показує графік залежностей завдань, звідки buildі assembleє незалежними: Направлений ациклічний графік для завдань плагіна Java з книги Gradle Recipes для Android.

На відміну від цього, посібник користувача Gradle для плагіна Java показує, що buildзалежить assemble, принаймні, для проектів Java:

Плагін Java - завдання

Це суперечить графіку "Розуміння Gradle". То, можливо, плагін Android реалізує завдання збірки / збірки не так, як плагін Java? Або ця поведінка змінилася в якійсь версії Gradle.

— Колін Д Беннет
джерело
збірка залежить як від перевірки, так і від збірки, як показано в коді: github.com/gradle/gradle/blob/…
— Генрік Нордвік
0

Assemble створить ваші артефакти, а build - збере ваші артефакти за допомогою додаткових перевірок.

Які додаткові перевірки? Я запускаю завдання, щоб вам не потрібно було:

:app:lint SKIPPED       
:app:bundleDebugClasses SKIPPED     
:app:kaptGenerateStubsDebugUnitTestKotlin SKIPPED       
:app:kaptDebugUnitTestKotlin SKIPPED        
:app:compileDebugUnitTestKotlin SKIPPED     
:app:preDebugUnitTestBuild SKIPPED      
:app:javaPreCompileDebugUnitTest SKIPPED        
:app:compileDebugUnitTestJavaWithJavac SKIPPED      
:app:processDebugUnitTestJavaRes SKIPPED        
:app:testDebugUnitTest SKIPPED      
:app:bundleReleaseClasses SKIPPED       
:app:kaptGenerateStubsReleaseUnitTestKotlin SKIPPED     
:app:kaptReleaseUnitTestKotlin SKIPPED      
:app:compileReleaseUnitTestKotlin SKIPPED       
:app:preReleaseUnitTestBuild SKIPPED        
:app:javaPreCompileReleaseUnitTest SKIPPED      
:app:compileReleaseUnitTestJavaWithJavac SKIPPED        
:app:processReleaseUnitTestJavaRes SKIPPED      
:app:testReleaseUnitTest SKIPPED        
:app:test SKIPPED       
:app:check SKIPPED      
:app:build SKIPPED

Як бачите, buildвиконує більше завдань, ніж assemble. Мовляв lint, testі checkзавдання.

Повні завдання можна переглянути тут . Оригінальний текст є buildзавданням, тоді як змінений текст єassemble завдання.

Використовуваний проект: Android Sunflower GitHub

— альдок
джерело
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.