(musica leggera per pianoforte)
– Il mio nome è Etienne. Lavoro per Gradle.
Sto conducendo il progetto di bill bill
(il nostro sforzo per integrarsi con Eclipse).
Sono anche co-leader degli sforzi di Gradle.com,
che è la nostra soluzione di base Sass
che uscirà presto.
L’obiettivo di oggi è darti più informazioni
nella build di Gradle,
e come si riferisce alla build di Android.
Ma prima di iniziare,
Vorrei chiederti:
Chi sta facendo lo sviluppo di Android,
che sta ascoltando?
La maggior parte delle persone, direi il 90%.
Chi sta usando Android Studio?
Forse dovrei chiedere il contrario.
Chi non sta utilizzando Android Studio?
Forse 5 mani, o giù di lì.
Chi ha toccato la build Gradle?
Interessante.
Direi forse due terzi.
Ho sempre fatto quella domanda, e ogni volta che lo chiedo sale.
Non sono sicuro che sia un buon segno o no.
Io penso che sia.
E chi sta usando Gradle al di fuori di un progetto Android?
Sviluppo Java, Scala.
Forse cinque mani.
Questo è venuto fuori.
Qual è la motivazione
per parlare di Gradle e Android:
è solo un sistema di costruzione.
Perché questo grande affare di fare questa scelta,
e non un altro
Voglio parlarne ancora un po ‘
per darti un po ‘di contesto.
La build di Android è implicitamente molto complessa.
Se lo si confronta con un solo progetto Java,
La build di Android è più complessa.
Puoi anche vederlo su questo grafico a lato
(da Xavier, Android Lead).
È una semplificazione di ciò che accade
durante la build di Android, potenzialmente.
E non include nemmeno tutto.
C’è complessità implicata,
più che compilare
Hai i tuoi corsi, li carteggi,
e hai finito.
In genere quando si esegue lo sviluppo di Android
fai parte di una squadra,
e non tutti potrebbero fare cose Android
su quella squadra.
Potresti anche avere una squadra di back-end.
stanno facendo Java o Scala;
rapidamente hai più lingue
(Java, Android, ecc.).
Questo deve essere parte di esso pure.
Hai una generazione di risorse,
estrazione di artefatti,
e conversione ad altri artefatti.
Devi splatare dalla diversità.
Tutta la frammentazione
che tu sicuramente sai meglio di me.
Ma è lì.
C’è complessità
coinvolto nel gestire la build di Android.
E se guardi a questa complessità su questo grafico qui,
espressività contro concisione,
puoi vedere che con Ant puoi essere molto espressivo,
puoi fondamentalmente fare tutto.
Formica
è molto espressivo,
ma cresce anche rapidamente.
Devi dirlo con i dettagli su cosa fare.
Dall’altra parte hai Maven, che è molto conciso,
è un approccio basato su XML.
È conciso, ma non molto espressivo.
A tutti voi che avete una build personalizzata
sapere quanto velocemente arrivi ai tuoi limiti.
Gradle combina i due.
È conciso.
Sto per darti un esempio
(anche molto espressivo).
In questo esempio qui,
questa è una build Android completamente autonoma.
Sapori diversi prodotti,
due dimensioni di sapore
combinato con un tipo di build;
un’esplosione di prodotti incrociati.
Ciò porta a compiti.
(Non sono sicuro,
forse nella prima fila puoi ancora leggerlo).
(Posso. Ma sicuramente non nell’ultima riga).
Finisci con 300 attività.
Voglio mostrare
il DSL molto conciso
(le cose accadono dietro le quinte).
Se volevi ottenere lo stesso con Ant,
dovresti scrivere di più
per ottenere lo stesso risultato.
Con Maven, non so come lo faresti.
Per quanto riguarda le lingue.
Hai più lingue.
In genere hai anche più team.
E poi vuoi collaborare agli stessi software.
Quindi vuoi un sistema di costruzione
che ti consente di interagire tra i diversi team.
Gli artefatti vengono consumati, vengono prodotti.
Vuoi anche avere queste versioni coordinate.
Anche prima del rilascio.
Se cambi qualcosa nel back end,
vuoi sapere se questo influenza il tuo generale
applicazione che include una parte Android o no.
Hai bisogno di questa versione coordinata,
e questo è davvero uno dei punti di forza di Gradle:
un grande progetto,
con sotto-progetti e lo lega, tutti insieme.
Alla fine non si modella l’APK.
Formi un prodotto,
e c’è più coinvolto,
anche oltre a costruire questo artefatto,
quindi vuoi fare uscite automatiche,
inviare e-mail di rilascio,
fare tutto il provisioning degli ambienti di sviluppo.
Potresti creare un test,
qualche documentazione con codice di prova.
O codice che è stato testato
modo automatico.
(c’è molto da fare).
Per darti un esempio:
Linkedin, un grande utente di Gradle.
2.000 sviluppatori,
2.000 componenti,
e fanno circa 300.000 build a settimana,
e 1.000 release costruisce un giorno.
Se vedi quella scala,
probabilmente non è la scala di tutti quelli che lavorano,
o in quella stanza ora,
ma se lavori in un simile ambiente,
se hai una build molto disconnessa,
artefatti qua e là, e poi tu solo
in qualche modo, metterlo insieme,
non sta andando in scala.
Diamo un’occhiata al sistema di build di Android.
Il sistema di build di Android è
un bel pezzo di software secondo me.
Perché prende il meglio della lettura di cose diverse.
Utilizza l’IDE di Android Studio,
è la tua interfaccia utente,
basato sulla piattaforma IntelliJ.
Hai il plugin Android Gradle,
che è quindi di nuovo basato sulla piattaforma Gradle.
E tu hai gli strumenti Android.
Vogliamo guardare oggi
l’Android Gradle Plugin
e la piattaforma Gradle,
e trattarli come uno.
Alla fine,
Non ti importa; quando la tua build è lenta,
se si tratta del plug-in Android o è la build Gradle.
La tua build è solo lenta?
O è veloce, ma poi non ti interessa neanche.
Ciò che lo rende così bello
sul sistema di build Android
è che c’è un’unica fonte di verità
quando si tratta della logica di costruzione.
La build è l’unico posto
che definisce cosa fa la tua build.
Non c’è niente in più nell’IDE.
Quando apri il tuo progetto,
non vai nel tuo IDE e dici
Ho anche bisogno di questa libreria e di quella libreria.
Questo è tutto definito dalla build.
È visionario,
prima non era stato fatto.
Tu fai
configurazione in Eclipse,
(ad esempio, prima Eclipse con Ant).
Dovevi fare tutto in Eclipse per lo sviluppo Android.
Per definire cosa
dipendenze che usi,
lo fai nella tua build.
Dove sono le mie fonti.
Lo fai nella build,
ma non nell’IDE.
L’IDE verrà configurato in base al modello.
Te lo mostrerò un po ‘più in dettaglio.
In alto a sinistra vedi Android Studio,
questo sei tu, lo sviluppatore, che lavora su Android Studio,
Alla fine, dal momento della costruzione,
Gradle è l’unico posto che ha la logica di costruzione.
Deve comunicare con Gradle
per capire cosa deve presentare / fare.
Ciò avviene tramite l’API di Tooling.
Qualcuno sa che cos’è l’API degli strumenti?
O che esiste?
Nessuno.
È interessante.
Quando hai Android Studio,
la build di Gradle, il modo in cui parlano tra loro
è attraverso una libreria chiamata tooling API.
L’API degli strumenti risiede in Android Studio
(sul percorso classe dell’IDE).
Attraverso la comunicazione di interprocessi,
parla con la build di Gradle.
La build di Gradle
(Demone Gradle)
è un processo separato.
Se vuoi compilare,
l’interstudio indicherà l’API degli strumenti, compilerà,
e l’API degli strumenti parlerà con il demone
attraverso la comunicazione di interprocessi.
Demone
compilerà quella build con quell’attività.
È così che funziona.
Se vieni dalla riga di comando,
continui a interagire con Gradle. Con
il demone Gradle, se lo hai abilitato,
ma tu vieni semplicemente attraverso un modo diverso
(il programma di avvio).
Non si entra attraverso l’API degli strumenti,
ma attraverso il launcher.
Se si è in un server di integrazione continua,
coinvolgi anche Gradle direttamente.
Tutto ciò funziona
perché Gradle è l’unica fonte
di verità quando si tratta di costruire la logica.
Ognuno porta Gradle.
Quali sono i miei progetti?
Qual è il mio percorso di classe compilato?
Qual è il mio test compila il percorso di classe, eccetera.
Per approfondire un po ‘di più,
l’API degli strumenti (in verde).
È un proxy
per aver parlato con Gradle.
Vedremo alcuni dei benefici nella prossima slide.
C’è anche un meccanismo per fornire modelli personalizzati.
Questo è esattamente ciò che accade con Android.
In che modo Android ottiene tutte le informazioni
ha bisogno dalla build
che può presentarlo nell’IDE,
o configurare l’IDE
(il tuo modello personalizzato).
Android chiede Gradle, per favore dammi quella modella
per Android.
Android, la modella ritorna
e contiene tutte le informazioni sulle varianti,
e i sapori.
L’IDE può consumarlo
e configurare l’IDE di conseguenza.
Se vuoi guardarlo,
è il progetto Android predefinito che è il modello.
(questo è quello che fanno i ragazzi Android)
Scrivono un modello,
fornire un plugin.
Questo è ciò che fornisci sempre nella tua sceneggiatura?
Dice plugin di alimentazione qualcosa di Android,
e registra quel modello.
Puoi chiedere quel modello
attraverso l’API degli strumenti.
C’è il client VM (l’IDE).
Questo è il piccolo file del lavoro di routine
(800 k o giù di lì).
Chiede a Gradle, attraverso l’API degli strumenti,
dammi quel modello di costruzione o invoca alcune attività.
Costruisci modelli che chiedi,
per configurare l’IDE.
Invocare compiti di compilazione
eseguire qualcosa nella build.
Alcuni dei vantaggi di questo approccio
è la retrocompatibilità.
Anche se la build Gradle utilizzata fosse 1.0,
potresti ancora parlarci.
Potresti non avere tutte le funzionalità disponibili,
ma è ancora compatibile.
Hai isolamento Runtime.
Diciamo che Gradle ha avuto una perdita di memoria.
Ciò non influirebbe su Android Studio,
perché è un processo diverso.
Se Android Studio ha avuto una perdita di memoria,
Gradle non ne risentirebbe
perché è un processo diverso.
(Due lati per guardarlo).
Ci sono alcuni servizi di alto livello,
in modo da poter cancellare una build.
Questo vale per l’API degli strumenti,
qualunque cosa faccia, la fermerà.
Ha una modalità continua.
Lo mostrerò più tardi.
E puoi anche eseguire test.
Android Studio non lo sta usando,
ma penso che lo faranno ad un certo punto.
Se hai un’API specifica su di esso quando esegui un test,
che il test è eseguito da Gradle.
Il che ha senso,
perché solo Gradle sa qual è il percorso di classe, eccetera,
per eseguire quel test.
L’IDE non lo sa davvero.
Può solo fare un’approssimazione.
C’è un modello di evento,
man mano che esegui una build attraverso l’API degli strumenti, ottieni eventi.
Ovviamente si ottiene tutto il registro.
Ottieni progressi.
Ma hai anche eventi come
la fase di configurazione inizia, si ferma.
La fase di esecuzione inizia, si ferma.
I test sono iniziati. I test sono finiti o falliti, eccetera.
Tutto ciò è consumabile attraverso l’API degli strumenti.
E se hai guardato su costruire shaper
o integrazione di Gradle per Eclipse,
vedresti che se, quando sei sulla build,
vedi un albero che ti mostra
tutti questi eventi accadono.
Perché tutto questo è possibile?
Gradle ha un modello molto ricco.
Avendo un modello ricco, conosce tutte queste cose.
Sa cosa significano.
Con quelle informazioni c’è così tanto che puoi fare.
Se si confronta questo con una build Ant,
e non dirò nulla contro Ant,
ma quando fai qualcosa con Ant,
La stessa Ant non sa cosa stai facendo.
È molto imperativo
Non c’è modo di fornire questi ricchi modelli
come sono, è il caso di Gradle.
Per quanto riguarda la perfomance.
Tutti vogliamo che le prestazioni siano velocissime.
Ho usato questa immagine perché usa anche
lampo parallelo che va dall’alto verso il basso.
Qual è l’aspetto chiave della performance:
fare le cose in parallelo.
Qual è il nostro obiettivo?
Il nostro obiettivo è ridurre al minimo il tempo di costruzione,
per dirlo in un modo semplice.
Usando la poca memoria necessaria.
Perché?
Vogliamo un riscontro più rapido sui dati di costruzione.
Vogliamo fare più build al giorno.
Vogliamo fare più uscite al giorno.
E vogliamo fare più round sull’integrazione continua.
(e molte altre ragioni).
Ci sono molti più motivi per cui vogliamo avere build veloci.
Quando fai lo sviluppo,
da un round a quello successivo,
di solito non ci sono molti cambiamenti nella tua build.
Potresti avere questa build complessa,
ma cosa fai di solito?
Si modificano alcuni file sorgente.
Tu cambi alcuni test.
Forse una volta ogni tanto rimuovi una risorsa
o ne aggiungi uno.
Oppure aggiungi una dipendenza o cambia una dipendenza
ma questo è già raro.
Non lo fai per ogni build.
Tra queste serie di test consecutive,
tipicamente non molti cambiamenti.
E se non ci sono molti cambiamenti, non dovrebbe esserci molto
essere lavorato dalla build.
Quando piccoli cambiamenti nella build,
poco lavoro dovrebbe essere fatto.
Questo è qualcosa che tu attualmente
vedi nel plugin Android,
Questo non è il caso.
Anche se hai un grande progetto Android,
Gradle task, o Gradle help,
ci vorrà un po ‘, e quella volta
è proporzionale alla dimensione della build.
E non dovrebbe essere, perché quando dici aiuto Gradle,
non stai nemmeno eseguendo nulla nella tua build.
Quando costruisci, fallo
impiegano più tempo di quanto tu vorresti che prendessero?
Sì, annuendo.
Questo è, per la maggior parte,
a causa della fase di configurazione.
arriveremo a questo.
qual è l’approccio a Gradle
migliorare le prestazioni?
che si applica alla prospettiva di Android,
ma anche a tutti gli altri a Gradle
che non sono correlati ad Android.
Due approcci.
Uno è quello evolutivo.
Fai piccoli miglioramenti qua e là.
Potrebbero avere un impatto significativo.
e lo mostrerò in un grafico più avanti.
C’è anche il modo di dire
facciamo qualche cambiamento rivoluzionario
per fare il prossimo passo in termini di prestazioni.
Potresti solo fare un’ottimizzazione locale,
ma non l’ottimizzazione globale altrimenti.
Questo sta accadendo attualmente. Lo vedremo.
Quando costruisci con Gradle.
Hai una build a due fasi.
Qualcuno ha familiarità con questo, che hai due fasi?
Hai una fase di configurazione e una fase di esecuzione.
Alcune persone sembrano averne familiarità.
Dici la build di Gradle o quello che chiami,
se mai vai alla riga di comando.
Accadranno due cose
La prima cosa è la fase di configurazione.
Questo è quando viene eseguita la logica di compilazione,
e il modello di costruzione è costruito.
Nella fase di esecuzione, quel modello di costruzione
viene applicato, il che significa che i compiti sono eseguiti.
Vedremo queste due fasi,
e inizierò con la fase di esecuzione.
Perché quello è quello in cui è stato fatto di più,
e poi arriveremo alla fase di configurazione.
Cosa stiamo già facendo in termini
di ottimizzazione durante la fase di esecuzione.
Uno è la funzione di build incrementale.
Se pensi alle attività, le attività hanno
ingressi e uscite in Gradle.
Il significato di un’attività consuma determinati input, come una funzione,
fa qualcosa con loro,
e produce un’uscita.
In Gradle puoi annotare o dichiarare,
quali sono gli input di un’attività e quali sono gli output.
E con queste informazioni, Gradle può fare build incrementali.
Se gli ingressi non sono cambiati e le uscite
non sono cambiati, non è necessario eseguire di nuovo quell’attività.
diciamo che hai un progetto e fai una compilazione.
Ha file sorgente, nessun file compilato.
Farà la compilation.
Ora lo esegui di nuovo.
Deve fare qualcosa se non hai cambiato la fonte
file o se non hai rimosso i file di classe?
No. Tutto è rimasto lo stesso.
E usando, per Gradle, sapere quali sono gli input
e le uscite sono che può fare quell’ottimizzazione per te.
Ecco perché, quando dici “Gradle build”, Gradle build,
se hai una build normalmente configurata, direi
lo vedi aggiornato, aggiornato, aggiornato,
e nulla è stato fatto davvero.
Che è buono, perché se nulla è cambiato,
nulla dovrebbe essere fatto.
Come ho detto prima.
Questo è solo un piccolo esempio.
se hai scritto il tuo compito, e non lo fa,
quelli di Gradle sembrano molto simili.
Ho scritto un’attività chiamata operazione di conversione,
e prende un file,
fa qualcosa con quel file,
e crea un nuovo file.
è solo una trasformazione.
Quello che fa, non importa,
è per questo che ho messo un commento lì.
Questo è come lo chiameresti nel tuo script Gradle.
Diresti solo che ho un compito,
è di questo tipo
I miei input sono uno o più file.
Sto usando solo questo, e
la mia directory di destinazione verrà riconvertita
i file scritti in questa cartella.
Ecco come lo useresti.
Usando queste annotazioni,
i file di input e la directory di output,
ora stai dicendo a Gradle cosa sono
i miei input e output.
E Gradle gestirà questi,
ne terrà traccia,
in modo che quando lo vuoi, lo farà
ricorda quali erano i valori l’ultima volta che l’hai eseguito.
Se il dispositivo è sempre lo stesso, dirà
oh questo compito è aggiornato, saltiamolo.
Chi ha usato Ant e ha usato
un approccio con timestamp per vedere se non ci sono i timestamp
sono cambiati, e quindi non lo farà?
C’è almeno una mano.
Lo facevo anche io.
Dovevo farlo ogni volta,
quando ho avuto un compito del genere
sensibile agli ingressi e alle uscite.
Qui è completamente cotto nel sistema.
è così. questa è l’attività di conversione.
Per darti un’idea
di cosa significa input e output.
Torneremo su questo concetto durante
la fase di configurazione.
Ecco perché voglio mostrarlo qui prima.
Ce n’è un altro.
Questo è un concetto così semplice.
Hai un input, hai un output.
Tieni traccia di esso o Gradle tiene traccia di esso,
e quindi puoi fare ogni sorta di cose.
Ti ho appena mostrato la funzione di build incrementale.
Un altro è la funzione di creazione continua.
Quello che puoi fare è,
e anche tu potresti farlo
con una build Android, non lo è
specifico per qualsiasi tipo di build.
Sto solo dicendo che Gradle è un involucro di Gradle,
o sarebbe Gradle.
Dico test dash t.
Dash t sta per modalità continua.
Puoi vedere
inizia a costruire, fa tutto ciò che deve fare,
anche se non avevi il trattino t,
costruire con successo. Se l’hanno fatto
qualcosa o no non importa
tempo totale, ma poi non si torna alla riga di comando
richiesta. Sta dicendo ora in attesa di cambiamenti.
Quindi sta solo aspettando lì,
e se ora cambi qualcosa che è un input
dell’attività invocata, quindi si innescherebbe automaticamente
la build e fai ciò che è necessario.
Diciamo che scrivi
documentazione usando qualcosa come Asciidoc.
Stai sempre cambiando il file,
esecuzione di Gradle build.
Cambiando il file, eseguendo la build di Gradle.
Con la modalità continua, devi solo cambiare
il tuo file e vai al browser.
Tu dici di aggiornamento ed è lì.
Non appena cambi il file sorgente,
e sta rilevando il cambiamento, lo ricostruirà
l’artefatto, e lo vedrai.
Come fa a sapere cosa hai fatto,
cosa rintracciare. Non può
ti basta seguire il tuo intero file system.
Che cosa tiene traccia dei tuoi input.
Se il tuo compito ha definito gli input,
allora sa dove cercare i cambiamenti.
Guarderà solo questi cambiamenti se accadono.
Se succedono, sa di innescare una build.
Funzionalità molto potente che è possibile
basato su questo concetto molto semplice
di dichiarare input e output.
Questa è davvero la chiave.
Più dici a Gradle quello che stai facendo,
e quello che hai, più può farlo.
Le cose più intelligenti che può fare,
senza che tu debba farli.
Potresti implementarti,
come una modalità orologio, e ci sono anche plugin per questo,
ma ora è disponibile per ogni attività che ha input.
In termini
di miglioramenti delle prestazioni,
sono applicabili anche ai progetti Android.
Puoi comandare le build;
ci sono stato per molto tempo.
Ma se hai un grande progetto, scopri se qualcosa
è cambiato o non ha richiesto molto tempo.
Doveva andare su tutti i file, crearne alcuni,
guarda i timestamp, fai qualche controllo sulle somme, eccetera.
Solo per decidere se tutto è aggiornato o meno.
O qualcosa non è aggiornato o no.
Ed è particolarmente doloroso quando lo hai
un grande progetto e nulla è cambiato.
Perché quello che farà sarà attraversato
i tuoi 400.000 file solo per realizzare
niente è cambiato
E questo richiede tempo.
Nell’ultima versione
quello è RC1 è fuori ora,
ci sono stati dei miglioramenti
alla gestione di questi file controlla somme.
Se hai un progetto molto grande,
vedrai che se non hai quasi nessun cambiamento,
sarà molto più veloce da rilevare.
Se hai un piccolo progetto,
noterai anche una differenza,
ma non è così spettacolare
come il progetto è grande.
Questo ci riporta indietro:
se è cambiato poco, poco dovrebbe accadere.
Successivo: compilazione veloce per la modalità continua.
Diciamo che stai usando quella modalità continua,
stai facendo dei cambiamenti, è sempre in costruzione
come stanno cambiando le cose.
Se stai compilando come parte di questo,
questo cambiamento accade,
Gradle genererà un demone del compilatore,
di default almeno per Java.
Gli altri che puoi configurare
usa un demone del compilatore.
Con build continue
questo demone rimarrà in vita,
anche come il giro di costruzione.
Finché la sessione di build
di un round di build continuo,
il demone del compilatore sarà lì.
Tutto ciò che è già
c’è molto più veloce da usare
che se deve partire, deve scaldarsi.
Questi sono tutti miglioramenti evolutivi.
Diamo un’occhiata alla fase di configurazione.
Se guardi i tuoi script di compilazione,
anche se in Android è dichiarativo
non appena fai le tue cose,
diventa imperativo.
Anche se non scrivi alcun codice imperativo,
cosa succede dietro la scena dal plugin Android
è abbastanza imperativo.
Potresti avere un DSL, cioè dichiarativo,
ma quello che Android deve fare è imperativo.
E non appena diventa imperativo
nel tuo codice o nel codice del plugin
Gradle non sa cosa stai facendo.
E se non sa cosa stai facendo,
non può ottimizzare le cose.
Cosa fanno le persone?
Fanno cose pigramente perché
non dovrebbe accadere presto,
O usare collezioni pigre.
Rilevano tutti i cambiamenti che verranno dopo.
Oppure usano il progetto dopo la valutazione,
che è un gancio dove ti permette
per dire, la fase di configurazione è finita,
ora lasciami fare qualcosa.
Cosa succede se più persone aggiungono tale gancio?
Chi è aggiunto, chi sarà chiamato per primo,
chi verrà chiamato l’ultimo.
C’è un inganno
per rendere questo lavoro in un complesso
configurare come la build di Android.
È molto complesso se pensi
di sapori di build, Android deve sapere.
Hai finito dichiarando i tuoi sapori di build?
Finché questo non è possibile, non possono ripetere nulla.
Ma quando, non sa quando hai finito.
Deve fare questi ganci tardi
che non funziona
Ciò che si ottiene è un modello di costruzione dichiarativo.
Questo è l’output della fase di configurazione.
Questo è dichiarativo, hai il tuo modello.
Ma il problema è che Gradle in realtà non lo sa
come quel modello si è riunito.
Sa solo che è qui.
La prossima volta che sei su una build,
non sa come succede
quindi deve fare di nuovo tutto.
Un altro problema è
sta costruendo l’intero modello.
Anche se costruirà solo alcune cose.
Questo è descritto con l’aiuto di Gradle.
Costruirà l’intero modello anche se
tutto quello che vuoi veramente fare è chiamare aiuto Gradle.
Quanto tempo è stato investito per cosa
volevi fare
Non è nella relazione corretta.
C’è una soluzione per questo.
Altrimenti, non sarebbe bello.
Per Android
al momento della costruzione o al momento della configurazione
l’intero modello è costruito.
Se hai un grande progetto
(400 progetto),
costruzione del progetto e dieci varianti:
è enorme.
Ecco perché le cose richiedono così tanto tempo.
Penso al team di Android
ci vogliono due minuti
chiamare semplicemente come compiti Gradle
(perché deve costruire così tante cose,
che richiede tempo).
L’altra cosa è che deve fare il pieno
risoluzione delle dipendenze e elaborazione
al momento della valutazione o del tempo di configurazione.
Non è così
conosci tutti i sapori che vuoi avere
fino a molto tardi. Quindi è così tardi
che deve fare cose.
Cosa è stato fatto fino ad oggi
migliorare la fase di configurazione?
Lo script di compilazione, si compilano più velocemente.
Il caching avviene lì,
in modo affidabile.
Come usiamo le nuove versioni di Groovy
per fare l’analisi del DSL,
diventa più veloce,
Gradle non è scritto in Groovy.
La gente pensa questo.
Non è vero.
Il livello DSL è fatto con Groovy.
c’è un’altra funzionalità chiamata configure on demand.
Forse l’uno o l’altro l’ha già usato.
Ti permette, quando esegui alcuni compiti,
solo configurare quei progetti
che sono raggiunti da tali compiti.
Funziona solo in determinate condizioni,
e se violate queste condizioni,
l’uscita non è garantita.
Ma se hai un pulito
progetto, che non tenta di attirare altri progetti
della stessa build,
quindi usare configure on demand funziona bene.
Non passerà attraverso questi progetti
che non sono raggiungibili dal compito
tu vuoi correre.
Diciamo che hai un progetto, tu esegui build,
e hai una dipendenza compilata su un altro progetto.
Configura anche quell’altro progetto.
Ma se un terzo progetto non lo è
raggiunto in questo modo, non lo configurerà.
Quale può farti risparmiare tempo.
Di nuovo, questi miglioramenti sono evolutivi.
Diamo un’occhiata alla build di Android.
Un grafico
Per preparare il palco,
il team di Android e il team di Gradle
avere un buon rapporto,
beneficio reciproco.
Questo esce da questa relazione.
Se sto indicando alcune cose
che riguarda il lato Android,
non è affatto un dito puntato.
Sta davvero lavorando sulle soluzioni insieme.
Se fai un’installazione pulita,
tempo, in questo esempio,
è usato per il pre-dexing.
Tutte le tue librerie che stai consumando
attraverso le dipendenze, devono essere dexati.
Questo richiede molto tempo in questa build.
Lo vedrai dice installazione pulita.
Non dovrebbero essere maiuscole,
ma non importa.
Una volta che lo fai e corri
la build di nuovo, sono memorizzati nella cache.
Succede solo una volta,
ma comunque ciò può ferire la prima volta che lo fai
se hai delle dipendenze.
C’è un potenziale
per ottimizzazioni, per il pre-dexing.
Ad esempio, vogliamo avere un pulito,
cache sicura, ma è una cache generica.
Il che significa se hai delle dipendenze
e devono essere trasformati prima di essere consumati,
che dovrebbe diventare parte di Gradle,
e quindi può essere usato per
anche i plugin Android.
L’altro è la parallelizzazione.
Questo pre-dexing potrebbe avvenire in parallelo,
ma attualmente non sta succedendo in parallelo.
Qualcosa che Gradle
potrebbe sostenere,
che questo pre-dexing può avvenire in parallelo.
Il terzo è una cache distribuita
questo è già sulla mappa stradale
(senza una data però).
Immaginiamo
sei un team e hai una cache distribuita
che vive da qualche parte
La prima persona, tu fai la build,
innescherà il dexing
o pre-dexing di queste librerie.
Altri sviluppatori lo faranno anche
chiama la build. Il pre-dexing
per prima cosa controllerà la cache se è già lì.
E se è lì, sarà già consumato.
Questo riduce il tempo
per pre-dexing sulla tua macchina locale a zero.
Questo è un altro aspetto.
Prima di andare alla cache distribuita,
controllerà localmente se qualcosa è già lì.
Se non è lì, vai alla cache distribuita.
Se è lì, usalo da lì,
scaricalo, salvalo.
Mi piace consumare
una dipendenza esterna.
Dexing
(puoi vedere su questo grafico).
Ancora una volta, richiede una quantità significativa di tempo.
Non c’è molto che Gradle possa fare.
Questo è davvero più nelle mani
del team di Android, ma stanno lavorando
una nuova implementazione, come ho capito, è Jack.
Quale per uno può fare dexing più veloce,
e l’altro è che può fare il dexing incrementale.
Al momento non sta succedendo:
cambiate un file, deve dex di nuovo tutto.
Questo è lo stato attuale.
Ciò che è stato già ottimizzato a questo punto.
Questi sono cambiamenti evolutivi.
Ancora alcune limitazioni. Android è interessato
Anche tutte le altre build sono interessate.
Il collo di bottiglia che ci stiamo concentrando
ora è la fase di configurazione.
Tutto è costruito
in un modello di build che viene poi consumato.
Anche se nulla deve essere consumato
fuori da quel modello di costruzione.
Stai solo chiamando aiuto Gradle.
Questo è chiamato solo un nuovo modello di configurazione.
Questo è davvero rivoluzionario.
Non si tratta solo di modificare un po ‘qua e là.
È davvero qualcosa che costruiamo
in parallelo. Hanno anche dei ponti da fare
il vecchio mondo lavora con il nuovo mondo.
Avere tutte le cose disponibili ma solo bisogno di alcune cose,
andremo a sapere solo
quello di cui abbiamo bisogno per la costruzione.
Questo nuovo modello di configurazione.
Darò alcuni esempi di codice.
Ritorna a ciò che ho appena spiegato
è la fase di esecuzione
vogliamo sapere gli input e le uscite,
perché se conosci gli input e gli output,
puoi iniziare, sai in quale ordine fare le cose.
Puoi iniziare a fare le cose in parallelo
perché sai che puoi costruire un grafico.
Se hai un grafico, prendi gli alberi,
i sottoalberi e puoi costruirli in parallelo.
C’è così tanto che puoi fare una volta che lo sai.
(Cosa è già stato fatto per la fase di esecuzione,
accadrà anche per la fase di configurazione).
L’aspetto chiave che cambierà
è che descrivi il tuo modello.
Sarà molto dichiarativo.
Dici, guarda il mio modello B,
e poi Gradle ne deriverà l’implementazione.
Gestirà il modello.
Gestendolo, Gradle può essere intelligente a riguardo
e cosa fa al riguardo.
Ti permetterà di fare modelle più ricche.
Puoi già vederlo nella build di Android.
Hanno fatto un lavoro fantastico
di come modellare una build.
Se applichi il plugin e tu hai questo
Estensione Android.
Tutte le cose che fai in modo dichiarativo,
e così tanta magia accade dietro la scena.
È davvero grandioso
soprattutto dati quei vincoli
che ho elencato prima.
Android ne beneficerà davvero
perché possono sbarazzarsi di tutti gli inganni.
Sarà una modellizzazione più pulita,
perché ora se guardi i compiti,
vedresti che c’è una logica di esecuzione,
così come la logica di configurazione.
Questa sarà una separazione netta.
Il compito, o non sarà più chiamato un compito,
ma hai i tuoi tipi di gestione in tutto ciò che contengono sono dati.
Non c’è niente sull’esecuzione.
Puoi collaborare meglio.
Non sai quando le cose sono pronte,
quindi devi farli molto tardi.
Questo andrà via.
Sarà davvero facile da dire
Io sono colui che la crea, OR
Voglio aggiungere i valori predefiniti,
O voglio mutarlo,
O voglio fare qualcosa alla fine,
o voglio fare la convalida.
Molto più deterministico.
E comprensibile.
Avendo un modello, come per l’esecuzione,
abbiamo un compito e un grafico delle attività.
Se c’è un modello per la tua build,
e tu sai da dove vengono le cose,
puoi fare report davvero interessanti,
e tu sai perché stanno accadendo cose.
Perché sai chi ha contribuito a cosa.
Diamo un’occhiata all’esempio di codice.
Abbiamo gestito questo qui chiamato Picture.
È in un’interfaccia.
Gradle fornirà implementazione,
come
che sa se qualcuno imposta il nome.
Se sa chi stabilisce il nome,
è qualcosa su cui può riferire.
So anche che posso derivare
cose da quello pure.
Un altro vantaggio di questi tipi gestiti
è che possono essere persistenti.
Come va e costruisce quel modello,
se ci sono certe cose di cui non ha bisogno,
può scriverli a questo, rincuorarli di nuovo più tardi.
Oppure può memorizzarli nel daemon,
e quando esegui la prossima build,
può riutilizzarli, può memorizzare nella cache le cose.
Ecco perché sono esternalizzabili.
Questo è un esempio.
Qualcuno ha ancora scritto un plugin Gradle?
Una persona
chi ha scritto un plugin Gradle.
Questo strano un po ‘.
Ormai sembra così.
Molto dichiarativo.
In pratica dici, voglio,
c’è un modello per creare un’immagine,
e c’è un modo per mutare l’immagine.
L’immagine è passata e puoi impostare questo argomento.
Quando li imposti, perché l’implementazione
di immagine è controllata da Gradle,
di nuovo, può tracciare e sa chi ha fatto questi cambiamenti.
C’è dell’altro.
Ma voglio solo darti una piccola panoramica.
L’ultima parte sta fornendo
un DSL (come sviluppatore
di un’applicazione Android,
vuoi dichiarare cosa fare).
Sulla base dell’esempio che mostro,
tu dici ok, ecco la mia modella.
Ecco una foto. Voglio creare una nuova istanza di immagine,
o immagine nodo, e voglio impostare il nome su qualcosa,
e voglio impostare i tag su qualcosa.
Questo sembra molto simile a come lo fai
nel plugin Android,
ma la differenza è l’implementazione
di tutto ciò è controllato da Gradle.
Conoscendo questo,
può essere tutte le ottimizzazioni che ho menzionato.
Per darti un esempio.
Abbiamo un rapporto qui.
Esattamente per quell’esempio che ho mostrato.
Questo createPicture,
può vedere di che tipo si tratta.
Puoi vedere chi lo ha creato.
E puoi anche vedere quali erano le regole
che sono stati applicati su quella foto,
quindi il configure è stato chiamato dopo la creazione.
Puoi vederlo per ogni attributo,
chi l’ha creato. Qual è il valore Qual è il tipo.
Con tutte queste ricche informazioni
c’è intelligenza che può accadere.
Se si prende l’ultimo plug-in per Android.
Fonde davvero con due plugin.
Una vecchia versione e una nuova versione.
E la logica sottostante di cosa fare durante la costruzione
è lo stesso, ma il modo
è configurato è diverso.
Uno sta usando il nuovo modello,
l’altro sta usando il vecchio modello.
Devi usare
questo modello, la parola chiave più esterna.
E poi dentro di te dici Android,
e poi è molto simile.
non è ancora completo.
è davvero work in progress, ma ogni volta
esce una nuova versione di Gradle,
fanno uso delle ultime funzionalità,
e regolare i loro plugin sperimentali.
A un certo punto, questo plugin diventerà
il plugin predefinito.
Non cose così belle.
Devi usare la notazione a punti;
e devi dire creare se è nuovo,
puoi usare solo il nome se è esistente.
Questo andrà via, certo.
Ma spero che questo ti faccia eccitare
che vedi Gradle apporta questi cambiamenti.
guidato da Android,
ma si inseriscono nella grande visione di Gradle.
E Android li consuma.
La versione per versione, migliorando il loro plugin.
Cosa otteniamo dal fare tutto questo?
La configurazione diventerà parallelizzabile
come l’esecuzione dell’attività può essere parallelizzabile.
Gestire i tempi può essere esternalizzato,
che è importante quando si tratta di fare il caching.
Il modello può essere riutilizzato attraverso invocazioni,
perché Gradle conosce gli input e gli output
per la fase di configurazione.
Sa se può riutilizzare qualcosa o no.
Sa tutto, in pratica,
e così facendo può fare il minimo
che è necessario fare.
Questo è davvero un cambiamento rivoluzionario.
Non vogliamo rompere ciò che è lì.
Tutto accade in parallelo a ciò che è lì;
e c’è un passaggio dal vecchio lavoro al nuovo.
Ciò richiede un certo sforzo.
Non sarà un big bang.
È già usato oggi.
Presto, con il nuovo plug-in Android,
o con il nuovo plug-in Android,
il supporto C ++ che ha per costruire l’NDK,
userà già il plugin Gradle per C ++,
e questo è già basato su questo nuovo
modello di configurazione.
Sono davvero
attenersi ad esso.
Se guardiamo alla tabella di marcia
per i prossimi sei a dodici mesi,
senza alcuna garanzia, naturalmente
questi miglioramenti sono molto in alto nella lista.
Android è un ecosistema molto importante per Gradle,
ma anche gli altri ecosistemi vogliono avere prestazioni migliori.
Tutti vogliono prestazioni migliori.
Ci sono investimenti in corso lì.
L’altro è la correzione automatica,
dovrebbe dire generare la gestione delle dipendenze.
Non ci sono solo dipendenze tra le biblioteche,
puoi anche vedere le dipendenze
tra costrutti di livello molto più elevato.
E questo sta accadendo anche adesso.
Non ho intenzione di entrare in quello,
ma voglio andare in performance solo un po ‘.
Abbiamo questi hotspot
che cerchiamo di identificare e, una volta risolti,
il prossimo si presenterà.
Tutti quelli che hanno eseguito il profiling delle prestazioni
sa come funziona
Il caching e il riutilizzo sono aspetti chiave.
Usiamo ciò che è già lì,
piuttosto che ricostruirlo.
Fare il lavoro in parallelo. è enorme
In parallelo significa per correre sulla stessa macchina,
ma può anche significare attraverso le macchine.
Verranno anche le build distribuite.
Hai una build, usi cose diverse,
devi configurare le cose.
Ciò può accadere in parallelo.
Può succedere anche attraverso le macchine.
E facendo il lavoro in background.
La modalità continua che ho mostrato
è un esempio
Tu fai il tuo lavoro e mentre fai il tuo lavoro
Gradle può già vedere se qualcosa è cambiato,
e se è cambiato, può già prepararlo
in modo tale che quando vuoi eseguirlo,
è già lì.
Tutte queste tecniche che ho appena menzionato
(lato sinistro),
può essere applicato a molte cose sul lato della mano.
Gli attuali si sono concentrati su:
costruire la configurazione.
questo è quello che ho appena spiegato.
Il prossimo sarà la risoluzione delle dipendenze.
Anche qui le cose possono accadere in parallelo.
Il caching avviene già, ma può accadere di più.
E l’esecuzione del compito.
è già stato fatto qui,
ma si può fare di più.
Immaginiamo che tu sia un compito
sono completamente gestiti da Gradle,
quale sarà il caso con il nuovo modello di configurazione.
Quindi è possibile eseguire queste attività in parallelo.
E una volta che puoi eseguirli in parallelo, voglio dire,
e Gradle sa cosa può essere eseguito in parallelo,
è un enorme passo avanti.
Puoi già abilitarlo in una certa misura,
ma non è super deterministico
perché Gradle in realtà non sa quali sono i tuoi compiti.
Quindi se guardiamo, alla performance,
questo è solo un po ‘come, alcuni test che abbiamo eseguito.
Se usi questo nuovo approccio,
totalmente basato su questi tipi gestiti,
questa non è una build per Android, ma comunque,
anche con build Gradle puoi avere varianza,
il concetto di varianza è venuto fuori
i requisiti di Android, ma è un concetto
che si applica in generale, come,
anche una varietà potrebbe essere contro
JDK sei o sette o otto,
questi sono tre diverse varianza.
Se crei una variante,
con questo modello gestito,
richiede tempo zero.
Se costruisci un progetto, richiede del tempo.
Se costruisci tutto, richiede più tempo.
La chiave è: meno lo fai,
o meno vuoi fare,
meno Gradle deve fare.
Questa è la cosa.
Se vuoi fare una compilazione completa,
il nuovo modello non ti darà molto.
andando a darti un po ‘, ma non è eccezionale.
O non molto significativo.
Meno lo fai, meno Gradle farà,
che è a vostro vantaggio.
Penso che sia molto visibile con questa curva.
Per arrotondare questo,
perché questo è importante per il contesto di Android,
pure, gestione delle dipendenze.
C’è una gestione delle dipendenze,
Puoi avere le tue dipendenze dalla varianza.
Ma vogliamo andare oltre.
Quando si consumano librerie esterne,
vuoi consumare la variante.
Supponiamo che tu crei una libreria nella variante ABC.
Ora abbiamo un altro progetto che consuma
questa libreria e ha anche la varianza ABC.
Vuoi consumare la variante,
di quella dipendenza esterna.
Lo stesso vale per le librerie native.
Anche tu vuoi consumare quello.
Io ti trovi nel tipo di build di debug,
vuoi usare tutto il debug.
Memorizzando questo,
questi metadati extra con queste varianze.
E poi quando si tratta di risoluzione,
proverà a scegliere la variante.
Se ne trova uno, lo usa.
Se non lo fa, esploderà.
Lo stesso accadrà nello spazio Java.
Se sto costruendo una libreria per JDK 8,
e tu stai dipendendo da un’altra libreria,
se quella biblioteca dice, sono disponibile solo o
Sono solo, sono una variante solo per JDK 9 e successivi,
non può usarlo.
Questa sarà la variante completa
della variante di gestione delle dipendenze.
Per arrotondare questo,
stiamo anche lavorando su Gradle.com
Vediamo Android
come obiettivo davvero interessante per questo.
Mentre esegui la tua build, puoi caricare
come una ricevuta di compilazione per Gradle.com
e puoi condividerlo con persone che vuoi condividere.
Diciamo che hai un master di costruzione nella tua squadra.
Hai un problema locale.
Puoi caricare quello e il tuo master di compilazione può guardarlo,
e in base a ciò che vede, può capirlo
qual è il problema.
Cosa è cambiato.
Altre cose sono, tu costruisci.
Va tutto bene, e poi improvvisamente questa build smette di funzionare.
Quello che è successo?
Forse ti rendi conto
una dipendenza transitiva è cambiata.
Tutte queste cose ti scopriranno
cosa sta succedendo.
Ti aiuterà anche a rilevare gli errori
e proporre soluzioni.
Questo è ciò che sta succedendo a Gradle.com.
Diciamo che vuoi andare al modulo,
hai avuto problemi a costruire.
Puoi semplicemente allegare un link alla ricevuta di compilazione
e poi qualcuno può andare avanti e dire
Vedo un problema qui.
Anche qualcun altro ha avuto questo problema.
c’è un link al modulo, eccetera.
Questo sta arrivando molto presto.
è in pieno sviluppo ora.
Stiamo facendo progressi lì.
Non sono sicuro che qualcuno sappia che esiste una classe udacity
su Gradle e sviluppo Android.
Questo è stato fatto insieme a Google.
Classe fantastica.
10.000 persone hanno già
registrato per questo.
È un buon modo per imparare Gradle
nel contesto di Android.
y
Gradle è una grande azienda in cui lavorare.
E ci sono sempre più persone necessarie.
E questo mi porta alla fine di questa presentazione.
(pubblico che applaude)
– Ok, grazie mille Haten.
Non ci sono state domande online,
ma non so se qualcuno ha una domanda in diretta ora?
Penso che sia buono,
perché il tempo è scaduto
Grazie ancora, moltissimo,
e ricorda di scrivere feedback per Haten. Grazie.
(pubblico che applaude)
– Il mio nome è Etienne. Lavoro per Gradle.
Sto conducendo il progetto di bill bill
(il nostro sforzo per integrarsi con Eclipse).
Sono anche co-leader degli sforzi di Gradle.com,
che è la nostra soluzione di base Sass
che uscirà presto.
L’obiettivo di oggi è darti più informazioni
nella build di Gradle,
e come si riferisce alla build di Android.
Ma prima di iniziare,
Vorrei chiederti:
Chi sta facendo lo sviluppo di Android,
che sta ascoltando?
La maggior parte delle persone, direi il 90%.
Chi sta usando Android Studio?
Forse dovrei chiedere il contrario.
Chi non sta utilizzando Android Studio?
Forse 5 mani, o giù di lì.
Chi ha toccato la build Gradle?
Interessante.
Direi forse due terzi.
Ho sempre fatto quella domanda, e ogni volta che lo chiedo sale.
Non sono sicuro che sia un buon segno o no.
Io penso che sia.
E chi sta usando Gradle al di fuori di un progetto Android?
Sviluppo Java, Scala.
Forse cinque mani.
Questo è venuto fuori.
Qual è la motivazione
per parlare di Gradle e Android:
è solo un sistema di costruzione.
Perché questo grande affare di fare questa scelta,
e non un altro
Voglio parlarne ancora un po ‘
per darti un po ‘di contesto.
La build di Android è implicitamente molto complessa.
Se lo si confronta con un solo progetto Java,
La build di Android è più complessa.
Puoi anche vederlo su questo grafico a lato
(da Xavier, Android Lead).
È una semplificazione di ciò che accade
durante la build di Android, potenzialmente.
E non include nemmeno tutto.
C’è complessità implicata,
più che compilare
Hai i tuoi corsi, li carteggi,
e hai finito.
In genere quando si esegue lo sviluppo di Android
fai parte di una squadra,
e non tutti potrebbero fare cose Android
su quella squadra.
Potresti anche avere una squadra di back-end.
stanno facendo Java o Scala;
rapidamente hai più lingue
(Java, Android, ecc.).
Questo deve essere parte di esso pure.
Hai una generazione di risorse,
estrazione di artefatti,
e conversione ad altri artefatti.
Devi splatare dalla diversità.
Tutta la frammentazione
che tu sicuramente sai meglio di me.
Ma è lì.
C’è complessità
coinvolto nel gestire la build di Android.
E se guardi a questa complessità su questo grafico qui,
espressività contro concisione,
puoi vedere che con Ant puoi essere molto espressivo,
puoi fondamentalmente fare tutto.
Formica
è molto espressivo,
ma cresce anche rapidamente.
Devi dirlo con i dettagli su cosa fare.
Dall’altra parte hai Maven, che è molto conciso,
è un approccio basato su XML.
È conciso, ma non molto espressivo.
A tutti voi che avete una build personalizzata
sapere quanto velocemente arrivi ai tuoi limiti.
Gradle combina i due.
È conciso.
Sto per darti un esempio
(anche molto espressivo).
In questo esempio qui,
questa è una build Android completamente autonoma.
Sapori diversi prodotti,
due dimensioni di sapore
combinato con un tipo di build;
un’esplosione di prodotti incrociati.
Ciò porta a compiti.
(Non sono sicuro,
forse nella prima fila puoi ancora leggerlo).
(Posso. Ma sicuramente non nell’ultima riga).
Finisci con 300 attività.
Voglio mostrare
il DSL molto conciso
(le cose accadono dietro le quinte).
Se volevi ottenere lo stesso con Ant,
dovresti scrivere di più
per ottenere lo stesso risultato.
Con Maven, non so come lo faresti.
Per quanto riguarda le lingue.
Hai più lingue.
In genere hai anche più team.
E poi vuoi collaborare agli stessi software.
Quindi vuoi un sistema di costruzione
che ti consente di interagire tra i diversi team.
Gli artefatti vengono consumati, vengono prodotti.
Vuoi anche avere queste versioni coordinate.
Anche prima del rilascio.
Se cambi qualcosa nel back end,
vuoi sapere se questo influenza il tuo generale
applicazione che include una parte Android o no.
Hai bisogno di questa versione coordinata,
e questo è davvero uno dei punti di forza di Gradle:
un grande progetto,
con sotto-progetti e lo lega, tutti insieme.
Alla fine non si modella l’APK.
Formi un prodotto,
e c’è più coinvolto,
anche oltre a costruire questo artefatto,
quindi vuoi fare uscite automatiche,
inviare e-mail di rilascio,
fare tutto il provisioning degli ambienti di sviluppo.
Potresti creare un test,
qualche documentazione con codice di prova.
O codice che è stato testato
modo automatico.
(c’è molto da fare).
Per darti un esempio:
Linkedin, un grande utente di Gradle.
2.000 sviluppatori,
2.000 componenti,
e fanno circa 300.000 build a settimana,
e 1.000 release costruisce un giorno.
Se vedi quella scala,
probabilmente non è la scala di tutti quelli che lavorano,
o in quella stanza ora,
ma se lavori in un simile ambiente,
se hai una build molto disconnessa,
artefatti qua e là, e poi tu solo
in qualche modo, metterlo insieme,
non sta andando in scala.
Diamo un’occhiata al sistema di build di Android.
Il sistema di build di Android è
un bel pezzo di software secondo me.
Perché prende il meglio della lettura di cose diverse.
Utilizza l’IDE di Android Studio,
è la tua interfaccia utente,
basato sulla piattaforma IntelliJ.
Hai il plugin Android Gradle,
che è quindi di nuovo basato sulla piattaforma Gradle.
E tu hai gli strumenti Android.
Vogliamo guardare oggi
l’Android Gradle Plugin
e la piattaforma Gradle,
e trattarli come uno.
Alla fine,
Non ti importa; quando la tua build è lenta,
se si tratta del plug-in Android o è la build Gradle.
La tua build è solo lenta?
O è veloce, ma poi non ti interessa neanche.
Ciò che lo rende così bello
sul sistema di build Android
è che c’è un’unica fonte di verità
quando si tratta della logica di costruzione.
La build è l’unico posto
che definisce cosa fa la tua build.
Non c’è niente in più nell’IDE.
Quando apri il tuo progetto,
non vai nel tuo IDE e dici
Ho anche bisogno di questa libreria e di quella libreria.
Questo è tutto definito dalla build.
È visionario,
prima non era stato fatto.
Tu fai
configurazione in Eclipse,
(ad esempio, prima Eclipse con Ant).
Dovevi fare tutto in Eclipse per lo sviluppo Android.
Per definire cosa
dipendenze che usi,
lo fai nella tua build.
Dove sono le mie fonti.
Lo fai nella build,
ma non nell’IDE.
L’IDE verrà configurato in base al modello.
Te lo mostrerò un po ‘più in dettaglio.
In alto a sinistra vedi Android Studio,
questo sei tu, lo sviluppatore, che lavora su Android Studio,
Alla fine, dal momento della costruzione,
Gradle è l’unico posto che ha la logica di costruzione.
Deve comunicare con Gradle
per capire cosa deve presentare / fare.
Ciò avviene tramite l’API di Tooling.
Qualcuno sa che cos’è l’API degli strumenti?
O che esiste?
Nessuno.
È interessante.
Quando hai Android Studio,
la build di Gradle, il modo in cui parlano tra loro
è attraverso una libreria chiamata tooling API.
L’API degli strumenti risiede in Android Studio
(sul percorso classe dell’IDE).
Attraverso la comunicazione di interprocessi,
parla con la build di Gradle.
La build di Gradle
(Demone Gradle)
è un processo separato.
Se vuoi compilare,
l’interstudio indicherà l’API degli strumenti, compilerà,
e l’API degli strumenti parlerà con il demone
attraverso la comunicazione di interprocessi.
Demone
compilerà quella build con quell’attività.
È così che funziona.
Se vieni dalla riga di comando,
continui a interagire con Gradle. Con
il demone Gradle, se lo hai abilitato,
ma tu vieni semplicemente attraverso un modo diverso
(il programma di avvio).
Non si entra attraverso l’API degli strumenti,
ma attraverso il launcher.
Se si è in un server di integrazione continua,
coinvolgi anche Gradle direttamente.
Tutto ciò funziona
perché Gradle è l’unica fonte
di verità quando si tratta di costruire la logica.
Ognuno porta Gradle.
Quali sono i miei progetti?
Qual è il mio percorso di classe compilato?
Qual è il mio test compila il percorso di classe, eccetera.
Per approfondire un po ‘di più,
l’API degli strumenti (in verde).
È un proxy
per aver parlato con Gradle.
Vedremo alcuni dei benefici nella prossima slide.
C’è anche un meccanismo per fornire modelli personalizzati.
Questo è esattamente ciò che accade con Android.
In che modo Android ottiene tutte le informazioni
ha bisogno dalla build
che può presentarlo nell’IDE,
o configurare l’IDE
(il tuo modello personalizzato).
Android chiede Gradle, per favore dammi quella modella
per Android.
Android, la modella ritorna
e contiene tutte le informazioni sulle varianti,
e i sapori.
L’IDE può consumarlo
e configurare l’IDE di conseguenza.
Se vuoi guardarlo,
è il progetto Android predefinito che è il modello.
(questo è quello che fanno i ragazzi Android)
Scrivono un modello,
fornire un plugin.
Questo è ciò che fornisci sempre nella tua sceneggiatura?
Dice plugin di alimentazione qualcosa di Android,
e registra quel modello.
Puoi chiedere quel modello
attraverso l’API degli strumenti.
C’è il client VM (l’IDE).
Questo è il piccolo file del lavoro di routine
(800 k o giù di lì).
Chiede a Gradle, attraverso l’API degli strumenti,
dammi quel modello di costruzione o invoca alcune attività.
Costruisci modelli che chiedi,
per configurare l’IDE.
Invocare compiti di compilazione
eseguire qualcosa nella build.
Alcuni dei vantaggi di questo approccio
è la retrocompatibilità.
Anche se la build Gradle utilizzata fosse 1.0,
potresti ancora parlarci.
Potresti non avere tutte le funzionalità disponibili,
ma è ancora compatibile.
Hai isolamento Runtime.
Diciamo che Gradle ha avuto una perdita di memoria.
Ciò non influirebbe su Android Studio,
perché è un processo diverso.
Se Android Studio ha avuto una perdita di memoria,
Gradle non ne risentirebbe
perché è un processo diverso.
(Due lati per guardarlo).
Ci sono alcuni servizi di alto livello,
in modo da poter cancellare una build.
Questo vale per l’API degli strumenti,
qualunque cosa faccia, la fermerà.
Ha una modalità continua.
Lo mostrerò più tardi.
E puoi anche eseguire test.
Android Studio non lo sta usando,
ma penso che lo faranno ad un certo punto.
Se hai un’API specifica su di esso quando esegui un test,
che il test è eseguito da Gradle.
Il che ha senso,
perché solo Gradle sa qual è il percorso di classe, eccetera,
per eseguire quel test.
L’IDE non lo sa davvero.
Può solo fare un’approssimazione.
C’è un modello di evento,
man mano che esegui una build attraverso l’API degli strumenti, ottieni eventi.
Ovviamente si ottiene tutto il registro.
Ottieni progressi.
Ma hai anche eventi come
la fase di configurazione inizia, si ferma.
La fase di esecuzione inizia, si ferma.
I test sono iniziati. I test sono finiti o falliti, eccetera.
Tutto ciò è consumabile attraverso l’API degli strumenti.
E se hai guardato su costruire shaper
o integrazione di Gradle per Eclipse,
vedresti che se, quando sei sulla build,
vedi un albero che ti mostra
tutti questi eventi accadono.
Perché tutto questo è possibile?
Gradle ha un modello molto ricco.
Avendo un modello ricco, conosce tutte queste cose.
Sa cosa significano.
Con quelle informazioni c’è così tanto che puoi fare.
Se si confronta questo con una build Ant,
e non dirò nulla contro Ant,
ma quando fai qualcosa con Ant,
La stessa Ant non sa cosa stai facendo.
È molto imperativo
Non c’è modo di fornire questi ricchi modelli
come sono, è il caso di Gradle.
Per quanto riguarda la perfomance.
Tutti vogliamo che le prestazioni siano velocissime.
Ho usato questa immagine perché usa anche
lampo parallelo che va dall’alto verso il basso.
Qual è l’aspetto chiave della performance:
fare le cose in parallelo.
Qual è il nostro obiettivo?
Il nostro obiettivo è ridurre al minimo il tempo di costruzione,
per dirlo in un modo semplice.
Usando la poca memoria necessaria.
Perché?
Vogliamo un riscontro più rapido sui dati di costruzione.
Vogliamo fare più build al giorno.
Vogliamo fare più uscite al giorno.
E vogliamo fare più round sull’integrazione continua.
(e molte altre ragioni).
Ci sono molti più motivi per cui vogliamo avere build veloci.
Quando fai lo sviluppo,
da un round a quello successivo,
di solito non ci sono molti cambiamenti nella tua build.
Potresti avere questa build complessa,
ma cosa fai di solito?
Si modificano alcuni file sorgente.
Tu cambi alcuni test.
Forse una volta ogni tanto rimuovi una risorsa
o ne aggiungi uno.
Oppure aggiungi una dipendenza o cambia una dipendenza
ma questo è già raro.
Non lo fai per ogni build.
Tra queste serie di test consecutive,
tipicamente non molti cambiamenti.
E se non ci sono molti cambiamenti, non dovrebbe esserci molto
essere lavorato dalla build.
Quando piccoli cambiamenti nella build,
poco lavoro dovrebbe essere fatto.
Questo è qualcosa che tu attualmente
vedi nel plugin Android,
Questo non è il caso.
Anche se hai un grande progetto Android,
Gradle task, o Gradle help,
ci vorrà un po ‘, e quella volta
è proporzionale alla dimensione della build.
E non dovrebbe essere, perché quando dici aiuto Gradle,
non stai nemmeno eseguendo nulla nella tua build.
Quando costruisci, fallo
impiegano più tempo di quanto tu vorresti che prendessero?
Sì, annuendo.
Questo è, per la maggior parte,
a causa della fase di configurazione.
arriveremo a questo.
qual è l’approccio a Gradle
migliorare le prestazioni?
che si applica alla prospettiva di Android,
ma anche a tutti gli altri a Gradle
che non sono correlati ad Android.
Due approcci.
Uno è quello evolutivo.
Fai piccoli miglioramenti qua e là.
Potrebbero avere un impatto significativo.
e lo mostrerò in un grafico più avanti.
C’è anche il modo di dire
facciamo qualche cambiamento rivoluzionario
per fare il prossimo passo in termini di prestazioni.
Potresti solo fare un’ottimizzazione locale,
ma non l’ottimizzazione globale altrimenti.
Questo sta accadendo attualmente. Lo vedremo.
Quando costruisci con Gradle.
Hai una build a due fasi.
Qualcuno ha familiarità con questo, che hai due fasi?
Hai una fase di configurazione e una fase di esecuzione.
Alcune persone sembrano averne familiarità.
Dici la build di Gradle o quello che chiami,
se mai vai alla riga di comando.
Accadranno due cose
La prima cosa è la fase di configurazione.
Questo è quando viene eseguita la logica di compilazione,
e il modello di costruzione è costruito.
Nella fase di esecuzione, quel modello di costruzione
viene applicato, il che significa che i compiti sono eseguiti.
Vedremo queste due fasi,
e inizierò con la fase di esecuzione.
Perché quello è quello in cui è stato fatto di più,
e poi arriveremo alla fase di configurazione.
Cosa stiamo già facendo in termini
di ottimizzazione durante la fase di esecuzione.
Uno è la funzione di build incrementale.
Se pensi alle attività, le attività hanno
ingressi e uscite in Gradle.
Il significato di un’attività consuma determinati input, come una funzione,
fa qualcosa con loro,
e produce un’uscita.
In Gradle puoi annotare o dichiarare,
quali sono gli input di un’attività e quali sono gli output.
E con queste informazioni, Gradle può fare build incrementali.
Se gli ingressi non sono cambiati e le uscite
non sono cambiati, non è necessario eseguire di nuovo quell’attività.
diciamo che hai un progetto e fai una compilazione.
Ha file sorgente, nessun file compilato.
Farà la compilation.
Ora lo esegui di nuovo.
Deve fare qualcosa se non hai cambiato la fonte
file o se non hai rimosso i file di classe?
No. Tutto è rimasto lo stesso.
E usando, per Gradle, sapere quali sono gli input
e le uscite sono che può fare quell’ottimizzazione per te.
Ecco perché, quando dici “Gradle build”, Gradle build,
se hai una build normalmente configurata, direi
lo vedi aggiornato, aggiornato, aggiornato,
e nulla è stato fatto davvero.
Che è buono, perché se nulla è cambiato,
nulla dovrebbe essere fatto.
Come ho detto prima.
Questo è solo un piccolo esempio.
se hai scritto il tuo compito, e non lo fa,
quelli di Gradle sembrano molto simili.
Ho scritto un’attività chiamata operazione di conversione,
e prende un file,
fa qualcosa con quel file,
e crea un nuovo file.
è solo una trasformazione.
Quello che fa, non importa,
è per questo che ho messo un commento lì.
Questo è come lo chiameresti nel tuo script Gradle.
Diresti solo che ho un compito,
è di questo tipo
I miei input sono uno o più file.
Sto usando solo questo, e
la mia directory di destinazione verrà riconvertita
i file scritti in questa cartella.
Ecco come lo useresti.
Usando queste annotazioni,
i file di input e la directory di output,
ora stai dicendo a Gradle cosa sono
i miei input e output.
E Gradle gestirà questi,
ne terrà traccia,
in modo che quando lo vuoi, lo farà
ricorda quali erano i valori l’ultima volta che l’hai eseguito.
Se il dispositivo è sempre lo stesso, dirà
oh questo compito è aggiornato, saltiamolo.
Chi ha usato Ant e ha usato
un approccio con timestamp per vedere se non ci sono i timestamp
sono cambiati, e quindi non lo farà?
C’è almeno una mano.
Lo facevo anche io.
Dovevo farlo ogni volta,
quando ho avuto un compito del genere
sensibile agli ingressi e alle uscite.
Qui è completamente cotto nel sistema.
è così. questa è l’attività di conversione.
Per darti un’idea
di cosa significa input e output.
Torneremo su questo concetto durante
la fase di configurazione.
Ecco perché voglio mostrarlo qui prima.
Ce n’è un altro.
Questo è un concetto così semplice.
Hai un input, hai un output.
Tieni traccia di esso o Gradle tiene traccia di esso,
e quindi puoi fare ogni sorta di cose.
Ti ho appena mostrato la funzione di build incrementale.
Un altro è la funzione di creazione continua.
Quello che puoi fare è,
e anche tu potresti farlo
con una build Android, non lo è
specifico per qualsiasi tipo di build.
Sto solo dicendo che Gradle è un involucro di Gradle,
o sarebbe Gradle.
Dico test dash t.
Dash t sta per modalità continua.
Puoi vedere
inizia a costruire, fa tutto ciò che deve fare,
anche se non avevi il trattino t,
costruire con successo. Se l’hanno fatto
qualcosa o no non importa
tempo totale, ma poi non si torna alla riga di comando
richiesta. Sta dicendo ora in attesa di cambiamenti.
Quindi sta solo aspettando lì,
e se ora cambi qualcosa che è un input
dell’attività invocata, quindi si innescherebbe automaticamente
la build e fai ciò che è necessario.
Diciamo che scrivi
documentazione usando qualcosa come Asciidoc.
Stai sempre cambiando il file,
esecuzione di Gradle build.
Cambiando il file, eseguendo la build di Gradle.
Con la modalità continua, devi solo cambiare
il tuo file e vai al browser.
Tu dici di aggiornamento ed è lì.
Non appena cambi il file sorgente,
e sta rilevando il cambiamento, lo ricostruirà
l’artefatto, e lo vedrai.
Come fa a sapere cosa hai fatto,
cosa rintracciare. Non può
ti basta seguire il tuo intero file system.
Che cosa tiene traccia dei tuoi input.
Se il tuo compito ha definito gli input,
allora sa dove cercare i cambiamenti.
Guarderà solo questi cambiamenti se accadono.
Se succedono, sa di innescare una build.
Funzionalità molto potente che è possibile
basato su questo concetto molto semplice
di dichiarare input e output.
Questa è davvero la chiave.
Più dici a Gradle quello che stai facendo,
e quello che hai, più può farlo.
Le cose più intelligenti che può fare,
senza che tu debba farli.
Potresti implementarti,
come una modalità orologio, e ci sono anche plugin per questo,
ma ora è disponibile per ogni attività che ha input.
In termini
di miglioramenti delle prestazioni,
sono applicabili anche ai progetti Android.
Puoi comandare le build;
ci sono stato per molto tempo.
Ma se hai un grande progetto, scopri se qualcosa
è cambiato o non ha richiesto molto tempo.
Doveva andare su tutti i file, crearne alcuni,
guarda i timestamp, fai qualche controllo sulle somme, eccetera.
Solo per decidere se tutto è aggiornato o meno.
O qualcosa non è aggiornato o no.
Ed è particolarmente doloroso quando lo hai
un grande progetto e nulla è cambiato.
Perché quello che farà sarà attraversato
i tuoi 400.000 file solo per realizzare
niente è cambiato
E questo richiede tempo.
Nell’ultima versione
quello è RC1 è fuori ora,
ci sono stati dei miglioramenti
alla gestione di questi file controlla somme.
Se hai un progetto molto grande,
vedrai che se non hai quasi nessun cambiamento,
sarà molto più veloce da rilevare.
Se hai un piccolo progetto,
noterai anche una differenza,
ma non è così spettacolare
come il progetto è grande.
Questo ci riporta indietro:
se è cambiato poco, poco dovrebbe accadere.
Successivo: compilazione veloce per la modalità continua.
Diciamo che stai usando quella modalità continua,
stai facendo dei cambiamenti, è sempre in costruzione
come stanno cambiando le cose.
Se stai compilando come parte di questo,
questo cambiamento accade,
Gradle genererà un demone del compilatore,
di default almeno per Java.
Gli altri che puoi configurare
usa un demone del compilatore.
Con build continue
questo demone rimarrà in vita,
anche come il giro di costruzione.
Finché la sessione di build
di un round di build continuo,
il demone del compilatore sarà lì.
Tutto ciò che è già
c’è molto più veloce da usare
che se deve partire, deve scaldarsi.
Questi sono tutti miglioramenti evolutivi.
Diamo un’occhiata alla fase di configurazione.
Se guardi i tuoi script di compilazione,
anche se in Android è dichiarativo
non appena fai le tue cose,
diventa imperativo.
Anche se non scrivi alcun codice imperativo,
cosa succede dietro la scena dal plugin Android
è abbastanza imperativo.
Potresti avere un DSL, cioè dichiarativo,
ma quello che Android deve fare è imperativo.
E non appena diventa imperativo
nel tuo codice o nel codice del plugin
Gradle non sa cosa stai facendo.
E se non sa cosa stai facendo,
non può ottimizzare le cose.
Cosa fanno le persone?
Fanno cose pigramente perché
non dovrebbe accadere presto,
O usare collezioni pigre.
Rilevano tutti i cambiamenti che verranno dopo.
Oppure usano il progetto dopo la valutazione,
che è un gancio dove ti permette
per dire, la fase di configurazione è finita,
ora lasciami fare qualcosa.
Cosa succede se più persone aggiungono tale gancio?
Chi è aggiunto, chi sarà chiamato per primo,
chi verrà chiamato l’ultimo.
C’è un inganno
per rendere questo lavoro in un complesso
configurare come la build di Android.
È molto complesso se pensi
di sapori di build, Android deve sapere.
Hai finito dichiarando i tuoi sapori di build?
Finché questo non è possibile, non possono ripetere nulla.
Ma quando, non sa quando hai finito.
Deve fare questi ganci tardi
che non funziona
Ciò che si ottiene è un modello di costruzione dichiarativo.
Questo è l’output della fase di configurazione.
Questo è dichiarativo, hai il tuo modello.
Ma il problema è che Gradle in realtà non lo sa
come quel modello si è riunito.
Sa solo che è qui.
La prossima volta che sei su una build,
non sa come succede
quindi deve fare di nuovo tutto.
Un altro problema è
sta costruendo l’intero modello.
Anche se costruirà solo alcune cose.
Questo è descritto con l’aiuto di Gradle.
Costruirà l’intero modello anche se
tutto quello che vuoi veramente fare è chiamare aiuto Gradle.
Quanto tempo è stato investito per cosa
volevi fare
Non è nella relazione corretta.
C’è una soluzione per questo.
Altrimenti, non sarebbe bello.
Per Android
al momento della costruzione o al momento della configurazione
l’intero modello è costruito.
Se hai un grande progetto
(400 progetto),
costruzione del progetto e dieci varianti:
è enorme.
Ecco perché le cose richiedono così tanto tempo.
Penso al team di Android
ci vogliono due minuti
chiamare semplicemente come compiti Gradle
(perché deve costruire così tante cose,
che richiede tempo).
L’altra cosa è che deve fare il pieno
risoluzione delle dipendenze e elaborazione
al momento della valutazione o del tempo di configurazione.
Non è così
conosci tutti i sapori che vuoi avere
fino a molto tardi. Quindi è così tardi
che deve fare cose.
Cosa è stato fatto fino ad oggi
migliorare la fase di configurazione?
Lo script di compilazione, si compilano più velocemente.
Il caching avviene lì,
in modo affidabile.
Come usiamo le nuove versioni di Groovy
per fare l’analisi del DSL,
diventa più veloce,
Gradle non è scritto in Groovy.
La gente pensa questo.
Non è vero.
Il livello DSL è fatto con Groovy.
c’è un’altra funzionalità chiamata configure on demand.
Forse l’uno o l’altro l’ha già usato.
Ti permette, quando esegui alcuni compiti,
solo configurare quei progetti
che sono raggiunti da tali compiti.
Funziona solo in determinate condizioni,
e se violate queste condizioni,
l’uscita non è garantita.
Ma se hai un pulito
progetto, che non tenta di attirare altri progetti
della stessa build,
quindi usare configure on demand funziona bene.
Non passerà attraverso questi progetti
che non sono raggiungibili dal compito
tu vuoi correre.
Diciamo che hai un progetto, tu esegui build,
e hai una dipendenza compilata su un altro progetto.
Configura anche quell’altro progetto.
Ma se un terzo progetto non lo è
raggiunto in questo modo, non lo configurerà.
Quale può farti risparmiare tempo.
Di nuovo, questi miglioramenti sono evolutivi.
Diamo un’occhiata alla build di Android.
Un grafico
Per preparare il palco,
il team di Android e il team di Gradle
avere un buon rapporto,
beneficio reciproco.
Questo esce da questa relazione.
Se sto indicando alcune cose
che riguarda il lato Android,
non è affatto un dito puntato.
Sta davvero lavorando sulle soluzioni insieme.
Se fai un’installazione pulita,
tempo, in questo esempio,
è usato per il pre-dexing.
Tutte le tue librerie che stai consumando
attraverso le dipendenze, devono essere dexati.
Questo richiede molto tempo in questa build.
Lo vedrai dice installazione pulita.
Non dovrebbero essere maiuscole,
ma non importa.
Una volta che lo fai e corri
la build di nuovo, sono memorizzati nella cache.
Succede solo una volta,
ma comunque ciò può ferire la prima volta che lo fai
se hai delle dipendenze.
C’è un potenziale
per ottimizzazioni, per il pre-dexing.
Ad esempio, vogliamo avere un pulito,
cache sicura, ma è una cache generica.
Il che significa se hai delle dipendenze
e devono essere trasformati prima di essere consumati,
che dovrebbe diventare parte di Gradle,
e quindi può essere usato per
anche i plugin Android.
L’altro è la parallelizzazione.
Questo pre-dexing potrebbe avvenire in parallelo,
ma attualmente non sta succedendo in parallelo.
Qualcosa che Gradle
potrebbe sostenere,
che questo pre-dexing può avvenire in parallelo.
Il terzo è una cache distribuita
questo è già sulla mappa stradale
(senza una data però).
Immaginiamo
sei un team e hai una cache distribuita
che vive da qualche parte
La prima persona, tu fai la build,
innescherà il dexing
o pre-dexing di queste librerie.
Altri sviluppatori lo faranno anche
chiama la build. Il pre-dexing
per prima cosa controllerà la cache se è già lì.
E se è lì, sarà già consumato.
Questo riduce il tempo
per pre-dexing sulla tua macchina locale a zero.
Questo è un altro aspetto.
Prima di andare alla cache distribuita,
controllerà localmente se qualcosa è già lì.
Se non è lì, vai alla cache distribuita.
Se è lì, usalo da lì,
scaricalo, salvalo.
Mi piace consumare
una dipendenza esterna.
Dexing
(puoi vedere su questo grafico).
Ancora una volta, richiede una quantità significativa di tempo.
Non c’è molto che Gradle possa fare.
Questo è davvero più nelle mani
del team di Android, ma stanno lavorando
una nuova implementazione, come ho capito, è Jack.
Quale per uno può fare dexing più veloce,
e l’altro è che può fare il dexing incrementale.
Al momento non sta succedendo:
cambiate un file, deve dex di nuovo tutto.
Questo è lo stato attuale.
Ciò che è stato già ottimizzato a questo punto.
Questi sono cambiamenti evolutivi.
Ancora alcune limitazioni. Android è interessato
Anche tutte le altre build sono interessate.
Il collo di bottiglia che ci stiamo concentrando
ora è la fase di configurazione.
Tutto è costruito
in un modello di build che viene poi consumato.
Anche se nulla deve essere consumato
fuori da quel modello di costruzione.
Stai solo chiamando aiuto Gradle.
Questo è chiamato solo un nuovo modello di configurazione.
Questo è davvero rivoluzionario.
Non si tratta solo di modificare un po ‘qua e là.
È davvero qualcosa che costruiamo
in parallelo. Hanno anche dei ponti da fare
il vecchio mondo lavora con il nuovo mondo.
Avere tutte le cose disponibili ma solo bisogno di alcune cose,
andremo a sapere solo
quello di cui abbiamo bisogno per la costruzione.
Questo nuovo modello di configurazione.
Darò alcuni esempi di codice.
Ritorna a ciò che ho appena spiegato
è la fase di esecuzione
vogliamo sapere gli input e le uscite,
perché se conosci gli input e gli output,
puoi iniziare, sai in quale ordine fare le cose.
Puoi iniziare a fare le cose in parallelo
perché sai che puoi costruire un grafico.
Se hai un grafico, prendi gli alberi,
i sottoalberi e puoi costruirli in parallelo.
C’è così tanto che puoi fare una volta che lo sai.
(Cosa è già stato fatto per la fase di esecuzione,
accadrà anche per la fase di configurazione).
L’aspetto chiave che cambierà
è che descrivi il tuo modello.
Sarà molto dichiarativo.
Dici, guarda il mio modello B,
e poi Gradle ne deriverà l’implementazione.
Gestirà il modello.
Gestendolo, Gradle può essere intelligente a riguardo
e cosa fa al riguardo.
Ti permetterà di fare modelle più ricche.
Puoi già vederlo nella build di Android.
Hanno fatto un lavoro fantastico
di come modellare una build.
Se applichi il plugin e tu hai questo
Estensione Android.
Tutte le cose che fai in modo dichiarativo,
e così tanta magia accade dietro la scena.
È davvero grandioso
soprattutto dati quei vincoli
che ho elencato prima.
Android ne beneficerà davvero
perché possono sbarazzarsi di tutti gli inganni.
Sarà una modellizzazione più pulita,
perché ora se guardi i compiti,
vedresti che c’è una logica di esecuzione,
così come la logica di configurazione.
Questa sarà una separazione netta.
Il compito, o non sarà più chiamato un compito,
ma hai i tuoi tipi di gestione in tutto ciò che contengono sono dati.
Non c’è niente sull’esecuzione.
Puoi collaborare meglio.
Non sai quando le cose sono pronte,
quindi devi farli molto tardi.
Questo andrà via.
Sarà davvero facile da dire
Io sono colui che la crea, OR
Voglio aggiungere i valori predefiniti,
O voglio mutarlo,
O voglio fare qualcosa alla fine,
o voglio fare la convalida.
Molto più deterministico.
E comprensibile.
Avendo un modello, come per l’esecuzione,
abbiamo un compito e un grafico delle attività.
Se c’è un modello per la tua build,
e tu sai da dove vengono le cose,
puoi fare report davvero interessanti,
e tu sai perché stanno accadendo cose.
Perché sai chi ha contribuito a cosa.
Diamo un’occhiata all’esempio di codice.
Abbiamo gestito questo qui chiamato Picture.
È in un’interfaccia.
Gradle fornirà implementazione,
come
che sa se qualcuno imposta il nome.
Se sa chi stabilisce il nome,
è qualcosa su cui può riferire.
So anche che posso derivare
cose da quello pure.
Un altro vantaggio di questi tipi gestiti
è che possono essere persistenti.
Come va e costruisce quel modello,
se ci sono certe cose di cui non ha bisogno,
può scriverli a questo, rincuorarli di nuovo più tardi.
Oppure può memorizzarli nel daemon,
e quando esegui la prossima build,
può riutilizzarli, può memorizzare nella cache le cose.
Ecco perché sono esternalizzabili.
Questo è un esempio.
Qualcuno ha ancora scritto un plugin Gradle?
Una persona
chi ha scritto un plugin Gradle.
Questo strano un po ‘.
Ormai sembra così.
Molto dichiarativo.
In pratica dici, voglio,
c’è un modello per creare un’immagine,
e c’è un modo per mutare l’immagine.
L’immagine è passata e puoi impostare questo argomento.
Quando li imposti, perché l’implementazione
di immagine è controllata da Gradle,
di nuovo, può tracciare e sa chi ha fatto questi cambiamenti.
C’è dell’altro.
Ma voglio solo darti una piccola panoramica.
L’ultima parte sta fornendo
un DSL (come sviluppatore
di un’applicazione Android,
vuoi dichiarare cosa fare).
Sulla base dell’esempio che mostro,
tu dici ok, ecco la mia modella.
Ecco una foto. Voglio creare una nuova istanza di immagine,
o immagine nodo, e voglio impostare il nome su qualcosa,
e voglio impostare i tag su qualcosa.
Questo sembra molto simile a come lo fai
nel plugin Android,
ma la differenza è l’implementazione
di tutto ciò è controllato da Gradle.
Conoscendo questo,
può essere tutte le ottimizzazioni che ho menzionato.
Per darti un esempio.
Abbiamo un rapporto qui.
Esattamente per quell’esempio che ho mostrato.
Questo createPicture,
può vedere di che tipo si tratta.
Puoi vedere chi lo ha creato.
E puoi anche vedere quali erano le regole
che sono stati applicati su quella foto,
quindi il configure è stato chiamato dopo la creazione.
Puoi vederlo per ogni attributo,
chi l’ha creato. Qual è il valore Qual è il tipo.
Con tutte queste ricche informazioni
c’è intelligenza che può accadere.
Se si prende l’ultimo plug-in per Android.
Fonde davvero con due plugin.
Una vecchia versione e una nuova versione.
E la logica sottostante di cosa fare durante la costruzione
è lo stesso, ma il modo
è configurato è diverso.
Uno sta usando il nuovo modello,
l’altro sta usando il vecchio modello.
Devi usare
questo modello, la parola chiave più esterna.
E poi dentro di te dici Android,
e poi è molto simile.
non è ancora completo.
è davvero work in progress, ma ogni volta
esce una nuova versione di Gradle,
fanno uso delle ultime funzionalità,
e regolare i loro plugin sperimentali.
A un certo punto, questo plugin diventerà
il plugin predefinito.
Non cose così belle.
Devi usare la notazione a punti;
e devi dire creare se è nuovo,
puoi usare solo il nome se è esistente.
Questo andrà via, certo.
Ma spero che questo ti faccia eccitare
che vedi Gradle apporta questi cambiamenti.
guidato da Android,
ma si inseriscono nella grande visione di Gradle.
E Android li consuma.
La versione per versione, migliorando il loro plugin.
Cosa otteniamo dal fare tutto questo?
La configurazione diventerà parallelizzabile
come l’esecuzione dell’attività può essere parallelizzabile.
Gestire i tempi può essere esternalizzato,
che è importante quando si tratta di fare il caching.
Il modello può essere riutilizzato attraverso invocazioni,
perché Gradle conosce gli input e gli output
per la fase di configurazione.
Sa se può riutilizzare qualcosa o no.
Sa tutto, in pratica,
e così facendo può fare il minimo
che è necessario fare.
Questo è davvero un cambiamento rivoluzionario.
Non vogliamo rompere ciò che è lì.
Tutto accade in parallelo a ciò che è lì;
e c’è un passaggio dal vecchio lavoro al nuovo.
Ciò richiede un certo sforzo.
Non sarà un big bang.
È già usato oggi.
Presto, con il nuovo plug-in Android,
o con il nuovo plug-in Android,
il supporto C ++ che ha per costruire l’NDK,
userà già il plugin Gradle per C ++,
e questo è già basato su questo nuovo
modello di configurazione.
Sono davvero
attenersi ad esso.
Se guardiamo alla tabella di marcia
per i prossimi sei a dodici mesi,
senza alcuna garanzia, naturalmente
questi miglioramenti sono molto in alto nella lista.
Android è un ecosistema molto importante per Gradle,
ma anche gli altri ecosistemi vogliono avere prestazioni migliori.
Tutti vogliono prestazioni migliori.
Ci sono investimenti in corso lì.
L’altro è la correzione automatica,
dovrebbe dire generare la gestione delle dipendenze.
Non ci sono solo dipendenze tra le biblioteche,
puoi anche vedere le dipendenze
tra costrutti di livello molto più elevato.
E questo sta accadendo anche adesso.
Non ho intenzione di entrare in quello,
ma voglio andare in performance solo un po ‘.
Abbiamo questi hotspot
che cerchiamo di identificare e, una volta risolti,
il prossimo si presenterà.
Tutti quelli che hanno eseguito il profiling delle prestazioni
sa come funziona
Il caching e il riutilizzo sono aspetti chiave.
Usiamo ciò che è già lì,
piuttosto che ricostruirlo.
Fare il lavoro in parallelo. è enorme
In parallelo significa per correre sulla stessa macchina,
ma può anche significare attraverso le macchine.
Verranno anche le build distribuite.
Hai una build, usi cose diverse,
devi configurare le cose.
Ciò può accadere in parallelo.
Può succedere anche attraverso le macchine.
E facendo il lavoro in background.
La modalità continua che ho mostrato
è un esempio
Tu fai il tuo lavoro e mentre fai il tuo lavoro
Gradle può già vedere se qualcosa è cambiato,
e se è cambiato, può già prepararlo
in modo tale che quando vuoi eseguirlo,
è già lì.
Tutte queste tecniche che ho appena menzionato
(lato sinistro),
può essere applicato a molte cose sul lato della mano.
Gli attuali si sono concentrati su:
costruire la configurazione.
questo è quello che ho appena spiegato.
Il prossimo sarà la risoluzione delle dipendenze.
Anche qui le cose possono accadere in parallelo.
Il caching avviene già, ma può accadere di più.
E l’esecuzione del compito.
è già stato fatto qui,
ma si può fare di più.
Immaginiamo che tu sia un compito
sono completamente gestiti da Gradle,
quale sarà il caso con il nuovo modello di configurazione.
Quindi è possibile eseguire queste attività in parallelo.
E una volta che puoi eseguirli in parallelo, voglio dire,
e Gradle sa cosa può essere eseguito in parallelo,
è un enorme passo avanti.
Puoi già abilitarlo in una certa misura,
ma non è super deterministico
perché Gradle in realtà non sa quali sono i tuoi compiti.
Quindi se guardiamo, alla performance,
questo è solo un po ‘come, alcuni test che abbiamo eseguito.
Se usi questo nuovo approccio,
totalmente basato su questi tipi gestiti,
questa non è una build per Android, ma comunque,
anche con build Gradle puoi avere varianza,
il concetto di varianza è venuto fuori
i requisiti di Android, ma è un concetto
che si applica in generale, come,
anche una varietà potrebbe essere contro
JDK sei o sette o otto,
questi sono tre diverse varianza.
Se crei una variante,
con questo modello gestito,
richiede tempo zero.
Se costruisci un progetto, richiede del tempo.
Se costruisci tutto, richiede più tempo.
La chiave è: meno lo fai,
o meno vuoi fare,
meno Gradle deve fare.
Questa è la cosa.
Se vuoi fare una compilazione completa,
il nuovo modello non ti darà molto.
andando a darti un po ‘, ma non è eccezionale.
O non molto significativo.
Meno lo fai, meno Gradle farà,
che è a vostro vantaggio.
Penso che sia molto visibile con questa curva.
Per arrotondare questo,
perché questo è importante per il contesto di Android,
pure, gestione delle dipendenze.
C’è una gestione delle dipendenze,
Puoi avere le tue dipendenze dalla varianza.
Ma vogliamo andare oltre.
Quando si consumano librerie esterne,
vuoi consumare la variante.
Supponiamo che tu crei una libreria nella variante ABC.
Ora abbiamo un altro progetto che consuma
questa libreria e ha anche la varianza ABC.
Vuoi consumare la variante,
di quella dipendenza esterna.
Lo stesso vale per le librerie native.
Anche tu vuoi consumare quello.
Io ti trovi nel tipo di build di debug,
vuoi usare tutto il debug.
Memorizzando questo,
questi metadati extra con queste varianze.
E poi quando si tratta di risoluzione,
proverà a scegliere la variante.
Se ne trova uno, lo usa.
Se non lo fa, esploderà.
Lo stesso accadrà nello spazio Java.
Se sto costruendo una libreria per JDK 8,
e tu stai dipendendo da un’altra libreria,
se quella biblioteca dice, sono disponibile solo o
Sono solo, sono una variante solo per JDK 9 e successivi,
non può usarlo.
Questa sarà la variante completa
della variante di gestione delle dipendenze.
Per arrotondare questo,
stiamo anche lavorando su Gradle.com
Vediamo Android
come obiettivo davvero interessante per questo.
Mentre esegui la tua build, puoi caricare
come una ricevuta di compilazione per Gradle.com
e puoi condividerlo con persone che vuoi condividere.
Diciamo che hai un master di costruzione nella tua squadra.
Hai un problema locale.
Puoi caricare quello e il tuo master di compilazione può guardarlo,
e in base a ciò che vede, può capirlo
qual è il problema.
Cosa è cambiato.
Altre cose sono, tu costruisci.
Va tutto bene, e poi improvvisamente questa build smette di funzionare.
Quello che è successo?
Forse ti rendi conto
una dipendenza transitiva è cambiata.
Tutte queste cose ti scopriranno
cosa sta succedendo.
Ti aiuterà anche a rilevare gli errori
e proporre soluzioni.
Questo è ciò che sta succedendo a Gradle.com.
Diciamo che vuoi andare al modulo,
hai avuto problemi a costruire.
Puoi semplicemente allegare un link alla ricevuta di compilazione
e poi qualcuno può andare avanti e dire
Vedo un problema qui.
Anche qualcun altro ha avuto questo problema.
c’è un link al modulo, eccetera.
Questo sta arrivando molto presto.
è in pieno sviluppo ora.
Stiamo facendo progressi lì.
Non sono sicuro che qualcuno sappia che esiste una classe udacity
su Gradle e sviluppo Android.
Questo è stato fatto insieme a Google.
Classe fantastica.
10.000 persone hanno già
registrato per questo.
È un buon modo per imparare Gradle
nel contesto di Android.
y
Gradle è una grande azienda in cui lavorare.
E ci sono sempre più persone necessarie.
E questo mi porta alla fine di questa presentazione.
(pubblico che applaude)
– Ok, grazie mille Haten.
Non ci sono state domande online,
ma non so se qualcuno ha una domanda in diretta ora?
Penso che sia buono,
perché il tempo è scaduto
Grazie ancora, moltissimo,
e ricorda di scrivere feedback per Haten. Grazie.
(pubblico che applaude)
Please follow and like us: