web-dev-qa-db-fra.com

Gradle Implementation vs configuration de l'API

J'essaie de comprendre quelle est la différence entre la configuration api et implementation lors de la construction de mes dépendances.
Dans la documentation, il est indiqué que implementation a un meilleur temps de construction, mais, voyant ceci commentaire dans une question similaire, je me suis demandé si c'était vrai.
Étant donné que je ne suis pas un expert en diplômes, j'espère que quelqu'un pourra vous aider. J'ai déjà lu documentation mais je m'interrogeais sur une explication facile à comprendre.

androidgradledependenciesimplementation
163
Viper Alpha

Le mot-clé Gradle compile est déconseillé en faveur des mots-clés api et implementation pour configurer les dépendances.

Utiliser api équivaut à utiliser le obsolète compile. Ainsi, si vous remplacez tout compile par api, tout fonctionnera comme toujours.

Pour comprendre le mot clé implementation, considérons l'exemple suivant.

EXEMPLE

Supposons que vous avez une bibliothèque appelée MyLibrary qui 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 MyLibrarybuild.gradle utilise la configuration de api dans dependencies{} comme ceci:

dependencies {
    api project(':InternalLibrary')
}

Vous voulez utiliser MyLibrary dans votre code, donc dans le build.gradle de votre application, vous ajoutez cette dépendance:

dependencies {
    api project(':MyLibrary')
}

À l'aide de la configuration api (ou obsolète compile), vous pouvez accéder à la fois à MyLibrary et InternalLibrary dans votre code d'application:

// Access 'MyLibrary' (as desired and expected)
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 manière, le module MyLibrary risque de "fuir" la mise en oeuvre interne de quelque chose. Vous ne devriez pas (pouvoir) utiliser cela parce que ce n'est pas directement importé par vous.

La configuration implementation a été introduite pour empêcher cela. Alors maintenant, si vous utilisez implementation au lieu de api dans MyLibrary:

dependencies {
    implementation project(':InternalLibrary')
}

Et dans le build.gradle de votre application:

dependencies {
    implementation project(':MyLibrary')
}

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

Notez que si MyLibrary utilise api pour importer InternalLibrary, votre application POURRA pouvoir appeler InternalLibrary.giveMeAString() sans problèmes. , indépendamment de l'utilisation de api ou implementation pour ajouter MyLibrary à votre application.

Ce type de stratégie de boxe permet à Android Gradle plugin de savoir que si vous éditez quelque chose dans InternalLibrary, il ne doit déclencher que la recompilation de MyLibrary et la recompilation de l'ensemble de votre application, car vous n'avez pas accès à InternalLibrary.

Lorsque vous avez beaucoup de dépendances imbriquées, ce mécanisme peut accélérer beaucoup la construction. (Regardez la vidéo liée à la fin pour bien comprendre)

CONCLUSIONS

  • Lorsque vous passez au nouveau plug-in Android Gradle 3.XX, vous devez remplacer tous vos compile par le mot clé implementation (1 *). . Ensuite, essayez 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 pas plus accessible. Suggestion de Android Jerome Dochez, ingénieur plug-in Gradle (1 ) * )

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

Article utile Présentant la différence entre la mise en oeuvre et api

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

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

Google I/O 2017 - Comment accélérer Gradile construit (NEW GRADLE PLUGIN 3.0.0 PARTIE UNIQUEMENT)

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

documentation Android

315
MatPag

J'aime penser à une dépendance api publique (vu par les autres modules) tandis que implementation dépendance comme privé (vu seulement par ce module).

Notez que contrairement aux variables et méthodes public/private, les dépendances api/implementation ne sont pas appliquées par le moteur d'exécution. Il s'agit simplement d'une optimisation au moment de la construction, qui permet à Gradle de savoir quels modules il doit recompiler lorsque l'une des dépendances change d'API.

79
dev.bmax

Considérez que vous avez le module app qui utilise lib1 comme bibliothèque et lib1 utilise lib2 comme bibliothèque. Quelque chose comme ça: app -> lib1 -> lib2.

Maintenant, lorsque vous utilisez api lib2 dans lib1, puis appvous pouvez voirlib2 codes lorsque vous utilisez: api lib1 ou implementation lib1 dans le module app.

MAIS lorsqu’on utilise implementation lib2 dans lib1, alors appne peut pas voir les codes lib2.

3
Ehsan Mashhadi