Implementación de Gradle vs configuración de API

Estoy tratando de averiguar cuál es la diferencia entre api y la configuración de la implementation , mientras que la construcción de mis dependencias.
En la documentación, dice que la implementation tiene mejor tiempo de construcción, pero, viendo este comentario en una pregunta similar, llegué a preguntarme si es cierto.
Ya que no soy experto en grados, espero que alguien pueda ayudar. He leído la documentación ya, pero me preguntaba sobre una explicación fácil de entender.

Creo que este tema necesita un poco más de cobertura porque tal vez no es tan inmediato para todos los desarrolladores.

La palabra clave de compile Gradle ha quedado obsoleta en favor de las nuevas palabras clave de api e implementation .

No voy a explicar api , porque es lo mismo que usar la compile edad, por lo que si reemplazar todo su compile con api todo funcionará como siempre.

Para entender la palabra clave de implementation necesitamos un ejemplo.

EJEMPLO

Tenemos esta biblioteca llamada MyLibrary donde internamente estamos usando otra biblioteca llamada InternalLibrary . Algo como esto:

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

Las dependencias de build.gradle de MyLibrary así:

 dependencies { api project(':InternalLibrary') }

Ahora en su código que desea utilizar MyLibrary por lo que debe tener un build.gradle con esta dependencia

 dependencies { api project(':MyLibrary') }

En el código de la aplicación, con la palabra clave api (o con la antigua compile ), puede acceder tanto a MyLibrary como a 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());

De esta forma, potencialmente está "filtrando" la implementación interna de algo que no debería usar porque no es importado directamente por usted.

Para evitar esto, Gradle ha creado la nueva palabra clave de implementation , por lo que ahora si cambia api a implementation en su MyLibrary

 dependencies { implementation project(':InternalLibrary') }

Y en su aplicación build.gradle

 dependencies { implementation project(':MyLibrary') }

No podrá llamar a InternalLibrary.giveMeAString() en el código de su aplicación.

Usando este tipo de estrategia de boxeo, el complemento gradle de Android sabe que si edita algo en InternalLibrary activará la recompilación de MyLibrary solamente. No activará la recompilación de toda tu aplicación porque no tienes acceso a InternalLibrary . Este mecanismo cuando tienes un montón de dependencias anidadas puede acelerar la construcción mucho. (Ver el video vinculado al final para una comprensión completa de esto)

CONCLUSIONES

Cuando cambia al nuevo complemento de gradle Android 3.XX, debe reemplazar toda su compile por la palabra clave de implementation (1 *) . Luego intenta compilar y probar tu aplicación. Si todo está bien, deje el código como está, si tiene problemas probablemente tiene algo malo con sus dependencias o ha usado algo que ahora es privado y no más accesible. Sugerencia de Android Gradle plugin ingeniero Jerome Dochez (1 ) *)
Si usted es un mantainer de la biblioteca, cambiando sus dependencias internas a la implementation en implementation , podría romper algunos códigos en la parte final del revelador si él utilizó algunas bibliotecas internas que él no debe utilizar, así que tenga cuidado de esto. (Potencialmente un desarrollador de noob podría haber utilizado el appcompat declarado internamente en su biblioteca en lugar de proporcionar su propia dependencia en su archivo build.gradle) (super-edge-case: D) Sin embargo, creo que valdrá la pena el esfuerzo y cada biblioteca debe cambiar A esta nueva implementación cuando Android plugin 3.0.0 será lanzado oficialmente.