Android Structure de projet Studio (v. Structure de projet Eclipse)
J'essaie d'apprendre le développement de Android et je suis d'abord dérouté par les différentes structures de projet entre Eclipse et Android Studio. Il est donc difficile de suivre des tutoriels conçus pour Eclipse. Quelqu'un pourrait-il me dire pourquoi ces différences existent? Devraient-ils exister?
Par exemple, si je localisais le fichier R.Java dans deux IDE différents, les chemins ressembleraient à ceci:
Eclipse: app\gen\com.example.app\R.Java
Android Studio: app\build\source\r\debug\com.example.app\R.Java
Pourquoi ces chemins sont-ils différents? Pourquoi mon R.Java se trouve-t-il dans un dossier de débogage sous Android Studio? Cela a conduit à des erreurs dès le début, et si quelqu'un a un aperçu de ces différences, je les apprécierais.
Le mystère: Android Structure de projet et système de construction de Studio
Je ne sais pas si cela est dû au système de construction Gradle (je parie que c'est le cas), mais je vais vous dire ce que j'ai compris jusqu'à présent.
Update 4: 2014/09/11 Ajouté aide-mémoire pour BuildTypes, Flavors et Variants (Je me sens enfin confiant pour écrire ceci: D)
Update 3: 2014/09/11 Mis à jour les espaces de travail de comparaison et les projets pour être précis
Update 2: 2014/04/17 Ajout de détails supplémentaires à la structure de projet AS.
Update 1: 2013/07/29 Structure de projet IntelliJ ajoutée
La structure de projet d'IntelliJ (indiquée à la fin) est destinée à IntelliJ avec le plugin Android. Le studio Android, cependant, a une structure de projet divisée comme suit:
Structure: Projets et Modules
module in Android Studio est semblable à un projet in 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)
Depuis 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 il s’agit d’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 y a plusieurs problèmes si vous essayez de créer plusieurs applications dans le même projet. C'est possible, mais si vous essayez (comme je l'ai fait), 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 niveau supérieur
1. Projet principal
Ce serait entier contexte du projet ( Eclipse Land: Comme votre espace de travail mais limité à ce qui est pertinent pour votre projet). Ex: HelloWorldProject si le nom de l'application que vous avez donnée était HelloWorld
2. .idea
Ceci où les métadonnées spécifiques au projet sont stockées par Android Studio (AS). ( Eclipse Land: fichier project.properties)
3. Module de projet
C'est le projet actuel. ex: HelloWorld si le nom de votre application que vous avez donné était HelloWorld
4. grade
C’est là que le wrapper de jar du système de génération de Gradle, c’est-à-dire, comment AS communique avec Gradle installé sous Windows (le système d’exploitation dans mon cas).
5. Bibliothèques externes
Ce n'est pas réellement un dossier mais un endroit où des bibliothèques référencées ( Eclipse Land: des bibliothèques référencées) sont affichées. Voici où la plate-forme ciblée est affichée, etc.
[ Note latérale: C'est là où beaucoup d'entre nous, dans Eclipse Land, utilisions pour supprimer les bibliothèques référencées et Corriger les propriétés du projet pour corriger les erreurs de référence, rappelez-vous?]
Dossier de projet en détail
C'est le numéro 3 dans la liste ci-dessus. A les sous-répertoires suivants
1. construire
Ceci contient toute la sortie complète du processus make, à savoir classes.dex, classes et ressources compilées, etc.
Dans l'interface graphique de Android Studio, seuls quelques dossiers sont affichés. La partie importante est que votre R.Java se trouve ici sous build/source/<flavor>/r/<build type(optional)>/<package>/R.Java
2. libs
Ceci est le dossier standard de la bibliothèque que vous voyez dans Eclipse land aussi
3. src
Ici, vous ne voyez que les dossiers Java et res qui correspondent au dossier src et au dossier res dans Eclipse Land . Ceci est très bien accueillie simplification IMHO.
Note sur les modules:
Les modules ressemblent à des projets Eclipse Land . Ici, l’idée est que vous ayez un projet d’application (module n ° 3 dans la liste ci-dessus) et plusieurs projets de bibliothèque (sous forme de modules distincts dans 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 ne l'ai toujours pas découvert.
[ Note latérale: La réorganisation dans son ensemble présente des avantages, tels que des simplifications dans le dossier src, mais de nombreuses complications. Les complications sont principalement dues à TRÈS TRÈS une documentation restreinte sur cette nouvelle présentation de projet.]
Le nouveau système de construction
Guide de l'utilisateur pour le nouveau système de compilation
Explication des goûts et des types de construction, etc. - Quel est le rôle du voile?
CheatSheet pour les saveurs et buildTypes
BuildType: debug et release sont buildTypes disponibles par défaut sur tous les projets. Ils sont pour construire/compiler le SAME CODE pour générer différents fichiers APK. Par exemple sur release APK, vous voudriez exécuter proguard (pour l’obscurcissement), le signer avec votre clé (par rapport à la clé de débogage), exécuter des optimisations (éventuellement via proguard ou d’autres outils), utiliser légèrement différent packageNames (nous utilisons com.company.product pour release et com.company.product.debug pour debug), etc. Nous utilisons également un indicateur de débogage (BuildConfig.DEBUG) pour désactiver la connexion à logcat (car l'application ralentit) sur release construit. Cela permet une construction debug plus rapide au cours du développement, mais également une construction release optimisée à mettre sur Play Store.
Saveur du produit: Il n'y a pas de saveur par défaut disponible (ou pour être précis, la saveur par défaut est vide/sans nom). Flavors pourrait être version gratuite ou version payée où ils ont DIFFERENT CODE . Ils partagent le même code Main, mais différentes versions (ou aucune version) de quelques fichiers ou ressources de code source.
BuildVariant: Un buildVariant est ce à quoi un APK généré correspond en réalité. Ils sont nommés comme suit (dans l'ordre) Product Flavor + Build Type = Build Variant.
Exemple 1: si vous avez free et paid comme deux saveurs. Les variantes de construction que vous obtiendrez sont:
Free - debug
Gratuit - Libération
Payé - débogage
Payé - Libération
Soit donc 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/pas de saveurs) Vous avez 2 buildVariants ou APK disponibles, car la saveur par défaut est sans nom/vide:
déboguer
Libération
Comparez ceci avec structure de projet d'Intellij si cela vous aide:
Le dossier .idea (1) contient un certain nombre de sous-dossiers, principalement avec des informations internes IntelliJ IDEA.
Le dossier src (2) contient le fichier MyActivity.Java (3) code source du fichier 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 de valeurs (6) est destiné au stockage de fichiers .xml décrivant des ressources de types variés. Actuellement, le dossier contient un fichier strings.xml avec les définitions de ressources String. Comme vous le verrez dans la section Ajouter une couleur, le dossier de présentation peut également contenir, par exemple, un descripteur de couleurs.
Le dossier pouvant être dessiné (7) contient des images.
Le dossier gen (8) contient le fichier R.Java (9) ==) == qui relie les ressources visuelles et le fichier Java code source. 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.
Android Studio: app\build\source\r\debug\com.example.app\R.Java
Pourquoi ces chemins sont-ils différents? Pourquoi mon R.Java se trouve-t-il dans un dossier de débogage sous Android Studio? Cela a conduit à des erreurs dès le début, et si quelqu'un avait une idée de ces différences, je les apprécierais.
Autrement dit, Android Studio est configuré pour créer un type de débogage Build) sur votre système.
Eclipse/ADT est conçu pour prendre en charge une seule construction à la fois (d'après ce que je peux dire). L'un des principaux objectifs du nouveau système de construction ( d'après le guide de l'utilisateur ):
Make it easy to create several variants of an application,
either for multi-apk distribution or for different flavors of an application
Donc, là où Eclipse/ADT pourrait générer un fichier R.Java, Android Studio prend en charge plusieurs fichiers. Le R.Java généré est situé dans le dossier debug car, par défaut, le nouveau système de construction prend en charge les types debug et release dès le départ. Si vous avez modifié votre variante de construction (bouton, coin inférieur gauche de AS) pour libérer AS générera R.Java dans le répertoire release.
Cela pourrait ne rien signifier pour des projets simples, mais le support de Variantes de construction signifie une simplification drastique du processus de construction pour de nombreuses développeurs, y compris le projet sur lequel je travaille.
Notre projet prend en charge 4 versions avec 2 types de construction (débogage et version), pour un total de 8 combinaisons APK différentes. Et chacune de ces combinaisons ayant des configurations légèrement différentes, ce système de construction a vraiment fonctionné pour nous. Mon studio Android est installé sur un autre ordinateur, mais si la mémoire est correctement utilisée, le fichier R.Java existe dans build/source/<flavor>/r/<build type>/package/R.Java. Lorsque notre serveur de CI crée les fichiers APK, il utilise chacun de ces fichiers R.Java pour générer des packages distincts.
Google interrompre le support pour le Android Developer Tools (ADT) dans Eclipse se termine, conformément à notre annonce. Vous devez migrer vos projets de développement d'applications vers Android Studio dès que possible. Pour plus d'informations sur la transition vers Android Studio, reportez-vous à la section Migration vers Android Studio.
Donc, mieux pour Android outil de développement pour Android Studio uniquement pour tout support futur de Android M ---