В чем разница между реализацией, api и компиляцией в Gradle?

tl; dr

Просто замените:

• compile с implementation (если вам не нужна транзитивность) или api (если вам нужна транзитивность)
• testCompile с testImplementation
• debugCompile с debugImplementation
• androidTestCompile с androidTestImplementation
• compileOnly все еще действителен. Он был добавлен в 3.0 для замены предоставленного, а не компилированного. (provided введен, когда у Gradle не было имени конфигурации для этого варианта использования и он назван в соответствии с предоставленной областью Maven.)

Это одно из критических изменений, появившихся в подключаемом модуле Android Gradle 3.0, о котором Google объявил на конференции IO17.

Конфигурация compile теперь устарела и должна быть заменена на implementation или api

Из документации Gradle:

dependencies {
    api 'commons-httpclient:commons-httpclient:3.1'
    implementation 'org.apache.commons:commons-lang3:3.5'
}

Зависимости, появляющиеся в api конфигурациях, будут транзитивно открыты потребителям библиотеки и, как таковые, появятся в пути к классам компиляции потребителей.

С другой стороны, зависимости, обнаруженные в конфигурации implementation, не будут открыты потребителям и, следовательно, не попадут в путь к классам компиляции потребителей. Это дает несколько преимуществ:

• зависимости больше не просачиваются в путь к классам компиляции потребителей, поэтому вы никогда случайно не будете зависеть от транзитивной зависимости
• более быстрая компиляция благодаря уменьшенному размеру пути к классам
• меньше перекомпиляций при изменении зависимостей реализации: потребители не нуждаются в перекомпиляции
• более чистая публикация: при использовании в сочетании с новым плагином maven-publish библиотеки Java создают файлы POM, которые точно различают то, что требуется для компиляции с библиотекой, и то, что требуется для использования библиотеки во время выполнения (другими словами, не смешайте то, что необходимо для компиляции самой библиотеки, и то, что необходимо для компиляции с библиотекой).

Конфигурация компиляции все еще существует, но ее не следует использовать, поскольку она не дает гарантий, которые предоставляют конфигурации api и implementation.

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

Этот ответ продемонстрирует разницу между implementation, api и compile в проекте.

Допустим, у меня есть проект с тремя модулями Gradle:

• app (приложение для Android)
• myandroidlibrary (библиотека Android)
• myjavalibrary (библиотека Java)

app имеет myandroidlibrary в качестве зависимостей. myandroidlibrary имеет myjavalibrary в качестве зависимостей.

myjavalibrary имеет MySecret класс

public class MySecret {

    public static String getSecret() {
        return "Money";
    }
}

myandroidlibrary имеет MyAndroidComponent класс, который управляет значением из класса MySecret.

public class MyAndroidComponent {

    private static String component = MySecret.getSecret();

    public static String getComponent() {
        return "My component: " + component;
    }    
}

Наконец, app интересует только значение из myandroidlibrary

TextView tvHelloWorld = findViewById(R.id.tv_hello_world);
tvHelloWorld.setText(MyAndroidComponent.getComponent());

Теперь поговорим о зависимостях ...

app нужно использовать :myandroidlibrary, поэтому в app build.gradle используйте implementation.

(Примечание: вы также можете использовать api / compile. Но задумайтесь на мгновение.)

dependencies {
    implementation project(':myandroidlibrary')      
}

Как вы думаете, как должен выглядеть myandroidlibrary build.gradle? Какой объем нам следует использовать?

У нас есть три варианта:

dependencies {
    // Option #1
    implementation project(':myjavalibrary') 
    // Option #2
    compile project(':myjavalibrary')      
    // Option #3
    api project(':myjavalibrary')           
}

В чем разница между ними и что мне следует использовать?

Компиляция или API (вариант №2 или №3)

Если вы используете compile или api. Наше приложение для Android теперь может получить доступ к myandroidcomponent зависимости, которая является MySecret классом.

TextView textView = findViewById(R.id.text_view);
textView.setText(MyAndroidComponent.getComponent());
// You can access MySecret
textView.setText(MySecret.getSecret());

Реализация (вариант №1)

Если вы используете конфигурацию implementation, MySecret не отображается.

TextView textView = findViewById(R.id.text_view);
textView.setText(MyAndroidComponent.getComponent());
// You can NOT access MySecret
textView.setText(MySecret.getSecret()); // Won't even compile

Итак, какую конфигурацию выбрать? Это действительно зависит от ваших требований.

Если вы хотите раскрыть зависимости, используйте api или compile.

Если вы не хотите раскрывать зависимости (скрывая свой внутренний модуль), используйте implementation.

Примечание.

Это всего лишь суть конфигураций Gradle, см. Таблицу 49.1. Плагин библиотеки Java - конфигурации, используемые для объявления зависимостей для более подробного объяснения.

Образец проекта для этого ответа доступен на https://github.com/aldoKelvianto/ImplementationVsCompile

Конфигурация Compile устарела и должна быть заменена на implementation или api.

Вы можете прочитать документацию в разделе разделение API и реализации .

Краткая часть -

Ключевое различие между стандартным подключаемым модулем Java и подключаемым модулем библиотеки Java состоит в том, что последний представляет концепцию API, доступного потребителям. Библиотека - это компонент Java, предназначенный для использования другими компонентами. Это очень распространенный вариант использования в многопроектных сборках, но также и при наличии внешних зависимостей.

Плагин предоставляет две конфигурации, которые можно использовать для объявления зависимостей: API и реализация. Конфигурация api должна использоваться для объявления зависимостей, которые экспортируются библиотечным API, тогда как конфигурация реализации должна использоваться для объявления зависимостей, которые являются внутренними для компонента.

Для дальнейшего объяснения обратитесь к этому изображению.

Краткое решение:

Лучше всего заменить все compile зависимости зависимостями implementation. И только в случае утечки интерфейса модуля следует использовать api. Это должно привести к гораздо меньшей перекомпиляции.

 dependencies {
         implementation fileTree(dir: 'libs', include: ['*.jar'])
 
         implementation 'com.android.support:appcompat-v7:25.4.0'
         implementation 'com.android.support.constraint:constraint-layout:1.0.2'
         // …
 
         testImplementation 'junit:junit:4.12'
         androidTestImplementation('com.android.support.test.espresso:espresso-core:2.2.2', {
             exclude group: 'com.android.support', module: 'support-annotations'
         })
 }

Объясните подробнее:

До Android Gradle plugin 3.0: у нас была большая проблема: одно изменение кода приводило к перекомпиляции всех модулей. Основная причина этого в том, что Gradle не знает, пропускаете ли вы интерфейс одного модуля через другой или нет.

После подключаемого модуля Android Gradle 3.0: последний подключаемый модуль Android Gradle теперь требует, чтобы вы явно указали, нет ли утечки интерфейса модуля. Исходя из этого, он может сделать правильный выбор, что следует перекомпилировать.

Таким образом, зависимость compile устарела и заменена двумя новыми:

• api: вы пропускаете интерфейс этого модуля через свой собственный интерфейс, что означает то же самое, что и старая compile зависимость

• implementation: вы используете этот модуль только для внутренних целей и не пропускаете его через свой интерфейс.

Итак, теперь вы можете явно указать Gradle перекомпилировать модуль, если интерфейс используемого модуля изменится или нет.

Любезно предоставлено блогом Йеруна Молса

Конфигурация зависимости Gradle

Gradle 3.0 внес следующие изменения:

• compile -> api

  api ключевое слово совпадает с устаревшим compile, которое раскрывает эту зависимость для всех уровней.

• compile -> implementation

  Это предпочтительный способ, потому что имеет ряд преимуществ. implementation отображать зависимость только для на один уровень выше во время сборки (зависимость доступна во время выполнения). В результате вы получаете более быструю сборку (нет необходимости перекомпилировать потребителей, которые выше, чем на 1 уровень)

• provided -> compileOnly

  Эта зависимость доступна только во время компиляции (зависимость недоступна во время выполнения). Эта зависимость не может быть транзитивной и быть .aar. Его можно использовать с процессором аннотации времени компиляции ^[About] и позволяет сократить окончательный выходной файл

• compile -> annotationProcessor

  Очень похоже на compileOnly, но также гарантирует, что транзитивная зависимость не видна для потребителя.

• apk -> runtimeOnly

  Зависимость недоступна во время компиляции, но доступна во время выполнения.

[тип зависимости POM]

Краткое различие в терминологии непрофессионала:

• Если вы работаете над интерфейсом или модулем, который обеспечивает поддержку других модулей, раскрывая элементы указанной зависимости, вам следует использовать api.
• Если вы создаете приложение или модуль, который будет реализовывать или использовать указанную зависимость внутри, используйте «реализация».
• 'compile' работает так же, как 'api', однако, если вы только реализуете или используете какую-либо библиотеку, 'реализация' будет работать лучше и сэкономит ваши ресурсы.

прочтите ответ @aldok для исчерпывающего примера.

Начиная с версии 5.6.3 Gradle документация предоставляет простые практические правила. чтобы определить, следует ли заменить старую compile зависимость (или новую) зависимостью implementation или api:

• По возможности предпочитайте implementation конфигурацию api

Это избавляет от зависимостей пути к классам компиляции потребителя. Кроме того, потребители немедленно не смогут скомпилировать, если какие-либо типы реализации случайно попадут в общедоступный API.

Итак, когда следует использовать конфигурацию api? Зависимость API - это зависимость, которая содержит по крайней мере один тип, представленный в двоичном интерфейсе библиотеки, часто называемый ее ABI (двоичный интерфейс приложения). Это включает, но не ограничивается:

• типы, используемые в суперклассах или интерфейсах
• типы, используемые в параметрах общедоступных методов, включая общие типы параметров (где общедоступные - это то, что видно компиляторам. Т.е., общедоступные, защищенные и закрытые члены пакета в мире Java)
• типы, используемые в публичных полях
• общедоступные типы аннотаций

Напротив, любой тип, который используется в следующем списке, не имеет отношения к ABI и, следовательно, должен быть объявлен как implementation зависимость:

• типы, используемые исключительно в телах методов
• типы, используемые исключительно в закрытых членах
• типы, находящиеся исключительно во внутренних классах (будущие версии Gradle позволят вам объявлять, какие пакеты принадлежат общедоступному API)

Несколько заметок перед тем, как продолжить; compile устарел, и в документации указано, что вы должны использовать реализацию, потому что компиляция будет удалена в Gradle версии 7.0. Если вы запустите свою сборку Gradle с --warning-mode all, вы увидите следующее сообщение;

Конфигурация компиляции устарела для объявления зависимостей. Это не сработает с ошибкой в ​​Gradle 7.0. Вместо этого используйте конфигурацию реализации.

Просто взглянув на изображение со страниц справки, можно понять, что это такое.

Итак, у вас есть синие прямоугольники compileClasspath и runtimeClassPath.
compileClasspath - это то, что требуется для успешной сборки при запуске gradle build. Библиотеки, которые будут присутствовать в пути к классам при компиляции, будут всеми библиотеками, которые настроены в вашей сборке gradle с использованием либо compileOnly, либо implementation.

Затем у нас есть runtimeClasspath, и это все пакеты, которые вы добавили с помощью implementation или runtimeOnly. Все эти библиотеки будут добавлены в окончательный файл сборки, который вы развернете на сервере.

Как вы также видите на изображении, если вы хотите, чтобы обе библиотеки использовались для компиляции, но вы также хотите, чтобы она была добавлена ​​в файл сборки, следует использовать implementation.

Примером runtimeOnly может быть драйвер базы данных.
Примером compileOnly может быть servlet-api.
Примером implementation может быть spring-core.

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

• api: следует использовать очень осторожно, поскольку он пропускает путь к классам компиляции потребителя, поэтому неправильное использование api может привести к загрязнению зависимостей.

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

• runtimeOnly: когда мы хотим изменить или поменять местами поведение библиотеки во время выполнения (в окончательной сборке).

Я создал сообщение с глубокое понимание каждого из них с помощью Рабочий пример: исходный код

https://medium.com/@gauraw.negi/how-gradle-dependency-configurations-work-underhood-e934906752e5