Co to jest "implementacja" w zależnościach Kotlin Gradle?

Question

Używam Android Studio 3.0 Preview, aby rozpocząć nowy projekt Kotlin. Podczas próby dodania zależności w build.gradle widziałem zakres implementation zamiast zwykłego compile.

androidTestImplementation('com.android.support.test.espresso:espresso-core:2.2.2', { 
    exclude group: 'com.android.support', module: 'support-annotations' 
}) 
implementation 'com.android.support:appcompat-v7:25.3.1' 
testImplementation 'junit:junit:4.12' 

Jest też androidTestImplementation i testImplementation zakres.

Na koniec dodam compile, aby dodać zależności od strony trzeciej i to działa.

compile 'io.reactivex.rxjava2:rxandroid:2.0.1' 

więc moje pytania są ..

• Co jest implementation, androidTestImplementation i testImplementation zakres?
• Czy jest inny niż compile, testCompile i androidTestCompile?
• Którego powinienem użyć do mojego projektu Kotlin?

Edytuj: Moja zła, to pytanie nie jest specyficzne dla Kotlin. To nowy Android Gradle Plugin configuration.

Answer 1

To nie jest specyficzne dla Kotlin, ale ma do czynienia z nową wtyczką Gradle dla Androida.

compile, provided i apk są teraz przestarzałe.
Użyj implementation lub api zamiast compile, compileOnly zamiast provided i runtimeOnly zamiast apk.

Powodem tego jest przyspieszenie budowania wielomodułowego. Biorąc pod uwagę moduł A, który zależy od modułu B, który z kolei zależy od modułu C, zmiana w module C spowodowałaby również ponowną kompilację modułu A. Jeśli A nie używa bezpośrednio C, nie ma potrzeby, aby A było rekompilowane po zmianie C.

Konfiguracja implementation zapewnia dokładnie w ten sposób: jeśli podasz implementation project(':C') w B, nie można uzyskać dostępu C z A i uniknąć niepotrzebnych budowania modułów. W dużym projekcie wielomodułowym może to zaoszczędzić sporo czasu.

Aby uzyskać więcej informacji, patrz Migrate to the new Gradle plugin.

Answer 2

Wcześniejsza wersja gradle v3.0.0-alpha1 używana do używania compile, ale została już uznana za przestarzałą.

Dlaczego?

Zależności pojawiające się w konfiguracjach compile będą przejściowo wystawione na działanie konsumentów biblioteki i jako takie pojawią się w ścieżce kompilacji użytkowników. Zależności występujące w konfiguracji implementacji nie będą natomiast narażone na działanie konsumentów, a zatem nie będą przeciekać do ścieżki klasy kompilacji konsumenta.

Weźmy przykład, aby to zrozumieć. Załóżmy, że utworzyłem serwer Library_Image_Upload, który obsługuje Image uploading. Użyłem Library_Network lib w Library_Image_Upload, który obsługuje wszystkie operacje sieciowe. Moja biblioteka korzysta tylko z przesłanych obrazów i zapewnia wygodny sposób przesyłania zdjęć. Teraz, gdy użyłem biblioteki Library_Network w moim projekcie Library_Image_Upload, każdy używający tej biblioteki będzie miał funkcjonalność Image Uploading wraz z wszystkimi operacjami sieciowymi , że ktoś może również użyć (Ważna). Później pomyślałem, że jest lepsza alternatywa dla Library_Network jako Library_Magic_Image i użyłem jej. Tak więc wszystkie funkcje API ujawnione przez Library_Network zniknęły i ktokolwiek używa tych funkcji, zepsuł kompilację.

implementation jest kilka korzyści:

• Zależności nie przedostają się do ścieżki klasy kompilacji konsumentów anymore, więc nigdy nie będzie przypadkowo zależeć od przechodnia zależność
• Szybsze kompilacji dzięki zmniejszonej wielkości ścieżce klasy
• Mniej rekompilacji, gdy zmieniają się zależności implementacji: konsumenci nie musieliby być rekompilowani
• Czystsze publikowanie: w połączeniu z nową opcją maven-publish, biblioteki Java p tworzyć pliki POM, które rozróżniają dokładnie to, co jest wymagane do kompilacji w stosunku do biblioteki i co jest wymagane do korzystania z biblioteki w czasie wykonywania (innymi słowy, nie mieszaj tego, co jest potrzebne do kompilowania samej biblioteki i tego, co jest potrzebne do kompilacji przeciwko biblioteka).

Aby dowiedzieć się więcej czytaj The Java Library Plugin

więc myślę, że masz odpowiedzi na wszystkie trzy pytania.

Mam nadzieję, że to pomaga.