Il mistero: struttura del progetto e sistema di costruzione di Android Studio
Non so se ciò sia dovuto al Gradle Build System (scommetto che lo sia), ma ti dirò cosa ho capito finora.
Aggiornamento 4: 2014/09/11 Aggiunto Cheat Sheet per BuildTypes, Flavorse Variants(finalmente mi sento fiducioso di scrivere questo: D)
Aggiornamento 3: 2014/09/11 Aggiornati gli spazi di lavoro e i progetti di confronto per la precisione
Aggiornamento 2: 2014/04/17 Aggiunti ulteriori dettagli alla struttura del progetto AS
Aggiornamento 1: 2013/07/29 Aggiunta struttura del progetto IntelliJ
La struttura del progetto di IntelliJ (mostrata alla fine) è per IntelliJ con il plugin Android. L'Android Studio, invece, ha una struttura di progetto così suddivisa:
Struttura: progetti e moduli
il modulo in Android Studio è come un progetto in Eclipse
il 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, la 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 isolati, ma è una definizione di progetto che li riunisce e li lega in un insieme più grande.
Per Android, significa un progetto per app e un modulo per libreria e per app di test.
Ci sono più problemi se provi a creare più app nello stesso progetto. È possibile, ma se ci provi (come ho fatto io), vedrai che quasi tutto è progettato per funzionare con una singola app per progetto.
Ad esempio, esiste un'opzione per "ricostruire 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 delle cartelle
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: HelloWorldProjectse il nome dell'applicazione che hai fornito eraHelloWorld
2. .idea
Qui i metadati specifici del progetto vengono archiviati da Android Studio (AS). ( Eclipse Land: project.properties file)
3. Modulo di progetto
Questo è il progetto vero e proprio. es: HelloWorldse il nome della tua applicazione che hai fornito era HelloWorld
4. gradle
Qui è dove il wrapper jar del sistema di build gradle, cioè questo jar, è il modo in cui AS comunica con gradle installato in Windows (il sistema operativo nel mio caso).
5. Biblioteche esterne
Questa non è in realtà una cartella, ma un luogo in cui vengono mostrate le Biblioteche referenziate ( Eclipse Land: Biblioteche referenziate). Qui è dove viene mostrata la piattaforma mirata, ecc.
[ Nota a margine: qui molti di noi in Eclipse Land erano soliti eliminare le librerie di riferimento e correggere le proprietà del progetto per correggere gli errori di riferimento, ricordi?]
Cartella del progetto in dettaglio
Questo è il numero 3 nell'elenco sopra. Ha le seguenti directory secondarie
1. build
Questo ha tutto l'output completo del makeprocesso cioè classes.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 sottobuild/source/<flavor>/r/<build type(optional)>/<package>/R.java
2. libs
Questa è le librerie standard di cartella che si vede in paese eclisse troppo
3. src
Qui, vedi solo la cartella javae resche corrisponde alla srccartella e alla rescartella in Eclipse Land . Questa è una semplificazione molto apprezzata IMHO.
Nota sui moduli:
I moduli sono come i progetti Eclipse Land . Qui l'idea è che tu abbia un progetto applicativo (Modulo # 3 nell'elenco sopra) e diversi progetti di libreria (come moduli separati nella cartella del progetto globale (# 1 nell'elenco sopra)) da cui dipende il progetto dell'applicazione. Come questi progetti di libreria possano essere riutilizzati in altre applicazioni, non l'ho ancora scoperto.
[ Nota a margine: l'intera riorganizzazione ha alcuni vantaggi come le semplificazioni nella cartella src, ma tante complicazioni. Le complicazioni sono dovute principalmente alla documentazione MOLTO MOLTO sottile su questo nuovo layout del progetto.]
Il nuovo sistema di build
Guida per l'utente per il nuovo sistema di compilazione
Spiegazione di sapori e buildTypes, ecc - Di cosa parla il clamore?
CheatSheet per sapori e buildTypes
BuildType: debug e releasesono buildTypesdisponibili per impostazione predefinita su tutti i progetti. Servono per costruire / compilare lo STESSO CODICE per generare diversi APK. Ad esempio su releaseAPK vorresti eseguire proguard (per offuscare), firmarlo con la tua chiave (rispetto alla chiave di debug), eseguire ottimizzazioni (magari tramite proguard o altri strumenti), utilizzare leggermente diversi packageNames(usiamo com.company.productper releasee com.company.product.debugper debug), ecc. Usiamo anche un flag di debug ( BuildConfig.DEBUG) per disattivare la registrazione su logcat (poiché rallenta l'app) nelle releasebuild. Ciò consente una debugbuild più veloce durante lo sviluppo ma anche una releasebuild ottimizzata da inserire nel Play Store.
Sapore del prodotto: non sono disponibili gusti predefiniti (o per essere precisi, il sapore predefinito è vuoto / senza nome). Flavorspotrebbe essere la versione gratuita o la versione a pagamento in cui hanno CODICE DIVERSO . Condividono lo stesso Maincodice ma versioni diverse (o nessuna versione) di alcuni file di codice sorgente o risorse.
BuildVariant: A buildVariantè ciò a cui corrisponde effettivamente un APK generato. Sono chiamati così (in ordine) Product Flavor+ Build Type=Build Variant .
Esempio 1: se hai freee paidcome due gusti. Le varianti di build che otterresti sono:
Free - debug
Free - release
Paid - debug
Paid - release
Quindi ci sono 4 possibili configurazioni APK. Alcune configurazioni potrebbero non avere senso in un particolare progetto, ma sono disponibili.
Esempio 2: (per nuovi progetti / nessuna versione) Sono disponibili 2 buildVariantso APK, poiché la versione predefinita è senza nome / vuota:
versione di
debug
La cartella .idea (1) contiene una serie di sottocartelle, principalmente con informazioni interne di 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 le definizioni delle risorse String. Come vedrai dalla sezione Aggiunta di un colore, la cartella del layout può anche contenere, ad esempio, un descrittore di colori.
La cartella disegnabile (7) contiene immagini.
La cartella gen (8) contiene il file R.java (9) che collega le risorse visive e il codice sorgente Java. Come vedrai dalle sezioni seguenti, IntelliJ IDEA supporta una stretta integrazione tra risorse statiche e R.java. Non appena le risorse vengono aggiunte o rimosse, le classi ei campi di classe corrispondenti in R.java vengono automaticamente generati o rimossi di conseguenza. Anche il file R.java appartiene al pacchetto com.example.
