Implementación de Gradle frente a configuración de API

Estoy tratando de averiguar cuál es la diferencia entre la api y la configuración de implementation mientras construyo mis dependencias.
En la documentación, dice que la implementation tiene mejor tiempo de construcción, pero al ver este comentario en una pregunta similar, me pregunté si es cierto.
Como no soy un experto en gradle, espero que alguien pueda ayudar. Ya leí la documentación 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 sea tan inmediato para todos los desarrolladores.

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

No explicaré api , porque es lo mismo que usar la compile , así que si reemplazas toda tu compile con api todo funcionará como siempre.

Para comprender la palabra clave 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 build.gradle de MyLibrary así:

 dependencies { api project(':InternalLibrary') } 

Ahora en tu código quieres usar MyLibrary así que deberías tener un build.gradle con esta dependencia

 dependencies { api project(':MyLibrary') } 

En el código de su aplicación, con la palabra clave api (o utilizando la compile ) puede acceder a MyLibrary e 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, ya que no es importado directamente por usted.

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

 dependencies { implementation project(':InternalLibrary') } 

Y en tu aplicación build.gradle

 dependencies { implementation project(':MyLibrary') } 

ya no podrá llamar a InternalLibrary.giveMeAString() en el código de su aplicación. Si bien si MyLibrary usa la palabra clave api para importar InternalLibrary , en su aplicación podrá llamar InternalLibrary.giveMeAString() sin problemas, independientemente si usa api o implementation para agregar MyLibrary a su aplicación.

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

CONCLUSIONES

  • Cuando cambie al nuevo complemento de Android Gradle 3.XX, debe reemplazar toda su compile con la palabra clave de implementation (1 *) . Luego intente comstackr y probar su aplicación. Si todo está bien, deje el código tal como está; si tiene problemas, probablemente tenga algo mal con sus dependencias o haya utilizado algo que ahora es privado y no más accesible. Sugerencia de Android Gradle plugin engineer Jerome Dochez (1 ) *)

  • Si es un mantenedor de biblioteca, debe usar una api para cada dependencia que se necesite para la API pública de su biblioteca, mientras que la implementation uso para dependencias de prueba o dependencias no debe ser utilizada por los usuarios finales.

REFERENCIAS (Este es el mismo video dividido para ahorrar tiempo)

Google I / O 2017: cómo acelerar las comstackciones de Gradle (VIDEO COMPLETO)

Google I / O 2017: cómo acelerar las comstackciones de Gradle (SOLO PARTE DE NUEVA GRADUACIÓN PLUGIN 3.0.0)

Google I / O 2017: cómo acelerar las construcciones de Gradle (referencia a 1 * )

Documentación de Android

Me gusta pensar en una dependencia de api como pública (vista por otros módulos) mientras que la dependencia de implementation es privada (solo se ve en este módulo).

Tenga en cuenta que, a diferencia de public variables y métodos public / private , implementation dependencias api / implementation no se aplican por el tiempo de ejecución. Esto es simplemente una optimización de tiempo de comstackción, que permite a Gradle saber qué módulos necesita recomstackr cuando una de las dependencias cambia su API.