Implementación de Gradle vs configuración de API

Hola, descubrimos la solución a tu búsqueda, has scroll y la hallarás un poco más abajo.

Solución:

Gradle compile la palabra clave quedó obsoleta en favor de la api y implementation palabras clave para configurar dependencias.

Utilizando api es el equivalente a usar el obsoleto compile, así que si reemplaza todos compile con api todo funcionará como siempre.

Para entender el implementation palabra clave considere el siguiente ejemplo.

EJEMPLO

Suponga que tiene una biblioteca llamada MyLibrary que utiliza 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 MyLibrarybuild.gradle usos api configuración en dependencies como esto:

dependencies 
    api project(':InternalLibrary')

Quieres usar MyLibrary en tu código así que en tu aplicación build.gradle agregas esta dependencia:

dependencies 
    implementation project(':MyLibrary')

Utilizando el api configuración (o en desuso compile) Puedes entrar InternalLibrary en el código de su aplicación:

// Access 'MyLibrary' (granted)
MyLibrary myLib = new MyLibrary();
System.out.println(myLib.myString());

// Can ALSO access the internal library too (but you shouldn't)
System.out.println(InternalLibrary.giveMeAString());

De esta forma el módulo MyLibrary potencialmente está “filtrando” la implementación interna de algo. No debería (poder) usar eso porque usted no lo ha importado directamente.

los implementation Se introdujo una configuración para evitar esto. Así que ahora si usas implementation en lugar de api en MyLibrary:

dependencies 
    implementation project(':InternalLibrary')

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

Este tipo de estrategia de boxeo permite que el complemento Gradle de Android sepa que si edita algo en InternalLibrary, solo debe desencadenar la recopilación de MyLibrary y no la recopilació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 una comprensión completa de esto)

CONCLUSIONES

• Cuando cambia al nuevo complemento 3.XX de Android Gradle, debe reemplazar todos sus compile con el implementation palabra clave *(1). Luego intente compilar y probar su aplicación. Si todo está bien, deje el código como está, si tiene problemas, probablemente tenga algún problema con sus dependencias o haya usado algo que ahora es privado y no más accesible. * Sugerencia del ingeniero de complementos de Android Gradle Jerome Dochez (1))

• Si es un conservador de bibliotecas, debería utilizar api para cada dependencia que se necesita para la API pública de su biblioteca, mientras usa implementation para probar dependencias o dependencias que no deben ser utilizadas por los usuarios finales.

Artículo útil que muestra la diferencia entre implementación y 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 (NUEVO GRADLE PLUGIN 3.0.0 SOLO PARTE)

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

Documentación de Android

Me gusta pensar en un api dependencia como público (visto por otros módulos) mientras implementation dependencia como privado (solo visto por este módulo).

Tenga en cuenta que a diferencia de public/private variables y métodos, api/implementation las dependencias no son impuestas por el tiempo de ejecución. Esto es simplemente una optimización del tiempo de compilación, que permite Gradle para saber qué módulos necesita volver a compilar cuando una de las dependencias cambia su API.

Considere que tiene app módulo que utiliza lib1 como biblioteca y lib1 usos lib2 como biblioteca. Algo como esto: app -> lib1 -> lib2.

Ahora al usar api lib2 en lib1, luego apppuede verlib2 códigos al usar: api lib1 o implementation lib1 en el app módulo.

PERO cuando se usa implementation lib2 en lib1, luego appno pueden ver los lib2 códigos.

No se te olvide difundir este tutorial si lograste el éxito.

---

---

Utiliza Nuestro Buscador