Gradle de mise en Œuvre de vs API de configuration

Gradle compile mot-clé a été dépréciée en faveur de la api et implementation des mots clés pour configurer les dépendances.

À l'aide de api est l'équivalent de l'aide de l'obsolète compile, donc si vous remplacez tous les compile avec api tout fonctionne comme toujours.

Pour comprendre la implementation mot-clé 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 ceci:

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

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

Supposons que le MyLibrary build.gradle utilise api de configuration dans dependencies{} comme ceci:

dependencies {
    api project(':InternalLibrary')
}

Vous souhaitez utiliser MyLibrary dans votre code dans votre application build.gradle vous ajouter cette dépendance:

dependencies {
    api project(':MyLibrary')
}

À l'aide de la api de configuration (ou obsolète compile), vous pouvez accéder à la fois à MyLibrary et InternalLibrary dans le code de votre 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 est potentiellement une "fuite" de la mise en œuvre interne de quelque chose. Vous ne devriez pas (être capable de) l'utiliser car il n'est pas importés directement par vous.

La implementation de configuration a été introduit pour éviter cela.
Alors maintenant, si vous utilisez implementation au lieu de api dans MyLibrary:

dependencies {
    implementation project(':InternalLibrary')
}

Et dans votre application build.gradle:

dependencies {
    implementation project(':MyLibrary')
}

vous ne serez pas en mesure d'appeler InternalLibrary.giveMeAString() dans votre application code plus.

Noter que si MyLibrary utilise api à l'importation InternalLibrary, votre application SERA être en mesure d'appeler InternalLibrary.giveMeAString() sans problème, indépendant de l'utilisation de api ou implementation pour ajouter MyLibrary à votre application.

Ce genre de boxe stratégie permet à l'Android plugin Gradle de savoir que si vous modifiez quelque chose dans InternalLibrary pour déclencher la recompilation de MyLibrary seulement et de ne pas déclencher la recompilation de l'ensemble de votre application parce que vous n'avez pas accès à InternalLibrary.

Quand vous avez beaucoup de imbriqués les dépendances de ce mécanisme peut accélérer la construction d'un beaucoup. (Regarder la vidéo, liée à la fin pour une pleine compréhension de ce)

CONCLUSIONS

• Lorsque vous basculez vers la nouvelle Android plugin Gradle 3.X.X, vous devez remplacer tous vos compile avec le implementation mot-clé (1*). Ensuite, essayez de compiler et de tester votre application. Si tout est ok de laisser le code en l'état, si vous avez des problèmes, vous avez probablement quelque chose de mal avec vos dépendances ou vous avez utilisé quelque chose qui maintenant est privée et n'est pas plus accessible. Suggestion Android plugin Gradle ingénieur Jérôme Dochez (1)*)

• Si vous êtes une bibliothèque mantainer vous devez utiliser api pour chaque dépendance qui est nécessaire pour l'API publique de votre bibliothèque, alors que l'utilisation implementation pour le test des dépendances ou des dépendances qui ne doit pas être utilisé par les utilisateurs finaux.

Article utile Mettant en valeur la différence entre mise en œuvre et api

RÉFÉRENCES
(C'est la même vidéo découpée en place pour un gain de temps)

Google I/O 2017 - Comment accélérer Gradle construit (VIDÉO COMPLÈTE)

Google I/O 2017 - Comment accélérer Gradle construit (NOUVEAU PLUGIN GRADLE 3.0.0 PARTIE SEULEMENT)

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

Android documentation

OriginalL'auteur MatPag

Considérer que vous avez app module qui utilise lib1 comme une bibliothèque et lib1 utilise lib2 comme une bibliothèque. Quelque chose comme ceci: app -> lib1 -> lib2.

Maintenant lors de l'utilisation de api lib2 dans lib1, puis app pouvez voir lib2 codes lors de l'utilisation: api lib1 ou implementation lib1 dans le app module.

MAIS lors de l'utilisation de implementation lib2 dans lib1, puis app ne pouvez pas voir la lib2 codes.

OriginalL'auteur Ehsan Mashhadi