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

После обновления до Android Studio 3.0 и создания нового проекта я заметил, что в build.gradle существует новый способ добавления новых зависимостей вместо compile implementation вместо testCompiletestImplementation .

пример:

  implementation 'com.android.support:appcompat-v7:25.0.0' testImplementation 'junit:junit:4.12' 

вместо

  compile 'com.android.support:appcompat-v7:25.0.0' testCompile 'junit:junit:4.12' 

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

Это одна из самых неожиданных изменений, произошедших с gradle: 3.0, которые Google анонсировал на уровне IO17: 3.0

конфигурация 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 и реализации.


ТЛ; др

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

  • compile с implementation
  • testCompile with testImplementation
  • debugCompile с debugImplementation
  • androidTestCompile с androidTestImplementation

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

Вы можете прочитать документы на странице https://docs.gradle.org/current/userguide/java_library_plugin.html#sec:java_library_separation .

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

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

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

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

Краткое описание:

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


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

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

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

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

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

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

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

Предоставлено блог Jeroen Mols

  • Android Studio Execution не удалось выполнить задачу compilefreeDebugKotlin
  • AndroidStudio ExternalSystemException с kotlin 0.12.213
  • Android Plugin 2.2.0-alpha1 не скомпилируется с Kotlin
  • Применение плагина «kotlin-android» в мгновенном приложении приводит к тому, что «null не может быть применено к ненулевому типу com.android.build.gradleBasePlugin»
  • запустить HelloAndroid от градиента?
  • Студия Android 3: устаревшая Kotlin Runtime
  • Kotlin: Как я могу позволить Android Studio реализовать интерфейс в нижней части класса
  • Использование функции замены в KOTLIN
  • Android Studio демонстрирует предупреждение зависимостей Kotlin после второй сборки
  • Проблема с Kotlin после Android Studio была обновлена ​​до 0,6
  • Тестирование Kotlin в студии android
  • Interesting Posts

    как использовать весенние аннотации, такие как @Autowired или @Value в kotlin для примитивных типов?

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

    Могу ли я запустить Android Studio 3.0 без Kotlin?

    Kotlin java абстрактный класс IllegalAccessError

    Выбрать свойство из каждого объекта в списке

    RxKotlin flattenAsObservable (): несоответствие типа с ссылкой на метод

    Глобальная функция расширения в котлине

    LMAX Disruptor с Kotlin: нельзя использовать лямбда?

    Когда лямбда-параметры должны быть noinline в Котлин?

    Запуск Котлинского кодекса на платформе SBT / Play?

    Есть ли способ показать все функции расширения данного класса Kotlin в Intellij IDE?

    Android Kotlin Gson Slow Json Deserialization

    MissingMethodInvocationException тестирование открытого класса в Котлине

    Kotlin: Неопределенность разрешения перегрузки в Eclipse, но не в IntelliJ

    Android – как реализовать несколько ViewHolder для макета заголовка другого для макета модели в адаптере Firestore RecyclerView

    Давайте будем гением компьютера.