Struttura del progetto Android Studio (rispetto alla struttura del progetto di Eclipse)

Sto cercando di imparare lo sviluppo di Android e sono inizialmente confuso dalle diverse strutture di progetto tra Eclipse e Android Studio. Ciò rende difficile seguire le esercitazioni progettate per Eclipse. Qualcuno potrebbe farmi sapere perché esistono queste differenze? Dovrebbero esistere?

Ad esempio, se dovessi individuare il file R.java nei due IDE diversi, i percorsi sarebbero simili a questo:

Eclipse: app \ gen \ com.example.app \ R.java

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

Perché questi percorsi sono diversi? Perché il mio R.java si trova in una cartella di debug in Android Studio? Questo ha portato ad alcuni errori nelle prime fasi e se qualcuno avesse qualche idea su queste differenze le apprezzerei.

Il mistero: la struttura del progetto e il sistema di costruzione di Android Studio

Non so se questo è dovuto al Gradle Build System (scommetto che lo sia), ma ti dirò quello che ho capito finora.

Aggiornamento 4: 2014/09/11 Aggiunto Cheat Sheet per BuildTypes , Flavors e Variants (finalmente mi sento sicuro di scrivere questo: D)
Aggiornamento 3: 2014/09/11 Aggiornate le aree di confronto e i progetti per essere precisi
Aggiornamento 2: 2014/04/17 Aggiunti ulteriori dettagli alla struttura del progetto AS
Aggiornamento 1: 2013/07/29 Aggiunta della struttura del progetto IntelliJ

La struttura del progetto IntelliJ (mostrata alla fine) è per IntelliJ con il plug-in Android. Android Studio, tuttavia, ha una struttura di progetto divisa in questo modo:

Struttura: progetti e moduli

modulo in Android Studio è come un progetto in Eclipse

progetto in Android Studio è come uno spazio di lavoro in Eclipse (per essere precisi, uno spazio di lavoro con progetti interdipendenti)

Dalla documentazione (Android Studio è basato su Intellij IDEA):

Qualunque cosa tu faccia in IntelliJ IDEA, lo fai nel contesto di un progetto. Un progetto è un’unità organizzativa che rappresenta una soluzione software completa.

Il tuo prodotto finito può essere scomposto in una serie di moduli separati e discreti, ma è una definizione di progetto che li riunisce e li lega in un tutto più grande.

Per Android, significa un progetto per app e un modulo per libreria e per app di test.

Esistono diversi problemi se si tenta di creare più app all’interno dello stesso progetto. È ansible, ma se provi (come ho fatto io), vedrai che quasi tutto è progettato per funzionare con una singola app per progetto.

Ad esempio, esiste un’opzione per “ribuild il progetto”, che non ha senso con più app, molte altre impostazioni del progetto sarebbero inutili e il sistema VCS integrato non è eccezionale quando si hanno più repository.

Struttura: struttura della cartella

Struttura del progetto Android Studio

Cartelle di primo livello

1. Progetto principale

Questo sarebbe l’intero contesto del progetto ( Eclipse Land: come il tuo spazio di lavoro ma limitato a ciò che è rilevante per il tuo progetto). Es: HelloWorldProject se il nome dell’applicazione che hai fornito era HelloWorld

2. .idea

Questo in cui i metadati specifici del progetto vengono archiviati da Android Studio (AS). ( Eclipse Land: file project.properties )

3. Modulo del progetto

Questo è il vero progetto. ex: HelloWorld se il nome della tua applicazione è stato HelloWorld

4. gradle

Questo è dove il jar wrapper del sistema gradle build cioè questo jar è il modo in cui AS comunica con gradle installato in Windows (il sistema operativo nel mio caso).

5. Librerie esterne

Questa non è in realtà una cartella ma un luogo in cui vengono mostrate le Biblioteche di riferimento ( Eclipse Land: Biblioteche di riferimento). Ecco dove viene mostrata la Piattaforma Targeted ecc.

[ Nota a margine: questo è il caso in cui molti di noi in Eclipse Land hanno usato per cancellare le librerie di riferimento e correggere le proprietà del progetto per correggere gli errori di riferimento, ricorda?]

Cartella del progetto in dettaglio

Questo è il numero 3 nell’elenco sopra. Ha le seguenti sub dir

1. build

Questo ha tutto l’output completo del processo di make , ad esempio classs.dex, classi e risorse compilate, ecc.

Nella GUI di Android Studio, vengono mostrate solo alcune cartelle. La parte importante è che il tuo R.java si trova qui sotto build/source//r///R.java

2. librerie

Questa è la cartella di librerie standard che vedi anche in eclipse land

3. src

Qui, si vede solo la cartella java e res che corrisponde alla cartella src e alla cartella res in Eclipse Land . Questa è una benvenuta semplificazione IMHO.

Nota sui moduli:

I moduli sono come i progetti di Eclipse Land . Qui l’idea è di avere un progetto di applicazione (Modulo # 3 nella lista sopra) e diversi progetti di libreria (come moduli separati nella cartella di progetto globale (n. 1 nell’elenco precedente)) da cui dipende il progetto dell’applicazione. Come questi progetti di biblioteca possono essere riutilizzati in altre applicazioni, non l’ho ancora scoperto.

[ Nota a margine: l’intera riorganizzazione presenta alcuni vantaggi come le semplificazioni nella cartella src, ma tante complicazioni. Le complicazioni sono dovute principalmente alla documentazione MOLTO MOLTO su questo nuovo layout di progetto.]

Il nuovo sistema di costruzione

Guida per l’utente per il nuovo sistema di creazione

Spiegazione di sapori e buildTypes, ecc. – Di cosa parla il hullabaloo?

CheatSheet per sapori e buildTypes

BuildType: debug e release sono buildTypes disponibili per impostazione predefinita su tutti i progetti. Sono per la costruzione / compilazione dello SAME CODE per generare APK diversi. Per esempio sugli APK di release si vorrebbe eseguire proguard (per offuscamento), firmarlo con la propria chiave (come contro la chiave di debug), eseguire ottimizzazioni (magari tramite proguard o altri strumenti), usare un packageNames leggermente diverso (usiamo com.company.product for release e com.company.product.debug per debug ), ecc. Usiamo anche un flag di debug ( BuildConfig.DEBUG ) per distriggersre la registrazione su logcat (dato che rende l’app lenta) sulle build di release . Ciò consente una build di debug più veloce durante lo sviluppo, ma anche un build di release ottimizzato da mettere in play store.

Sapore prodotto: non sono disponibili aromi predefiniti (o per essere precisi, l’aroma predefinito è vuoto / senza nome). Flavors potrebbero essere versione gratuita o versione a pagamento dove hanno DIVERSO CODICE . Condividono lo stesso codice Main ma versioni diverse (o nessuna versione) di alcuni file o risorse di codice sorgente.

BuildVariant: Un buildVariant è ciò a cui corrisponde effettivamente un APK generato. Si chiamano così (in ordine) Product Flavor + Build Type Build Variant = Build Variant .
Esempio 1: se hai free e paid come due sapori. Le varianti di build che otterresti sono:
Libero – debug
Liberatoria
Pagato – debug
A pagamento
Quindi sono 4 le possibili configurazioni di APK. Alcune configurazioni potrebbero non avere senso in un particolare progetto, ma sono disponibili.

Esempio 2: (per nuovi progetti / senza sapori) Sono disponibili 2 buildVariants o APK, poiché l’impostazione predefinita è senza nome / vuota:
mettere a punto
pubblicazione

Confronta questo con la struttura del progetto di Intellij se questo aiuta:

Istantanea della struttura del progetto Intellij

La cartella .idea (1) contiene un numero di sottocartelle, principalmente con informazioni interne IntelliJ IDEA.

La cartella src (2) contiene il codice sorgente del file MyActivity.java (3) che implementa la funzionalità dell’applicazione. Il file appartiene al pacchetto com.example.

La cartella res (4) contiene varie risorse visive.

Il file layout / main.xml (5) definisce l’aspetto dell’applicazione costituita da risorse di vario tipo.

La cartella dei valori (6) è destinata alla memorizzazione di file .xml che descrivono risorse di vario tipo. Attualmente, la cartella contiene un file strings.xml con definizioni di risorse stringa. Come vedrai dalla sezione Aggiunta di un colore, la cartella di layout può contenere anche, ad esempio, un descrittore di colors.

La cartella drawable (7) contiene immagini.

La cartella gen (8) contiene il file R.java (9) che collega le risorse visive e il codice sorgente Java. Come vedrete dalle sezioni seguenti, IntelliJ IDEA supporta una stretta integrazione tra le risorse statiche e R.java. Non appena vengono aggiunte o rimosse risorse, le corrispondenti classi e campi di classi in R.java vengono automaticamente generati o rimossi di conseguenza. Il file R.java appartiene anche al pacchetto com.example.

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

Perché questi percorsi sono diversi? Perché il mio R.java si trova in una cartella di debug in Android Studio? Questo ha portato ad alcuni errori nelle prime fasi e se qualcuno avesse qualche idea su queste differenze le apprezzerei.

In poche parole, Android Studio è configurato per creare un tipo di build di debug sul tuo sistema.

Eclipse / ADT è progettato per supportare una singola build alla volta (da quello che posso dire). Uno degli obiettivi principali del nuovo sistema di build ( dalla guida dell’utente ):

 Make it easy to create several variants of an application, either for multi-apk distribution or for different flavors of an application 

Quindi, come Eclipse / ADT potrebbe generare un file R.java , Android Studio supporta più. R.java generato si trova nella cartella di debug perché per impostazione predefinita il nuovo sistema di build supporta il debug e release tipi di build al di fuori del blocco. Se hai modificato la variante di build (pulsante, angolo in basso a sinistra di AS) per rilasciare AS, genererai R.java nella directory di release .

Questo potrebbe non significare nulla per progetti semplici, ma il supporto di Build Varianti significa una drastica semplificazione del processo di compilazione per molti sviluppatori, incluso il progetto su cui sto lavorando.

Il nostro progetto supporta 4 sapori con 2 tipi di build (debug e release), per supportare un totale di 8 diverse combinazioni di APK. E ognuna di queste combinazioni ha configurazioni leggermente diverse, quindi questo sistema di costruzione ha funzionato davvero per noi. Il mio studio Android è installato su una macchina diversa, ma se la memoria serve correttamente, il file R.java esiste in build/source//r//package/R.java . Quando il nostro server CI crea i file APK, utilizza ciascuno di questi file R.java per generare pacchetti separati.

Google interrompe il supporto per gli Strumenti per sviluppatori Android (ADT) in Eclipse che termina, come da nostro annuncio. Dovresti eseguire la migrazione dei tuoi progetti di sviluppo di app su Android Studio il prima ansible. Per ulteriori informazioni sulla transizione a Android Studio, vedere Migrazione ad Android Studio.

Quindi la cosa migliore per lo strumento di sviluppo Android per Android Studio solo per tutto il futuro supporto di Android M —

Per Android Studio 3.0.1 e tutte le funzionalità selezionate:

  • Android O più recente
  • Android Auto
  • Cose Android
  • Abbigliamento Android
  • Android TV
  • Supporto C ++
  • Supporto Kotlin

La struttura nella versione 3.0.1 non sembra affatto come tutte le altre risposte.

La struttura recente è visualizzata nel 2018, Android Studio 3.0.1 01/2018.

Newbie kinda ha trovato qualcosa di simile a utilizzabile nella sottocartella di funzionalità:

Aggiorna il tuo Android Studio 3.0.1 01_2018:

ToolTip: