Implémentation Gradle vs configuration API

J'essaie de comprendre quelle est la différence entre apiet la implementationconfiguration lors de la construction de mes dépendances.
Dans la documentation, il est dit que le implementationtemps de construction est meilleur, mais, en voyant ce commentaire dans une question similaire, je me demande si c'est vrai.
Étant donné que je ne suis pas un expert du gradle, j'espère que quelqu'un pourra vous aider. J'ai déjà lu la documentation mais je me demandais une explication facile à comprendre.

Le compilemot clé Gradle a été déconseillé au profit des mots clés apiet implementationpour configurer les dépendances.

Utiliser apiéquivaut à utiliser le obsolète compile, donc si vous remplacez tout compilepar apitout, cela fonctionnera comme toujours.

Pour comprendre le implementationmot - clé, considérons l'exemple suivant.

EXEMPLE

Supposons que vous ayez une bibliothèque appelée MyLibraryqui utilise en interne une autre bibliothèque appelée InternalLibrary. Quelque chose comme ça:

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

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

Supposons que la configuration MyLibrary build.gradleutilise comme ceci:apidependencies{}

dependencies {
    api project(':InternalLibrary')
}

Vous voulez utiliser MyLibrarydans votre code donc dans votre application build.gradlevous ajoutez cette dépendance:

dependencies {
    implementation project(':MyLibrary')
}

En utilisant la apiconfiguration (ou obsolète compile), vous pouvez accéder InternalLibrarydans votre code d'application:

// Access 'MyLibrary' (granted)
MyLibrary myLib = new MyLibrary();
System.out.println(myLib.myString());

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

De cette façon, le module MyLibrary«fuit» potentiellement l'implémentation interne de quelque chose. Vous ne devriez pas (pouvoir) l'utiliser car il n'est pas directement importé par vous.

La implementationconfiguration a été introduite pour éviter cela. Alors maintenant, si vous utilisez implementationau lieu de apidans MyLibrary:

dependencies {
    implementation project(':InternalLibrary')
}

vous ne pourrez plus appeler InternalLibrary.giveMeAString()votre code d'application.

Ce type de stratégie de boxe permet au plugin Android Gradle de savoir que si vous modifiez quelque chose InternalLibrary, il ne doit déclencher que la recompilation MyLibraryet non la recompilation de l'ensemble de votre application, car vous n'y avez pas accès InternalLibrary.

Lorsque vous avez beaucoup de dépendances imbriquées, ce mécanisme peut accélérer considérablement la construction. (Regardez la vidéo liée à la fin pour une compréhension complète de cela)

CONCLUSIONS

• Lorsque vous passez au nouveau plugin Android Gradle 3.XX, vous devez remplacer tous vos fichiers compilepar le implementationmot - clé (1 *) . Essayez ensuite de compiler et de tester votre application. Si tout va bien, laissez le code tel quel, si vous avez des problèmes, vous avez probablement un problème avec vos dépendances ou vous avez utilisé quelque chose qui est maintenant privé et qui n'est pas plus accessible. Suggestion par l'ingénieur du plugin Android Gradle Jerome Dochez (1 ) * )

• Si vous êtes un responsable de bibliothèque, vous devez utiliser apipour chaque dépendance qui est nécessaire pour l'API publique de votre bibliothèque, tandis que implementationpour les dépendances de test ou les dépendances qui ne doivent pas être utilisées par les utilisateurs finaux.

Article utile présentant la différence entre l' implémentation et l' API

RÉFÉRENCES (Il s'agit de la même vidéo divisée pour gagner du temps)

Google I / O 2017 - Comment accélérer la construction de Gradle (FULL VIDEO)

Google I / O 2017 - Comment accélérer la construction de Gradle (NOUVEAU GRADLE PLUGIN 3.0.0 PART UNIQUEMENT)

Google I / O 2017 - Comment accélérer la construction de Gradle (référence à 1 * )

Documentation Android

J'aime penser une apidépendance comme publique (vue par d'autres modules) tandis que la implementationdépendance est privée (vue seulement par ce module).

Notez que, contrairement aux public/ privatevariables et aux méthodes, api/ les implementationdépendances ne sont pas appliquées par le runtime. Il s'agit simplement d'une optimisation au moment de la construction, qui permet Gradlede savoir de quels modules il a besoin pour recompiler lorsque l'une des dépendances change son API.

Considérez que vous avez un appmodule qui utilise lib1comme bibliothèque et lib1utiliselib2 comme bibliothèque. Quelque chose comme ceci: app -> lib1 -> lib2.

Maintenant, lorsque vous utilisez api lib2dans lib1, vous app pouvez voir les lib2 codes lorsque vous utilisez: api lib1ouimplementation lib1 dans leapp module.

MAIS lors de l'utilisation implementation lib2dans lib1, app ne peut pas voir les lib2codes.

Réponses de @matpag et @ dev-bmax sont suffisamment claires pour faire comprendre aux utilisateurs les différents usages entre l'implémentation et l'API. Je veux juste faire une explication supplémentaire sous un autre angle, espère aider les gens qui ont la même question.

J'ai créé deux projets à tester:

• projet A tant que projet de bibliothèque java nommé 'frameworks-web-gradle-plugin' dépend de 'org.springframework.boot: spring-boot-gradle-plugin: 1.5.20.RELEASE'
• le projet B dépend du projet A par implémentation 'com.example.frameworks.gradle: frameworks-web-gradle-plugin: 0.0.1-SNAPSHOT'

La hiérarchie des dépendances décrite ci-dessus ressemble à:

[project-b] -> [project-a] -> [spring-boot-gradle-plugin]

J'ai ensuite testé les scénarios suivants:

1. Faire le projet A dépend de 'org.springframework.boot: spring-boot-gradle-plugin: 1.5.20.RELEASE' par l' implémentation .

   Exécutez la gradle dependenciescommande dans un terminal dans le répertoire racine poject B ， avec la capture d'écran suivante de la sortie, nous pouvons voir que 'spring-boot-gradle-plugin' apparaît dans l'arbre des dépendances de runtimeClasspath, mais pas dans celui de compileClasspath, je pense que c'est exactement pourquoi nous ne pouvons pas faire utilisation de la bibliothèque qui a déclaré utiliser l'implémentation, elle ne le sera tout simplement pas par compilation.

   

2. Faire un projet A dépend de 'org.springframework.boot: spring-boot-gradle-plugin: 1.5.20.RELEASE' par api

   Exécutez à nouveau la gradle dependenciescommande dans un terminal dans le répertoire racine de poject B. Maintenant, 'spring-boot-gradle-plugin' apparaît à la fois dans l'arborescence des dépendances compileClasspath et runtimeClasspath.

   

Une différence significative que j'ai remarquée est que la dépendance dans le projet producteur / bibliothèque déclarée de manière implémentée n'apparaîtra pas dans compileClasspath des projets consommateurs, de sorte que nous ne pouvons pas utiliser la bibliothèque correspondante dans les projets consommateurs.

De la documentation Gradle :

Voyons un script de construction très simple pour un projet basé sur JVM.

plugins {
    id 'java-library'
}

repositories {
    mavenCentral()
}

dependencies {
    implementation 'org.hibernate:hibernate-core:3.6.7.Final'
    api 'com.google.guava:guava:23.0'
    testImplementation 'junit:junit:4.+'
}

la mise en oeuvre

Les dépendances requises pour compiler la source de production du projet qui ne font pas partie de l'API exposée par le projet. Par exemple, le projet utilise Hibernate pour sa mise en œuvre de la couche de persistance interne.

api

Les dépendances requises pour compiler la source de production du projet qui font partie de l'API exposée par le projet. Par exemple, le projet utilise Guava et expose les interfaces publiques avec les classes Guava dans leurs signatures de méthode.