2017-09-15 5 views
0

J'ai un projet Android Studio qui contient 3 modules. A, B, C. A dépend de C et B dépend de C. J'essaie d'accélérer les temps de construction, et j'ai réalisé que chaque fois que j'exécute la tâche assembleRelease/assembeDebug, elle construit TOUS les modules. Chaque fois que je construis le module A ne devrait construire que A et C, car B n'a aucune dépendance dans cette tâche, non? Comment puis-je éviter que le module B soit construit à chaque fois que je construis le module A?Exclure le module sur la construction Android Studio

Module A dépendances:

dependencies { 
    compile project(path: ':c', configuration: 'release') 
    provided files('libs/some-lib.jar') 
} 

dépendances Module B:

dependencies { 
    compile project(path: ':c', configuration: 'debug') 
} 

Module dépendances C:

dependencies { 
    compile files('libs/other-lib.jar') 
} 
+0

Comment exécutez-vous les tâches? Via la ligne de commande, ou via la boîte de dialogue Gradle dans Android Studio? – jdv

+0

J'exécutais des tâches à partir de la boîte de dialogue gradle .. maintenant im exécuter des tâches à partir de la ligne de commande et les temps de construction diminuaient beaucoup .. apparemment gradle construit tous les modules peu importe ce que vous essayez de construire –

+0

soigneusement) exécuter une tâche sous-module à partir d'Android Studio est en fait l'appel de la tâche à partir de la racine du projet. Comme la racine contient généralement toutes les références, l'arborescence de construction configurée qu'elle contient contient tous les modules. Si vous démarrez une seconde instance/fenêtre d'Android Studio exécutant une tâche de sous-module, vous créerez simplement une arborescence de construction basée sur ce module et ses dépendances. C'est facile à voir dans le journal Gradle. – jdv

Répondre

0

There is a bug in Android Studio où si vous utilisez la Gradle projets de dialogue pour exécuter des tâches, ces tâches seront exécutées dans le contexte racine. C'est-à-dire, si vous regardez attentivement, même les tâches sous-module sont exécutées comme si vous exécutiez la même tâche au niveau racine.

Solutions:

  1. Utilisez la ligne de commande wrapper Gradle ou Gradle.
  2. Toujours exécuter deux instances d'Android Studio (c.-à-plusieurs projets sont ouverts)
+0

J'ai commencé à construire à partir de la console en utilisant des commandes comme: ** gradlew a: assembleDebug ** .. les temps de construction ont beaucoup diminué! Merci –

-1

retirant simplement la déclaration include du module connexe (B dans ce cas) dans le fichier racine settings.gradle devrait arrêter Android Studio à partir de la construction B car il l'exclura du projet général Gradle. Le module reste intact, mais si vous envisagez de modifier un code, il est nécessaire de rajouter l'instruction include. Notez également que la modification du fichier settings.gradle nécessite une synchronisation Gradle pour Android Studio pour fonctionner correctement.

+0

C'est comme dire que vous ne voulez pas que le Module B fasse partie du projet, ce qui n'est probablement pas ce que nous voulons faire ici. – jdv

+0

Cela dépend vraiment de la façon dont les choses sont structurées en réalité et c'est un peu opiniâtre. Pour moi si le répertoire du module est dans la racine du projet, je ne considérerais pas pour autant qu'il soit retiré du projet même si l'instruction '' '' include''' est supprimée, c'est toujours là mais pas actif, et donc avec moins avec moins de construction qui est le point de base de l'OP – ahasbini

+0

Oui, mais Android Studio, au moins dans 2.x, _considers it removed_. Il vous demandera même si vous voulez le retirer de la liste des modules, et il sera rendu en police normale au lieu de gras dans l'interface utilisateur. Même si vous ne le "supprimez" pas, mais le gardez dans la liste des modules mais non attaché au projet principal, il y aura toutes sortes de problèmes.Gradle de la ligne de commande fonctionnera probablement encore, mais la synchronisation et d'autres activités d'interface utilisateur dans Android Studio ne verront jamais ce module. De plus, dans un contexte d'équipe, ce fichier est partagé, et le peaufiner entraînera toutes sortes de confusions inutiles. – jdv