Come sviluppatore di app so che convincere gli utenti a continuare a usare la tua app è una delle problematiche più grandi. Anche se le notifiche a livello di sistema operativo sono un ottimo modo per ricordare agli utenti di ritornare alla tua app, possono perdersi nel mare di notifiche inviate dalle altre app. Ad esempio, se vuoi comunicare ai clienti qualche power-up in vendita nel tuo store in-app, non sarebbe meglio parlarne quando avviano il gioco o completano un livello piuttosto che quando stanno andando al lavoro?
Considerando ciò, abbiamo rilasciato recentemente un ottimo prodotto per promuovere e far crescere la tua app: Firebase In-App Messaging. Grazie a In-App Messaging, ora puoi coinvolgere gli utenti che utilizzano attivamente la tua app iOS o Android inviando loro messaggi mirati, personalizzati e contestuali. Queste notifiche indirizzano gli utenti verso importanti azioni in-app, come iscriversi alla newsletter, guardare un video o acquistare un prodotto.
Ora hai la flessibilità e il controllo di impostare messaggi in-app in una varietà di formati e attivarli in base al comportamento degli utenti. Illustrerò solo un esempio dei numerosi modi di utilizzare Firebase In-App Messaging. Ho già configurato la mia app in modo che possa ricevere messaggi seguendo le istruzioni contenute nella Guida introduttiva.
Supponiamo di avere un'app per social media basata sulla pubblicazione di foto di gatti. Di recente ho lanciato una nuova funzione di condivisione che voglio comunicare ai miei utenti.
Quindi questo è un perfetto caso d'uso per Firebase In-App Messaging. Grazie a Firebase In-App Messaging, posso creare la campagna direttamente dalla Console Firebase, come indicato qui sotto.
Nella console, ho scelto un'immagine e un colore del pulsante che rispecchino il look e lo stile della mia app. Ho anche incluso un'azione del pulsante che nel mio caso farà visualizzare la finestra di dialogo di condivisione nell'app, in modo che gli utenti possano condividere facilmente le loro foto preferite.
In-App Messaging offre molte opzioni di targeting dei messaggi che ti consentono di adattare i messaggi in base ai gruppi che desideri raggiungere. Puoi selezionare tutti gli utenti dell'app, gli utenti di segmenti di pubblico specifici di Google Analytics, gli utenti che corrispondono a determinate proprietà o gli utenti che Firebase Predictions prevede che aderiranno a una determinata iniziativa nei prossimi sette giorni. Nel mio caso, seleziono tutti gli utenti.
Con la funzione di pianificazione, posso decidere quando questa finestra di dialogo verrà visualizzata nell'app. Potrei usare Firebase In-App Messaging per mostrare un messaggio ai miei utenti quando avviano l'app per la prima volta, ma voglio che la mia campagna sia più mirata e pertinente, quindi decido di mostrare il messaggio solo agli utenti che mettono Mi piace (o "zampa su") alla loro prima foto.
Ho anche la possibilità di impostare una data di inizio e di fine per la mia campagna, se mai dovessi organizzare una promozione stagionale.
Infine, posso selezionare un evento di conversione, ossia il parametro che misura se la campagna ha avuto successo. Nel mio caso, terrò traccia degli utenti che hanno condiviso o meno un'immagine.
L'evento di conversione scelto viene tracciato nella Console Firebase, come indicato nel grafico.
Per tutta la durata della campagna posso tenere traccia di impressioni, clic su pulsanti e conversioni. Posso anche modificare la campagna, e ciò mi permette di testare le modifiche che potrebbero migliorare il tasso di conversione.
Questo è solo un esempio di come In-App Messaging aiuta a promuovere la conversione. Può anche essere utilizzato per mettere in evidenza una vendita o un coupon all'interno di un'app e-commerce, informare gli utenti dei termini di aggiornamento del servizio o mostrare nuove funzionalità. All'interno dell'app, Firebase In-App Messaging rappresenta una sorta di guida che incoraggia l'esplorazione e la scoperta delle app, incrementa la durata delle sessioni e favorisce le conversioni. Per ulteriori esempi, vai a vedere il nostro annuncio sul blog!
Pronto per un'immersione totale? Inizia oggi stesso consultando la documentazione.
Getting started with Firebase In-App Messaging
Hai un caso d'uso perfetto per Firebase In-App Messaging? Condividilo con me su Twitter @ThatJenPerson. Non vedo l’ora di scoprire cosa riuscirai a creare!
Come abbiamo già accennato a maggio, le persone creano e utilizzano foto e video in molti modi diversi, quindi sosteniamo che sfruttarli meglio e farci ancora di più dovrebbe essere più semplice nell'ambito dei molti dispositivi e app che usiamo sempre. Ecco perché abbiamo prodotto l'API Google Photos Library, che offre la possibilità di creare esperienze di foto e video più intelligenti, veloci e utili all'interno dei tuoi prodotti.
Dopo un'anteprima di sviluppo ben accolta negli ultimi mesi, l'API Google Photos Library è ora disponibile per il pubblico. Se vuoi creare e testare la tua esperienza, inizia visitando la documentazione per sviluppatori. Puoi anche esprimere il tuo interesse aderendo al programma partner di Google Foto se stai pianificando un'integrazione più ampia.
Ecco una rapida panoramica dell'API Google Photos Library e come utilizzarla.
Sia che tu sia uno sviluppatore mobile, web o di backend, puoi utilizzare questa API REST per sfruttare il meglio di Google Foto e aiutare le persone a connettersi, caricare e condividere all'interno della tua app. Stiamo anche lanciando librerie client in diverse lingue che ti consentiranno di procedere più rapidamente.
Gli utenti devono autorizzare le richieste tramite l'API, in tal modo sono sempre al comando della situazione. Ecco cosa puoi aiutarli a fare:
Sfruttare il machine learning a vantaggio della tua app è semplice. Puoi utilizzare i filtri intelligenti, come le categorie di contenuti, per limitare o escludere determinati tipi di foto o video, e aiutare gli utenti a trovare più facilmente ciò che stanno cercando.
Ringraziamo tutti coloro che ci hanno fornito il loro feedback durante l'anteprima degli sviluppatori. Tutti i commenti ricevuti hanno contribuito a migliorare l'API. Sono disponibili le note sulla versione che accompagnano le nuove release della nostra API. Inoltre, se attualmente stai usando l'API Picasa Web Albums, ecco la guida alla migrazione che ti aiuterà a passare all'API Google Photos Library.
Recentemente ho fatto parte del fantastico team che ha lavorato all'app Android Google I/O 2018. È un'app complementare per conferenze che consente ai partecipanti e a chi si trova in remoto di cercare sessioni, creare programmi personalizzati e prenotare posti all'evento (se si ha la fortuna di essere lì!). Nell'app abbiamo sviluppato molte interessanti funzionalità animate che, a mio parere, hanno migliorato notevolmente l'esperienza utente. Il codice di questa app è appena stato reso open source e quindi vorrei segnalare alcuni dettagli e istanze di implementazione interessanti.
Ci sono 3 tipi di animazioni che abbiamo usato maggiormente nell'app:
Mi piacerebbe parlare più nel dettaglio di alcune di queste funzionalità.
Parte della funzione dell'app è creare entusiasmo e attesa per la conferenza. Pertanto, quest'anno abbiamo incluso un grande conto alla rovescia animato per marcare l'inizio della conferenza, visualizzato sia nella schermata di on-boarding sia nella sezione Info. È stata anche un'ottima opportunità per incorporare il marchio dell'evento nell'app dandole così più carattere.
Questa animazione è stata progettata da un motion designer e distribuita come serie di file JSON Lottie: ognuno di 1 secondo che mostra un numero animato in ingresso "in" e in uscita "out". Il formato Lottie ha semplificato il rilascio dei file in asset e ha persino offerto metodi convenienti come setMinAndMaxProgress che ci hanno permesso di riprodurre solo la prima o l'ultima metà di un'animazione (per mostrare un numero animato in ingresso o in uscita).
In generale è stato interessante gestire le varie animazioni del conto alla rovescia. Per ottenere questo obiettivo abbiamo creato una CountdownView personalizzata, che è un ConstraintLayout abbastanza complesso contenente diverse LottieAnimationViews. In questo caso abbiamo creato un delegato Kotlin per incapsulare l'avvio dell'animazione giusta. Ciò ci ha permesso di assegnare semplicemente un Int a ciascun delegato della cifra che doveva essere visualizzata e, a sua volta, il delegato eseguiva l'impostazione e l'avvio delle animazioni. Abbiamo esteso il delegato ObservableProperty per garantire che l'animazione fosse eseguita solo al variare della cifra. Quindi il nostro loop di animazione pubblicava un runnable ogni secondo (quando la visualizzazione era allegata) che calcolava la cifra da mostrare per ogni visualizzazione e poi aggiornava i delegati.
Una delle azioni chiave dell'app è consentire ai partecipanti di prenotarsi. Pertanto abbiamo messo questa azione in evidenza in un FAB nella schermata dei dettagli della sessione. Abbiamo ritenuto importante segnalare solamente che la sessione era stata riservata, una volta che l'operazione veniva completata correttamente sul backend (a differenza delle azioni meno importanti, come la valutazione di una sessione, per cui ottimisticamente l'UI veniva aggiornata subito). Ricevere una risposta dal backend poteva richiedere tempo quindi, per rendere il processo più dinamico, abbiamo creato un'icona animata per indicare che il processo è in corso e passare agevolmente al nuovo stato.
Il processo è complicato dal fatto che questa icona rappresenta diversi stati: la sessione che può essere prenotata, l'utente che può aver già prenotato, se la sessione è esaurita potrebbe essere disponibile una lista d'attesa o l’utente potrebbe essere già sulla lista d'attesa o, con l’avvicinarsi della sessione, le prenotazioni potrebbero non essere più disponibili. Ciò dà luogo a molte transizioni di stato da animare. Per semplificare queste transizioni, abbiamo deciso di passare sempre attraverso uno stato "in corso", ossia la clessidra animata mostrata sopra. Pertanto ogni transizione è costituita da una coppia di stati: stato 1 → in corso e in corso → stato 2. Questo approccio ha semplificato moltissimo le cose. Abbiamo creato ognuna di queste animazioni usando shapeshifter; vedi i file avd_state_to_state qui.
Per mostrare ciò, abbiamo utilizzato una visualizzazione personalizzata AnimatedStateListDrawable (ASLD). Se non hai mai usato ASLD, si tratta di una versione animata di StateListDrawable, come suggerisce il nome, che hai probabilmente già visto e consente, non solo di fornire diverse risorse drawable per stato ma anche transizioni tra stati (sotto forma di AnimatedVectorDrawable o AnimationDrawable). Ecco la risorsa drawable che definisce le immagini statiche e le transizioni in ingresso e uscita dello stato "in corso" per l'icona della prenotazione.
Abbiamo creato una visualizzazione personalizzata per supportare i nostri stati personalizzati. Le visualizzazioni offrono alcuni stati standard come Premuto o Selezionato. Analogamente, puoi definire il tuo stato e avere il Percorso di visualizzazione a tutte le risorse drawable mostrate. Abbiamo definito gli state_reservable, state_reserved ecc. Poi abbiamo creato un Enum dei diversi stati incapsulando lo stato della visualizzazione più eventuali attributi correlati, come la descrizione dei contenuti associati. La nostra logica business potrebbe semplicemente impostare il valore appropriato dall'Enum alla visualizzazione (tramite associazione dati) aggiornando lo stato della risorsa drawable che, a sua volta, ha avviato l'animazione tramite ASLD. La combinazione degli stati personalizzati e AnimatedStateListDrawable è stata un ottimo modo per implementare questo processo, mantenendo i diversi stati ai livelli dichiarativi e dando luogo a un codice di visualizzazione minimo.
Molte transizioni dello schermo funzionavano bene con le animazioni nelle finestre standard. La situazione era un po' diversa per la transizione nella schermata dei dettagli del relatore. Mostrava l'immagine dei relatori da entrambi i lati della transizione ed era una soluzione ideale per transizioni di elementi condivisi perché facilitava il cambio di contesto tra schermate.
Si tratta di una transizione di elementi condivisi standard che utilizza le classi ChangeBounds e ArcMotion della piattaforma su un ImageView.
L’aspetto più interessante è il modo in cui l'avvio di questa transizione si adattava al pattern Evento usato per la navigazione. In sostanza, questo pattern disaccoppia gli eventi di input (come l'azione di tocco di un relatore) dagli eventi di navigazione, incaricando ViewModel di rispondere all'input. In questo caso, il disaccoppiamento implicava che ViewModel esponesse un LiveData degli Eventi, che conosceva solo l'ID del relatore a cui indirizzarsi. L’inizializzazione di una transizione condivisa di elementi richiede la Visualizzazione condivisa che non avevamo a questo punto. Abbiamo risolto il problema memorizzando l'ID del relatore come tag sulla visualizzazione quando è associato, in modo che possa essere recuperato in un secondo momento per navigare verso una particolare schermata dei dettagli del relatore.
Una parte fondamentale dell'app per conferenze è filtrare gli eventi a cui siamo interessati. Ogni argomento viene associato a un colore per essere riconosciuto facilmente. Abbiamo anche ottenuto un ottimo design per il "chip" personalizzato da utilizzare per la selezione dei filtri.
Abbiamo preso in considerazione Chip di Material Components ma poi abbiamo optato per la nostra visualizzazione personalizzata che offriva un maggiore controllo sul display e sull'animazione tra i vari stati "selezionati". È stata implementata usando il disegno su canvas e uno StaticLayout per la visualizzazione del testo. La visualizzazione ha una singola proprietà di avanzamento [0-1] che indica la modalità selezionata-deselezionata. Per cambiare lo stato, il valore viene animato e la visualizzazione viene invalidata, consentendo al codice di rendering di interpolare linearmente le posizioni e le dimensioni degli elementi in base a ciò.
Inizialmente, durante l'implementazione, ho fatto in modo che la visualizzazione implementasse l'interfaccia Checkable e ho avviato l'animazione quando il metodo setChecked impostava un nuovo stato. Poiché si visualizzavano più filtri in un RecyclerView, ciò ha avuto lo sfortunato effetto di eseguire l'animazione se il filtro selezionato si spostava "out" e la visualizzazione veniva riassociata a un filtro non selezionato che si era spostato "in". Ops. Abbiamo quindi aggiunto un altro metodo per avviare l'animazione che ci permettesse di distinguere tra l'attivazione da clic e l'aggiornamento immediato quando si associavano nuovi dati alla visualizzazione.
Inoltre, quando abbiamo introdotto questa animazione toggle, abbiamo scoperto che si trattava di una procedura di janking, ovvero che comportava la perdita di fotogrammi. Era colpa del mio codice di animazione? Questi filtri sono visualizzati in un BottomSheet davanti alla schermata del programma principale della conferenza. Attivando un filtro, avviamo la logica del filtro da applicare al programma (e aggiorniamo il numero di eventi corrispondenti nel titolo del foglio del filtro). Dopo un'analisi approfondita di systrace abbiamo individuato il problema, ossia che quando i filtri venivano applicati, il ViewPager di RecyclerViews, che mostrava il programma diligentemente, si attivava e aggiornava in base ai dati appena forniti. Ciò determinava l'ingrandimento e l'associazione di diverse visualizzazioni. Tutto questo lavoro stava facendo saltare il budget dei fotogrammi... ma il programma di aggiornamento non era visibile perché era nascosto dal foglio del filtro. Abbiamo deciso di ritardare l'utilizzo del filtro vero e proprio fino a quando non veniva eseguita l'animazione, e quindi abbiamo rinunciato a una maggiore complessità di implementazione a favore di un'esperienza utente più fluida. Inizialmente ho implementato questa funzionalità usando PostDelayed ma ciò ha causato problemi durante i test dell'UI. Invece abbiamo cambiato il metodo che ha avviato l'animazione per accettare un lambda da eseguire alla fine. Ciò ci ha permesso di rispettare meglio le impostazioni di animazione dell'utente e testare correttamente l'esecuzione.
Nel complesso, penso che le animazioni abbiano davvero contribuito all'esperienza, al carattere, al branding e alla reattività dell'app. Speriamo che questo post abbia contribuito a spiegare sia il motivo sia il metodo utilizzati, e a fornirti buone indicazioni su come implementare le animazioni.
Animazione in un programma è stato originariamente pubblicato su Android Developers del blog Medium, utile per continuare la conversazione e offrire feedback su questa storia.
Attualmente Crashlytics elabora più di 3 miliardi di eventi al giorno per i nostri sviluppatori e li distilla in una serie di problemi strategici e actionable nel dashboard. Nel corso degli anni abbiamo ricevuto migliaia di richieste relative a come conoscere meglio i dati di arresto anomalo, ed è per questo che ora siamo particolarmente lieti di offrirti la possibilità di esportare i dati Firebase Crashlytics in BigQuery per un'analisi più approfondita!
Con pochi clic nel dashboard di Firebase Crashlytics puoi abilitare le esportazioni giornaliere di tutti i dati raw di arresto anomalo in base all'app o al progetto. Ciò include le tracce dello stack, i registri, le chiavi e qualsiasi altro dato di arresto anomalo.
Il dashboard Crashlytics conserva i dati per 90 giorni. Con BigQuery possiedi le politiche di conservazione e cancellazione che consentono al tuo team di monitorare più facilmente le tendenze dei dati di stabilità anno dopo anno.
BigQuery offre anche la possibilità di esportare dati in formato CSV, JSON e Avro. Ciò contribuirà a semplificare qualsiasi richiesta di estrazione dati GDPR che potresti ricevere.
Fino a ora, la visibilità nei report sugli arresti anomali tramite metadati personalizzati, come Experiment ID o un breadcrumb Analytics, è stata limitata, rendendo difficile l'identificazione delle varianti con minore stabilità in un esperimento o il livello di gioco con il maggior numero di arresti anomali. Ora, quando esporti i dati in BigQuery, è facile eseguire tutte le analisi approfondite che desideri per poi visualizzare il report con Data Studio o qualsiasi altro sistema aziendale utilizzato.
Ad esempio, supponi di configurare il tuo gioco Android in modo da poter registrare a quale livello avviene l'arresto anomalo con:
Crashlytics.setInt("current_level", 3);
Quando esporti i tuoi dati Crashlytics in BigQuery, puoi visualizzare la distribuzione degli arresti anomali per livello grazie a questa query:
#standardSQL SELECT COUNT(DISTINCT event_id) AS num_of_crashes, value FROM `projectId.crashlytics.package_name_ANDROID`, UNNEST(custom_keys) WHERE key = "current_level" GROUP BY key, value ORDER BY num_of_crashes DESC
Se sei già un utente Fabric, puoi accedere all'esportazione BigQuery e a tutte le altre funzionalità di Firebase, collegando la tua app al dashboard Fabric. Dai un'occhiata a questo link per scoprire ulteriori dettagli e consultare la documentazione.
Speriamo che questo miglioramento renda ancora più facile l'accesso ai dati dei tuoi report sugli arresti anomali e al debugging efficace della tua app! Come sempre, se hai domande, puoi trovarci su Twitter e su Stack Overflow. Buon debugging!
Pubblicato da Alex Wiltschko, Dan Moldovan, Wolff Dobson
Oggi vorremmo presentare la nuova funzionalità di TensorFlow chiamata "AutoGraph". AutoGraph converte il codice Python, tra cui il flusso di controllo, print() e altre funzionalità native di Python, in puro codice grafico TensorFlow.
Scrivere il codice TensorFlow senza utilizzare Eager Execution significa eseguire un po' di metaprogrammazione, ossia scrivere un programma che crea un grafico che a sua volta viene eseguito successivamente. Ciò può creare confusione, specialmente per gli sviluppatori nuovi. In particolare in alcune situazioni difficili che riguardano i modelli più complessi, come quelli che usano if e while o quelli che hanno effetti collaterali come print() o accettano input strutturati.
Abbiamo davvero bisogno di grafici? I grafici consentono tutti i tipi di ottimizzazioni, come la rimozione di espressioni secondarie comuni e la fusione dei kernel. Inoltre, semplificano l'addestramento distribuito e l'implementazione in tutti i tipi di ambienti, poiché formano un modello di calcolo indipendente dalla piattaforma. Questo è particolarmente importante per l'addestramento distribuito su GPU o TPU multiple o per la distribuzione del modello su altre piattaforme, come IoT o mobile tramite TensorFlow Lite.
Ecco un esempio semplice di un'operazione che forse potresti aggiungere al tuo grafico:
def huber_loss(a): if tf.abs(a) <= delta: loss = a * a / 2 else: loss = delta * (tf.abs(a) - delta / 2) return loss
Con Eager Execution, l'esempio "funzionerà abbastanza bene" ma le operazioni potrebbero essere lente a causa dei costi generali dell'interprete Python o delle opportunità mancate di ottimizzazione dei programmi.
Per prepararci all'esecuzione del grafico, bisogna riscrivere il codice usando costrutti come tf.cond(), ma ciò può rivelarsi oneroso e difficile da implementare. AutoGraph può effettuare automaticamente questa conversione mantenendo la facilità di programmazione Eager e sfruttando al tempo stesso i vantaggi prestazionali dell'esecuzione basata su grafici.
Nell'esempio possiamo assegnare autograph.convert() alla nostra funzione in modo che AutoGraph generi automaticamente il codice pronto per il grafico.
Utilizzando AutoGraph, il codice:
@autograph.convert() def huber_loss(a): if tf.abs(a) <= delta: loss = a * a / 2 else: loss = delta * (tf.abs(a) - delta / 2) return loss
diventa questo codice in fase di esecuzione a causa dell'elemento Decorator.
def tf__huber_loss(a): with tf.name_scope('huber_loss'): def if_true(): with tf.name_scope('if_true'): loss = a * a / 2 return loss, def if_false(): with tf.name_scope('if_false'): loss = delta * (tf.abs(a) - delta / 2) return loss, loss = ag__.utils.run_cond(tf.less_equal(tf.abs(a), delta), if_true, if_false) return loss
Puoi quindi chiamare il tuo codice come se fosse un op TensorFlow:
with tf.Graph().as_default(): x_tensor = tf.constant(9.0) # The converted function works like a regular op: tensors in, tensors out. huber_loss_tensor = huber_loss(x_tensor) with tf.Session() as sess: print('TensorFlow result: %2.2f\n' % sess.run(huber_loss_tensor))
È da notare che AutoGraph colma il divario tra Eager Execution e i grafici. Prende il codice Python in stile Eager e lo converte in codice che genera grafici.
AutoGraph non è una semplice raccolta di macro utili: è uno strumento che usa la trasformazione del codice sorgente per consentire di sovrascrivere qualsiasi parte del linguaggio Python, inclusi controllo del flusso, applicazione della funzione, assegnazione, generazione di codice boilerplate e refactoring di Python idiomatico, per semplificare la trasformazione in grafici.
Una delle problematiche dei compilatori è la leggibilità dei messaggi di errore. A tal fine, AutoGraph è impostato per creare messaggi di errore e tracce di stack che rivelano la fonte dell'errore nel codice sorgente originale piuttosto che mostrare solo riferimenti al codice generato.
Come può aiutarti AutoGraph? Ecco alcuni esempi di codice che ora puoi trasformare direttamente in codice di grafico senza alcuna modifica. Per scoprire come funziona, consulta il nostro notebook in Colab o in GitHub.
Qui vediamo la Congettura Collatz che usa loop e rami. Nota che, per cambiare, al posto dell'elemento Decorator usiamo la funzione di AutoGraph .to_graph() che lo trasforma in grafico.
def collatz(a): counter = 0 while a != 1: if a % 2 == 0: a = a // 2 else: a = 3 * a + 1 counter = counter + 1 return counter graph_mode_collatz = autograph.to_graph(collatz) # The code is human-readable, too print(autograph.to_code(collatz)) collatz_tensor = graph_mode_collatz(tf.constant(n))
AutoGraph può supportare flussi di controllo annidati arbitrari, come ad esempio:
def f(n): if n >= 0: while n < 5: n += 1 print(n) return n
AutoGraph consente di aggiungere elementi agli array all'interno dei loop. Per eseguire questa operazione, usiamo gli helper di AutoGraph, set_element_type e stack.
def f(n): z = [] # We ask you to tell us the element dtype of the list autograph.set_element_type(z, tf.int32) for i in range(n): z.append(i) # when you're done with the list, stack it # (this is just like np.stack) return autograph.stack(z)
Supportiamo anche costrutti come break, continue e persino print e assert. Terminata la conversione, l'assert Python di questo snippet viene convertito in un grafico che utilizza l'appropriato tf.Assert.
def f(x): assert x != 0, 'Do not pass zero!' return x * x
Aggiungere facilmente ai grafici i loop, controllare il flusso e altro, significa che spostare il ciclo di addestramento nel grafico è semplice. Possiamo vederne un esempio in questo notebook dove prendiamo un ciclo di addestramento RNN e lo eseguiamo con una singola chiamata sess.run(). Questa operazione potrebbe essere utile quando è necessario passare l'intero loop di addestramento all'acceleratore, piuttosto che gestire l'addestramento tramite un controller della CPU.
AutoGraph offre nuovi modi di pensare alla creazione e all'addestramento dei modelli. Non vediamo l'ora di aggiungere ulteriori funzionalità ad AutoGraph in base ai suggerimenti della community degli sviluppatori, quindi ti preghiamo di segnalarci qualsiasi problema!
Eager execution è di facile utilizzo ma i grafici possono essere più veloci. Sebbene il benchmarking sia complesso (e dipende sia dall'applicazione che dalla configurazione hardware), in questo semplice esempio vediamo un significativo aumento della velocità quando passiamo dal codice Eager a quello AutoGraph, che fa grande uso di if e while.
In definitiva, AutoGraph consente di utilizzare i modelli dinamici e con controllo del flusso sull'hardware dell'acceleratore, come GPU e TPU Cloud, necessari quando addestriamo modelli di grandi dimensioni su molti dati.
Siamo agli inizi del processo di esplorazione delle prestazioni, quindi segnalaci qualsiasi problema se trovi un costrutto grafico che funziona più lentamente del previsto.
Anche se utilizzi Eager Execution, puoi comunque sfruttare l'esecuzione di grafici per alcune parti del codice tramite tf.contrib.eager.defun. Ciò richiede l'utilizzo di grafici TensorFlow ops come tf.cond(). In futuro AutoGraph sarà perfettamente integrato con defun per consentire la creazione del codice di grafico in puro Python stile Eager. Una volta completata l'implementazione, potrai utilizzare AutoGraph per accelerare gli hotspot trasformando selettivamente il codice Eager in frammenti di grafici.
AutoGraph è uno strumento che consente di creare facilmente modelli intuitivi e complessi, eseguibili senza difficoltà nei grafici TensorFlow. Per ora questo è uno strumento sperimentale in contrib, ma prevediamo di spostarlo presto nel core TensorFlow.
Raccontaci la tua esperienza con AutoGraph. Segnalaci qualsiasi problema e, se hai feedback, suggerimenti o idee, invia i tuoi messaggi al gruppo degli sviluppatori TensorFlow.
Ringraziamenti
Vogliamo ringraziare in modo particolare Andrew Johnson, Bart van Merriënboer, Zachary Nado e Alex Passos per il contributo fondamentale. E anche ringraziare i nostri colleghi: Akshay Agrawal, Mark Daoust, Josh Levenberg, Dougal Maclaurin, Rajat Monga, Mahima Pushkarna, Alexey Radul, D. Sculley e Asim Shankar.
In questa serie “Two Minute Actions”, prendiamo un’idea e spieghiamo il procedimento per implementarla come Action per l’Assistente Google utilizzando le potenti funzionalità di Actions on Google.
Non lasciar finire l'estate senza aver provato l’audio a esecuzione prolungata in spiaggia. Puoi farlo ascoltando ore di audio sul tuo altoparlante smart.
Abbiamo bisogno di un modo per riprodurre l'audio a esecuzione più prolungata sugli altoparlanti smart. Actions on Google ha un lettore multimediale che consente di riprodurre i file audio.
Per il contenuto puoi trovare migliaia di suoni gratuiti nella libreria audio di Actions. Ti consigliamo di provare alcuni dei suoni ambientali. Quindi, puoi combinare queste tracce audio per renderle lunghe abbastanza utilizzando un editor audio gratuito come Audacity o una utility come SoX. Queste tracce possono essere ospitate online con servizi come Cloud Storage for Firebase.
Se desideri creare una playlist di tracce audio, il lettore multimediale di Actions on Google ha una funzione particolare che richiama un callback dopo il completamento della riproduzione utilizzando l’intento ‘actions.intent.MEDIA_STATUS’. Puoi usarlo per invocare un altro giocatore e riprodurre la traccia successiva nell'elenco.
Per attivare l'Action, un utente può semplicemente richiamarla per nome. Ancora meglio, l'Assistente Google ha recentemente aggiunto una nuova funzionalità che consente agli utenti di pianificare le routine. È facile progettare la tua Action con un intento di attivazione che viene richiamato quando l'utente esegue la sua routine. Vai alla Console Actions per configurare l'azione e ricevere suggerimenti automatici di routine.
Un buon punto di partenza per l’Action è la creazione di una delle nostre Actions di esempio. Basta fare clic su questo link e in un minuto otterrai un agente Dialogflow funzionante con codice di fulfillment per riprodurre i file multimediali che puoi estendere per realizzare questa Action.
Ulteriori informazioni? Vai a vedere la community Actions on Google per discutere Actions con gli sviluppatori. Partecipa al programma community degli sivluppatori di Actions on Google per guadagnare 200 $ mensili in credito Google Cloud e una t-shirt dell’Assistente, quando pubblichi la tua prima app.
