Le mystère: structure de projet et système de construction d'Android Studio
Je ne sais pas si c'est à cause du Gradle Build System (je parie que c'est le cas), mais je vais vous dire ce que j'ai compris jusqu'à présent.
Mise à jour 4: 2014/09/11 Ajout d'une feuille de triche pour BuildTypes, Flavorset Variants(je me sens enfin confiant d'écrire ceci: D)
Mise à jour 3: 2014/09/11 Mise à jour des espaces de travail et des projets de comparaison pour être précis
Mise à jour 2: 2014/04/17 Ajout de plus de détails à la structure du projet AS
Mise à jour 1: 29/07/2013 Ajout de la structure du projet IntelliJ
La structure du projet d'IntelliJ (illustrée à la fin) est pour IntelliJ avec le plugin Android. Cependant, Android Studio a une structure de projet divisée comme suit:
Structure: projets et modules
module dans Android Studio est comme un projet dans Eclipse
projet dans Android Studio est comme un espace de travail dans Eclipse (pour être précis, un espace de travail avec des projets interdépendants)
À partir de la documentation (Android Studio est basé sur Intellij IDEA):
Quoi que vous fassiez dans IntelliJ IDEA, vous le faites dans le contexte d'un projet. Un projet est une unité organisationnelle qui représente une solution logicielle complète.
Votre produit fini peut être décomposé en une série de modules discrets et isolés, mais c'est une définition de projet qui les rassemble et les lie en un tout plus grand.
Pour Android, cela signifie un projet par application et un module par bibliothèque et par application de test.
Il existe plusieurs problèmes si vous essayez de créer plusieurs applications dans le même projet. C'est possible, mais si vous essayez (comme moi), vous verrez que presque tout est conçu pour fonctionner avec une seule application par projet.
Par exemple, il existe une option pour «reconstruire le projet», ce qui n'a aucun sens avec plusieurs applications, de nombreux autres paramètres de projet seraient inutiles et le système VCS intégré n'est pas génial lorsque vous avez plusieurs référentiels.
Structure: Structure des dossiers
Dossiers de premier niveau
1. Projet principal
Ce serait tout le contexte du projet ( Eclipse Land: comme votre espace de travail mais limité à ce qui est pertinent pour votre projet). Ex: HelloWorldProjectsi le nom de l'application que vous avez donné étaitHelloWorld
2. .idée
C'est là que les métadonnées spécifiques au projet sont stockées par Android Studio (AS). ( Eclipse Land: project.properties fichier)
3. Module de projet
C'est le projet proprement dit. ex: HelloWorldsi le nom de votre application que vous avez donné était HelloWorld
4. gradle
C'est là que le wrapper jar du système de construction gradle, c'est-à-dire que ce fichier jar est la façon dont AS communique avec gradle installé dans Windows (le système d'exploitation dans mon cas).
5. Bibliothèques externes
Ce n'est pas en fait un dossier mais un endroit où les bibliothèques référencées ( Eclipse Land: Referenced Libraries) sont affichées. Voici où la plate-forme ciblée est affichée, etc.
[ Note latérale: C'est là que beaucoup d'entre nous dans Eclipse Land avaient l'habitude de supprimer les bibliothèques référencées et de corriger les propriétés du projet pour corriger les erreurs de référence, vous vous souvenez?]
Dossier de projet en détail
Il s'agit du numéro 3 dans la liste ci-dessus. Contient les sous-répertoires suivants
1. construire
Cela a toute la sortie complète du make processus, c'est-à-dire classes.dex, classes et ressources compilées, etc.
Dans l'interface graphique d'Android Studio, seuls quelques dossiers sont affichés. L'important est que votre R.java se trouve ici sousbuild/source/<flavor>/r/<build type(optional)>/<package>/R.java
2. libs
Il s'agit du dossier libs standard que vous voyez dans eclipse land trop
3. src
Ici, vous ne voyez que le dossier javaet resqui correspond au srcdossier et au resdossier dans Eclipse Land . Ceci est une simplification très bien accueillie à mon humble avis.
Remarque sur les modules:
Les modules sont comme Eclipse Land projets . Ici, l'idée est que vous avez un projet d'application (module n ° 3 dans la liste ci-dessus) et plusieurs projets de bibliothèque (en tant que modules séparés sous le dossier de projet global (n ° 1 dans la liste ci-dessus)) dont dépend le projet d'application. Comment ces projets de bibliothèque peuvent être réutilisés dans d'autres applications, je n'ai toujours pas découvert.
[ Note latérale: toute la réorganisation a des avantages comme des simplifications dans le dossier src, mais tant de complications. Les complications sont principalement dues à une documentation TRÈS TRÈS mince sur cette nouvelle présentation de projet.]
Le nouveau système de construction
Guide de l'utilisateur du nouveau système de construction
Explication des saveurs et des buildTypes, etc. - De quoi s'agit-il?
CheatSheet pour les saveurs et les buildTypes
BuildType: debug et releasesont buildTypesdisponibles par défaut sur tous les projets. Ils servent à créer / compiler le MÊME CODE pour générer différents APK. Par exemple, sur les releaseAPK, vous voudriez exécuter proguard (pour obfuscation), le signer avec votre clé (par opposition à la clé de débogage), exécuter des optimisations (peut-être via proguard ou d'autres outils), utiliser légèrement différent packageNames(nous utilisons com.company.productpour releaseet com.company.product.debugpour debug), etc. Nous utilisons également un indicateur de débogage ( BuildConfig.DEBUG) pour désactiver la journalisation dans logcat (car cela ralentit l'application) sur les releasebuilds. Cela permet une debugconstruction plus rapide pendant le développement mais aussi une optimisationrelease à mettre sur le Play Store.
Saveur du produit: Il n'y a pas de saveurs par défaut disponibles (ou pour être précis, la saveur par défaut est vide / sans nom). Flavorspourrait être une version gratuite ou une version payante où ils ont un CODE DIFFÉRENT . Ils partagent le même Maincode mais des versions différentes (ou aucune version) de quelques fichiers ou ressources de code source.
BuildVariant: A buildVariantcorrespond en réalité à un APK généré. Ils sont nommés ainsi (dans l'ordre) Product Flavor+ Build Type=Build Variant .
Exemple 1: si vous avez freeet paidcomme deux saveurs. Les variantes de construction que vous obtiendriez sont:
Gratuit - débogage
Gratuit - version
payée - débogage
payant - libération
Donc, c'est 4 configurations APK possibles. Quelques configurations peuvent ne pas avoir de sens dans un projet particulier, mais elles sont disponibles.
Exemple 2: (pour les nouveaux projets / aucune saveur) Vous avez 2 buildVariantsou APK disponibles, car la saveur par défaut est sans nom / vide:
version de
débogage
Le dossier .idea (1) contient un certain nombre de sous-dossiers, principalement avec des informations internes IntelliJ IDEA.
Le dossier src (2) contient le code source du fichier MyActivity.java (3) qui implémente les fonctionnalités de votre application. Le fichier appartient au package com.example.
Le dossier res (4) contient diverses ressources visuelles.
Le fichier layout / main.xml (5) définit l'apparence de l'application constituée de ressources de différents types.
Le dossier values (6) est destiné au stockage des fichiers .xml qui décrivent des ressources de différents types. Actuellement, le dossier contient un fichier strings.xml avec des définitions de ressources String. Comme vous le verrez dans la section Ajouter une couleur, le dossier de mise en page peut également contenir, par exemple, un descripteur de couleurs.
Le dossier dessinable (7) contient des images.
Le dossier gen (8) contient le fichier R.java (9) qui relie les ressources visuelles et le code source Java. Comme vous le verrez dans les sections ci-dessous, IntelliJ IDEA prend en charge une intégration étroite entre les ressources statiques et R.java. Dès que des ressources sont ajoutées ou supprimées, les classes et les champs de classe correspondants dans R.java sont automatiquement générés ou supprimés en conséquence. Le fichier R.java appartient également au package com.example.
