Внедрение конфигурации Gradle в против API-интерфейс


Я пытаюсь понять, в чем разница между api и implementation конфигурация при построении моих зависимостей.
В документации говорится, что implementation имеет лучшее время сборки, но, увидев этот комментарий в подобном вопросе, я задался вопросом, правда ли это.
Поскольку я не эксперт в gradle, я надеюсь, что кто-то может помочь. Я читал документация уже, но мне было интересно о простых для понимания объяснений.

2 72

2 ответа:

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

ш compile ключевое слово устарело в пользу нового api и implementation ключевые слова.

я не буду объяснять api, потому что это то же самое, что использовать старые compile, так что если вы замените все compile С api все будет работать как всегда.

понять implementation ключевое слово нам нужно образец.

пример

у нас есть библиотека под названием MyLibrary где внутренне мы используем другую библиотеку под названием InternalLibrary. Что-то вроде этого:

//internal library module
public class InternalLibrary {
    public static String giveMeAString(){
        return "hello";
    }
}

//my library module
public class MyLibrary {
    public String myString(){
        return InternalLibrary.giveMeAString();
    }
}

The build.gradle зависимости MyLibrary вот так:

dependencies {
    api project(':InternalLibrary')
}

теперь в вашем коде вы хотите использовать MyLibrary так что вы должны иметь build.gradle в зависимости

dependencies {
    api project(':MyLibrary')
}

в коде вашего приложения, с api ключевое слово (или с помощью старый compile) вы можете получить доступ к обоим MyLibrary и InternalLibrary.

//so you can access the library (as it should)
MyLibrary myLib = new MyLibrary();
System.out.println(myLib.myString());

//but you can access the internal library too (and you shouldn't)
System.out.println(InternalLibrary.giveMeAString());

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

чтобы предотвратить это, Gradle создал новый implementation ключевое слово, так что теперь, если вы переключитесь api до implementation в своем MyLibrary

dependencies {
    implementation project(':InternalLibrary')
}

и приложения build.gradle

dependencies {
    implementation project(':MyLibrary')
}

вы не сможете назвать InternalLibrary.giveMeAString() в вашем коде приложения больше. Хотя если MyLibrary использует api ключевое слово для импорта InternalLibrary, в вашем приложении вы сможете позвонить InternalLibrary.giveMeAString() без проблем, самостоятельно, если вы используете api или implementation добавить MyLibrary к вашему приложению.

используя такую стратегию бокса, плагин Android Gradle знает, что если вы редактируете что-то в InternalLibrary это вызовет перекомпиляцию MyLibrary только. Это не потребует перекомпиляции всего приложения, потому что у вас нет доступа к InternalLibrary. Этот механизм, когда у вас есть много вложенных зависимостей, может значительно ускорить сборку.(смотрите видео, связанное в конце для полного понимания этого)

выводы

  • при переключении на новый Android Gradle плагин 3.X. X, вы должны заменить все ваши compile С implementation ключевое слово (1*). Попробуйте скомпилировать и протестировать приложение. Если все в порядке оставьте код как если у вас есть проблемы, вы, вероятно, что-то не так с вашими зависимостями или вы использовали что-то, что теперь является частным и не более доступным. предложение инженера плагина Android Gradle Джерома Дочеза (1)*)

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

ссылки (Это то же самое видео, разделенное для экономии времени)

Google I / O 2017 - Как ускорить сборки Gradle (полное видео)

Google I / O 2017 - Как ускорить сборки Gradle (новый плагин GRADLE 3.0.0 только часть)

Google I / O 2017 - Как ускорить сборки Gradle (ссылка на 1*)

документация для Android

мне нравится думать о api иждивенцев общественные (видно по другим модулям) в то время как implementation иждивенцев частная (видно только по этому модулю).

обратите внимание, что в отличие от public/private переменные и методы, api/implementation зависимости не применяются средой выполнения. Это просто оптимизация времени сборки, что позволяет Gradle чтобы узнать, какие модули необходимо перекомпилировать, когда одна из зависимостей изменяет свой API.