Flutter per smart glass Google, UI battery-aware; compute su Jetson e ROS 2

Uno schermo fluido può mostrare dati vecchi. Su smart glass Google con Flutter conta la latenza evento-schermo e la freschezza, misurate end-to-end e non riassunte in un singolo FPS¹.

L’architettura è netta: Flutter resta strato di presentazione. Il lavoro specifico del dispositivo e quello pesante vivono su wearable SDK, servizi su Jetson, nodi ROS 2 e inferenza accelerata NVIDIA. Obiettivi: latenza prevedibile, memoria sotto controllo, osservabilità utile, degradazione ordinata. I loop di sicurezza restano sul robot. Flutter non è un controller hard real-time e non può essere l’unico meccanismo di sicurezza¹.

Prima si definiscono obiettivi misurabili. Freschezza, latenza evento-display, throughput, frame pacing, uso di CPU e memoria, rete, batteria, stato termico. Si contano messaggi scartati, tempi di riconnessione e acknowledgement dei comandi. Poi si strumenta l’intero percorso: cattura del sensore, elaborazione nativa o ROS, pubblicazione dal gateway, ricezione in Flutter, stato accettato, build del widget, frame renderizzato. Si registrano timestamp di sorgente e di ricezione. Dentro un processo si usano orologi monotoni. Tra dispositivi si considera l’offset e l’incertezza dell’orologio¹.

Le misure si fanno su hardware fisico, in profile mode. Si usa la vista Performance di Flutter DevTools. Il debug non offre una baseline attendibile. Si costruisce una baseline ripetibile: avvio pulito, connessione al robot o replay di una traccia fissa, scenario rappresentativo per alcuni minuti. Si cambia una variabile alla volta. Si raccolgono frame time, memoria, CPU, tassi di messaggi, conteggi di dati stale e reconnessioni. Si confrontano p50, p95 e p99, non solo le medie¹.

Acquisizione separata dalla presentazione. Le sorgenti ad alta frequenza non devono innescare rebuild diretti. Per dati di stato si usa una cache dell’ultimo valore con versione. Per eventi da preservare si usano code limitate. La cadenza di presentazione è controllata. Comandi, allarmi e audit hanno un canale affidabile con acknowledgement esplicito. Si contano ricevuti, accettati, scartati, stale e pubblicazioni UI con finestre o istogrammi a capacità limitata. Non si accumula ogni campione¹.

Il buffering è sempre limitato e con politiche chiare. Latest wins per posa, frame di preview e rilevazioni correnti. Drop dei vecchi per stream dove conta la freschezza. Persistenza per eventi che devono sopravvivere alla disconnessione. Reject con feedback per comandi che non è sicuro accodare. In caso contrario, l’overload diventa crescita di memoria invece di una condizione visibile e misurabile¹.

Si protegge il budget del frame Flutter. Niente parsing o trasformazioni in build(). Le schermate si dividono in sezioni aggiornate in modo indipendente. Camera e map non si ricostruiscono per stati non correlati. Il lavoro CPU-intensivo in Dart si misura tra compute e isolate con payload realistici, valutando costi di avvio e trasferimento. Per accelerazione hardware o API di piattaforma si preferisce un servizio nativo¹.

Il calcolo robotico resta vicino al robot: sensori verso nodi ROS 2 accelerati, gateway su Jetson, poi uno stato compatto verso la UI tramite WebSocket, MQTT o gRPC, infine il client Flutter. NVIDIA Isaac ROS offre pacchetti ROS 2 accelerati e a bassa latenza. Elaborazione d’immagine, inferenza e controllo robotico rimangono lato compute. Flutter riceve solo ciò che serve per visualizzazione e decisioni dell’operatore¹.

La staleness è uno stato esplicito. Ogni payload porta timestamp di sorgente e ricezione, numero di sequenza o versione, identità della sorgente e, se serve, qualità. La UI distingue zero da sconosciuto, disconnesso e stale. Il verde di salute non dipende dall’ultimo payload in sé¹.

Si valida la degradazione controllata. Si simulano ritardi e perdite di rete, burst, riavvii dei processi, perdita di permessi del wearable, stop della camera, rallentamenti dell’inferenza, memoria bassa e throttling termico. Sotto pressione si abbassa la risoluzione o la frequenza di update e si mettono in pausa grafici non essenziali. La visibilità di comandi e stato di sicurezza resta prioritaria¹.

Checklist di rilascio, in breve: baseline su hardware fisico, p50/p95/p99 misurate, code limitate e overflow osservabile, coalescenza degli stati ad alta frequenza, semantiche affidabili per comandi e allarmi, domini di clock e regole di staleness documentati, rete e riconnessioni testate, pressione termica e memoria testate, indipendenza della sicurezza dal mobile, budget di performance in test ripetibili¹.

Focus batteria. Si aumenta il rate quando l’utente ispeziona attivamente un sensore e lo si riduce in idle, background o low-power. Esempio di policy: active ? 100 ms : 1 s. È un punto di partenza. Va validato sul dispositivo e sul caso d’uso con misure reali¹.

Per i prossimi passi, il tutorial propone un esercizio completo: aggiungere timestamp e ID di sequenza al confine del gateway, catturare una traccia di carico normale e una di burst, implementare un buffer limitato con politica di overload esplicita, distinguere in UI stale, disconnesso e degradato, profilare sul target. Dettagli e link agli strumenti sono nella fonte¹: https://dev.to/vmodal_ai/google-smart-glasses-flutter-battery-aware-sensor-sampling-and-ui-scheduling-4bbo.