warning - update gradle android studio

Implementación de Gradle vs configuración de API

Question

Estoy tratando de averiguar cuál es la diferencia entre la configuración de la api y la implementation mientras construyo mis dependencias.
En la documentación, dice que la implementation tiene un mejor tiempo de compilación, pero al ver este comment en una pregunta similar, me pregunto si es cierto.
Como no soy un experto en gradle, espero que alguien pueda ayudar. Ya leí la documentation pero me preguntaba acerca de una explicación fácil de entender.

Answer 1

Considere que tiene un módulo de app que usa lib1 como biblioteca y lib1 usa lib2 como biblioteca. Algo como esto: app -> lib1 -> lib2 .

Ahora, cuando se usa api lib2 en lib1 , la app puede ver los códigos lib2 cuando se usa: api lib1 o implementation lib1 en el módulo de la app .

PERO cuando se usa la implementation lib2 en lib1 , la app no puede ver los códigos lib2 .

Answer 2

La palabra clave de compile Gradle quedó en desuso a favor de la api y implementation palabras clave de implementation para configurar las dependencias.

Usar api es el equivalente a usar la compile desuso, por lo que si reemplaza toda compile con api todo funcionará como siempre.

Para comprender la palabra clave de implementation considere el siguiente ejemplo.

EJEMPLO

Suponga que tiene una biblioteca llamada MyLibrary que usa internamente otra biblioteca llamada InternalLibrary . Algo como esto:

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

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

Supongamos que MyLibrary build.gradle usa la configuración de la api en dependencies{} como esta:

dependencies {
api project('':InternalLibrary'')
}

Desea usar MyLibrary en su código, por lo tanto, en el build.gradle su aplicación, agregue esta dependencia:

dependencies {
api project('':MyLibrary'')
}

Usando la configuración de la api (o la compile obsoleta) puede acceder tanto a MyLibrary como a InternalLibrary en su código de aplicación:

// 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 esta manera, el módulo MyLibrary está potencialmente "filtrando" la implementación interna de algo. No deberías (poder) usar eso porque no lo has importado directamente.

La configuración de implementation se introdujo para evitar esto. Entonces, si usa la implementation lugar de api en MyLibrary :

dependencies {
implementation project('':InternalLibrary'')
}

Y en build.gradle tu aplicación:

dependencies {
implementation project('':MyLibrary'')
}

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

Tenga en cuenta que si MyLibrary usa api para importar InternalLibrary , su aplicación PODRÁ llamar a InternalLibrary.giveMeAString() sin problemas, independientemente del uso de api o implementation para agregar MyLibrary a su aplicación.

Este tipo de estrategia de boxeo permite que el complemento Android Gradle sepa que si edita algo en InternalLibrary , solo debe desencadenar la recompilación de MyLibrary y no la recompilación de toda su aplicación, porque no tiene acceso a InternalLibrary .

Cuando tiene muchas dependencias anidadas, este mecanismo puede acelerar mucho la compilación. (Mire el video vinculado al final para obtener una comprensión completa de esto)

CONCLUSIONES

• Cuando cambie al nuevo complemento Android Gradle 3.XX, debe reemplazar toda su compile con la palabra clave de implementation (1 *) . Luego intente compilar y probar su aplicación. Si todo está bien, deje el código 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 del ingeniero del complemento Android Gradle Jerome Dochez (1 ) *)

• Si usted es un administrador de bibliotecas, debe usar una api para cada dependencia que sea necesaria para la API pública de su biblioteca, mientras usa la implementation para dependencias de prueba o dependencias que no deben ser utilizadas por los usuarios finales.

Artículo útil que muestra la diferencia entre la implementación y la API

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

Google I / O 2017 - Cómo acelerar las compilaciones de Gradle (VIDEO COMPLETO)

Google I / O 2017 - Cómo acelerar las compilaciones de Gradle (NUEVA PARTE GRADLE PLUGIN 3.0.0 SOLAMENTE)

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

here

Answer 3

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

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