J'essaie d'apprendre le développement Android et je suis d'abord confus par les différentes structures de projet entre Eclipse et Android Studio. Cela rend difficile de suivre les didacticiels conçus pour Eclipse. Quelqu'un pourrait-il me dire pourquoi ces différences existent? Devraient-ils exister?

Par exemple, si je devais localiser le fichier R.java dans les deux IDE différents, les chemins ressembleraient à ceci:

Éclipse: 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 est-il situé dans un dossier de débogage dans 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: 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

Comparez cela avec la structure de projet d' Intellij si cela 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 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.

Android Studio: app \ build \ source \ r \ debug \ com.example.app \ R.java

Pourquoi ces chemins sont-ils différents? Pourquoi mon R.java est-il situé dans un dossier de débogage dans 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.

En termes simples, Android Studio est configuré pour créer un type de build de débogage sur votre système.

Eclipse / ADT est conçu pour prendre en charge une seule version à la fois (d'après ce que je peux dire). L'un des principaux objectifs du nouveau système de construction (à partir du 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

Alors, là où Eclipse / ADT pourrait générer un R.javafichier, Android Studio prend en charge plusieurs. Le généré R.javaest situé dans le debugdossier car, par défaut, le nouveau système de construction prend en charge debuget les releasetypes de construction dès le départ. Si vous avez changé votre variante de construction (bouton, coin inférieur gauche de AS) pour libérer AS générera R.javadans le releaserépertoire.

Cela peut ne rien signifier pour des projets simples, mais la prise en charge des variantes de construction signifie une simplification drastique du processus de construction pour de nombreux développeurs, y compris le projet sur lequel je travaille.

Notre projet prend en charge 4 versions avec 2 types de build (débogage et publication), pour prendre en charge un total de 8 combinaisons d'APK différentes. Et chacune de ces combinaisons a des configurations légèrement différentes, donc ce système de construction a vraiment fonctionné pour nous. Mon studio Android est installé sur une machine différente, mais si la mémoire me sert correctement, le R.javafichier existe build/source/<flavor>/r/<build type>/package/R.java. Lorsque notre serveur CI crée les fichiers APK, il utilise chacun de ces R.javafichiers pour générer des packages séparés.

Google Arrêtez la prise en charge des outils de développement Android (ADT) dans Eclipse, 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, consultez Migration vers Android Studio.

Donc, le meilleur pour l'outil de développement Android pour Android Studio uniquement pour tous les futurs supports d' Android M ---

Pour Android Studio 3.0.1 et sélectionné toutes les fonctionnalités:

• Android O dernier
• Android Auto
• Choses Android
• Usure Android
• Android TV
• Prise en charge du C ++
• Assistance Kotlin

La structure de la version 3.0.1 ne ressemble pas du tout à toutes les autres réponses.

La structure récente est celle affichée en 2018, Android Studio 3.0.1 01/2018.

Le débutant a en quelque sorte trouvé quelque chose qui ressemble à utilisable dans le sous-dossier des fonctionnalités:

Mettez à jour votre Android Studio 3.0.1 01_2018:

Info-bulle: