Supporto dispositivi e session report
A causa delle differenze di hardware e prestazioni dei dispositivi, spesso le funzioni AR non possono funzionare su tutti i dispositivi. Perciò, quando si usano funzioni AR, è molto importante valutare con precisione il supporto del dispositivo corrente. Questo articolo spiega come viene espressa la disponibilità del dispositivo in Unity e come ottenere informazioni sul supporto del dispositivo e sulla disponibilità della session tramite session report (ARSession.Report).
Prima di iniziare
- Comprendere i concetti di base, la composizione e il workflow della session tramite introduzione ad ARSession
Supporto dispositivi, disponibilità della session e assembly
I dispositivi supportati da ogni funzione AR sono diversi. Ad esempio, motion tracking ha determinati requisiti per i componenti hardware e di solito richiede la calibrazione del dispositivo, mentre image tracking può funzionare su quasi tutti i dispositivi con una camera disponibile. Quindi, per stabilire se un'app AR può funzionare su un certo dispositivo, di solito è necessario sapere quali funzioni AR vengono usate, o in altre parole stabilire se una certa session può funzionare sul dispositivo.
In Unity, il processo di valutazione sopra descritto viene completato nella fase di session assembly (Assemble()). Il processo di assembly decide lo stato finale prima dell'avvio della session in base ai componenti contenuti nella session e al supporto del dispositivo corrente.
Se l'assembly riesce, la session entra nello stato Ready e può continuare ad avviarsi e funzionare. Se l'assembly fallisce, la session entra nello stato Broken, e la causa specifica dell'errore può essere consultata tramite session report (ARSession.Report).
Session report
La proprietà ARSession.Report fornisce il report runtime della session. Un session report contiene i seguenti campi:
| Proprietà | Descrizione |
|---|---|
| Availability | Report completo di disponibilità |
| BrokenReason | Motivo del danneggiamento della session, valido quando lo stato della session è Broken |
| Exception | Exception specifica del danneggiamento della session, valida quando lo stato della session è Broken |
Nel session report, è possibile usare Availability per consultare la disponibilità di ogni componente, oppure BrokenReason per consultare il motivo dettagliato quando la session è danneggiata.
Esempio di session report
Ad esempio, su Windows, se la session contiene ImageTrackerFrameFilter, CameraDeviceFrameSource e alcuni altri componenti frame source, il processo di assembly controlla la disponibilità di ogni componente e genera il seguente report:
Si può vedere che, anche se Availability del componente ARCoreFrameSource è Unavailable, poiché Availability di ImageTrackerFrameFilter e CameraDeviceFrameSource sono entrambi Available, l'assembly dell'intera session riesce e la session entra correttamente nello stato Ready.
Se rimuoviamo CameraDeviceFrameSource dalla session, il processo di assembly genera il seguente report:
Si può vedere che il numero nella lista FrameSources passa da 9 a 8. Anche se Availability del componente ImageTrackerFrameFilter è ancora Available, poiché non esiste un componente frame source disponibile, l'assembly dell'intera session fallisce e la session entra nello stato Broken. A questo punto il valore del campo BrokenReason nel report è NoAvailabileFrameSource, indicando che non c'è frame source disponibile.
Oltre al processo di assembly, la session può danneggiarsi anche durante il runtime, ad esempio se un componente in esecuzione viene rimosso accidentalmente. In quel momento è comunque possibile consultare la causa specifica tramite session report.
Aggiornamento del report
Il session report cambia nei seguenti momenti:
Completamento della prima fase di assembly
In questo momento viene generato un session report completo, incluso il report di disponibilità dei componenti. La parte Availability del session report viene determinata in questo momento e non cambia più. È possibile ottenere aggiornamenti del report di disponibilità dei componenti tramite l'evento AssembleUpdate.
Se la session viene avviata direttamente dopo l'assembly, è possibile ottenere aggiornamenti del session report anche tramite l'evento StateChanged. Gli stati della session da osservare includono: Ready e Broken.Completamento della seconda fase di assembly In questo momento viene generato un nuovo report di disponibilità dei componenti. A meno che la session non venga riavviata, il session report non verrà aggiornato. È possibile ottenere aggiornamenti del report di disponibilità dei componenti tramite l'evento AssembleUpdate.
Quando la session si avvia o quando la session si danneggia durante il runtime
BrokenReason e Exception nel session report verranno aggiornati. È possibile ottenere aggiornamenti del session report tramite l'evento StateChanged. Gli stati della session da osservare includono: Broken.
Contenuto del report: motivi del danneggiamento della session
BrokenReason indica il motivo del danneggiamento della session. Esistono i seguenti casi:
| Motivo | Descrizione |
|---|---|
| Uninitialized | Processo di assembly: EasyAR Sense non è stato inizializzato correttamente |
| LicenseInvalid | Processo di assembly: verifica della license EasyAR Sense fallita o non applicabile all'uso corrente |
| SessionObjectIncomplete | Processo di assembly: object session incompleto. Ad esempio RendererFeature non è configurato correttamente in URP |
| NoAvailabileFrameSource | Processo di assembly: nessun frame source disponibile. Ad esempio tutti i frame source non sono disponibili o non è stato aggiunto alcun frame source. Solo nella configurazione session predefinita, questa situazione indica il supporto del dispositivo per la funzione AR attualmente selezionata |
| FrameSourceIncomplete | Processo di assembly: frame source incompleto. Di solito accade quando un custom frame source non implementa correttamente l'interface frame source |
| FrameFilterNotAvailabile | Processo di assembly: esiste un frame filter non disponibile. Questa situazione esiste solo con alcune opzioni di assembly. |
| StartFailed | Avvio fallito. Ad esempio si verifica una exception durante l'avvio |
| RunningFailed | Runtime fallito. Ad esempio un componente in esecuzione viene rimosso accidentalmente, oppure RendererFeature non è configurato correttamente in URP. |
Contenuto del report: informazioni di disponibilità
Availability fornisce le informazioni di disponibilità di ogni componente nella session. Contiene i seguenti campi:
| Campo | Descrizione |
|---|---|
| FrameFilters | Lista di disponibilità dei frame filter controllati durante assembly |
| FrameSources | Lista di disponibilità dei frame source controllati durante assembly |
| PendingDeviceList | Attività di download della lista dispositivi non completata |
| DeviceList | Risultato del download della lista dispositivi |
I campi PendingDeviceList e DeviceList vengono usati per indicare lo stato di download della lista di supporto dispositivi. Quando la prima fase di assembly è completata, se e solo se PendingDeviceList non è vuoto, l'assembly entra nella seconda fase. Questa condizione può essere usata per stabilire se AssembleUpdate verrà eseguito una seconda volta.