Implementação da enxada vs configuração da API

Acho que este tópico precisa de um pouco mais de cobertura porque talvez não seja tão imediato para cada desenvolvedor.

A Palavra-chave Gradle compile foi desacreditada a favor das novas api e implementation palavras-chave.

Eu não vou explicar api, porque é a mesma coisa que usar o antigo compile, por isso se você substituir todo o seu compile com api Tudo vai funcionar como sempre.

Para entender a palavra-chave implementation precisamos de um exemplo.

Exemplo

Nós ... tenha esta biblioteca chamada MyLibrary onde internamente estamos usando outra biblioteca chamada InternalLibrary. Algo assim:

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

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

As dependências build.gradle de MyLibrary são assim:

dependencies {
    api project(':InternalLibrary')
}

Agora no seu código você quer usar {[14] } Então você deve ter um build.gradle com esta dependência

dependencies {
    api project(':MyLibrary')
}

No seu código de aplicação, com a palavra-chave api (ou usando a antiga compile) pode aceder a ambas 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());

Desta forma você está potencialmente "vazando" o implementação interna de algo que você não deve usar porque não é diretamente importado por você.

Para evitar isso, Gradle criou a nova palavra-chave implementation, Então agora se você mudar api para implementation na sua MyLibrary

dependencies {
    implementation project(':InternalLibrary')
}

E na tua aplicação build.gradle

dependencies {
    implementation project(':MyLibrary')
}

Já não vais poder ligar para o teu código de Aplicação. Embora MyLibrary use a palavra-chave api para importar InternalLibrary, na sua aplicação poderá ligar para InternalLibrary.giveMeAString() sem problemas, independentemente se utilizar api ou implementation para adicionar MyLibrary à sua aplicação.

Usando este tipo de estratégia de boxe, o plugin Android Gradle sabe que se editar algo em InternalLibrary irá desencadear a recompilação apenas de MyLibrary. Não irá desencadear a recompilação de toda a sua aplicação porque você não tem acesso a InternalLibrary. Este mecanismo quando você tem um monte de dependências aninhadas pode acelerar a construção muito.(Veja o vídeo ligado no final para uma compreensão completa de isto)

Conclusões

• Quando mudar para o novo plugin Android Gradle 3.X. X, deve substituir todas as suas compile pela palavra-chave implementation (1*). Em seguida, tente compilar e testar o seu aplicativo. Se tudo está bem deixe o código como está, se você tem problemas você provavelmente tem algo errado com suas dependências ou você usou algo que agora é privado e não mais acessível. Sugestão do engenheiro de grelhas Android Jerome Dochez (1)*)

• Se você é um mantenedor de biblioteca você deve usar api para cada dependência que é necessária para a API pública da sua biblioteca, enquanto usa implementation para testar dependências ou dependências que não devem ser usadas pelos usuários finais.

Referências (Este é o mesmo vídeo dividido para a poupança de tempo)

Google I / O 2017 - How speed up Gradle builds (FULL VIDEO)

Google I / O 2017-How acelerar as compilações das grelhas (apenas a parte do novo 'PLUGIN' 3. 0. 0)

Google I / O 2017 - How speed up Gradle builds (referência a 1*)

Documentação Android