Suporte de dispositivos e session report
Devido às diferenças de hardware e desempenho dos dispositivos, muitas vezes as funções AR não podem ser executadas em todos os dispositivos. Portanto, ao usar funções AR, é muito importante avaliar com precisão o suporte do dispositivo atual. Este artigo explica como a disponibilidade de dispositivo é expressa no Unity e como obter informações de suporte de dispositivo e disponibilidade de session por meio de session report (ARSession.Report).
Antes de começar
- Entenda os conceitos básicos, a composição e o workflow de session por meio da introdução ao ARSession
Suporte de dispositivos, disponibilidade de session e assembly
Os dispositivos suportados por cada função AR são diferentes. Por exemplo, motion tracking tem certos requisitos para componentes de hardware e normalmente exige calibração do dispositivo, enquanto image tracking pode funcionar em quase todos os dispositivos com câmera disponível. Portanto, para determinar se um app AR pode ser executado em determinado dispositivo, normalmente é necessário saber quais funções AR estão sendo usadas atualmente, ou, em outras palavras, determinar se uma session pode ser executada no dispositivo.
No Unity, o processo acima é concluído na etapa de session assembly (Assemble()). O processo de assembly decide o estado final antes do início da session com base nos componentes contidos na session e no suporte do dispositivo atual.
Se o assembly for bem-sucedido, a session entrará no estado Ready e poderá continuar a ser iniciada e executada. Se o assembly falhar, a session entrará no estado Broken, e a causa específica da falha poderá ser consultada por meio de session report (ARSession.Report).
Session report
A propriedade ARSession.Report fornece o relatório runtime da session. Um session report contém os seguintes campos:
| Propriedade | Descrição |
|---|---|
| Availability | Relatório completo de disponibilidade |
| BrokenReason | Motivo de dano da session, válido quando o estado da session é Broken |
| Exception | Exception específica de dano da session, válida quando o estado da session é Broken |
No session report, é possível usar Availability para consultar a disponibilidade de cada componente, ou usar BrokenReason para consultar o motivo detalhado quando a session está danificada.
Exemplo de session report
Por exemplo, no Windows, se a session contiver ImageTrackerFrameFilter, CameraDeviceFrameSource e vários outros componentes frame source, o processo de assembly verificará a disponibilidade de cada componente e gerará o seguinte relatório:
Pode-se ver que, embora Availability do componente ARCoreFrameSource seja Unavailable, como Availability de ImageTrackerFrameFilter e CameraDeviceFrameSource são ambos Available, o assembly de toda a session é bem-sucedido, e a session entra com sucesso no estado Ready.
Se removermos CameraDeviceFrameSource da session, o processo de assembly gerará o seguinte relatório:
Pode-se ver que o número na lista FrameSources mudou de 9 para 8. Embora Availability do componente ImageTrackerFrameFilter ainda seja Available, como não há nenhum componente frame source disponível, o assembly de toda a session falha e a session entra no estado Broken. Nesse momento, o valor do campo BrokenReason no relatório é NoAvailabileFrameSource, indicando que não há frame source disponível.
Além do processo de assembly, a session também pode apresentar dano durante o runtime, por exemplo quando algum componente em execução é removido acidentalmente. Nesse caso, a causa específica do dano também pode ser consultada por meio de session report.
Atualização do relatório
Session report muda nos seguintes momentos:
Conclusão da primeira etapa de assembly
Nesse momento, um session report completo é gerado, incluindo o relatório de disponibilidade de componentes. A parte Availability do session report é determinada nesse momento e não muda mais. É possível obter atualizações do relatório de disponibilidade de componentes por meio do evento AssembleUpdate.
Se a session for iniciada diretamente após o assembly, também é possível obter atualizações de session report por meio do evento StateChanged. Os estados de session que precisam de atenção incluem: Ready e Broken.Conclusão da segunda etapa de assembly Nesse momento, um novo relatório de disponibilidade de componentes é gerado. A menos que a session seja reiniciada, session report não será atualizado. É possível obter atualizações do relatório de disponibilidade de componentes por meio do evento AssembleUpdate.
Quando a session inicia ou quando a session apresenta dano durante o runtime
BrokenReason e Exception no session report serão atualizados. É possível obter atualizações de session report por meio do evento StateChanged. Os estados de session que precisam de atenção incluem: Broken.
Conteúdo do relatório: motivos de dano da session
BrokenReason indica o motivo do dano da session. Existem as seguintes situações:
| Motivo | Descrição |
|---|---|
| Uninitialized | Processo de assembly: EasyAR Sense não foi inicializado com sucesso |
| LicenseInvalid | Processo de assembly: verificação de license do EasyAR Sense falhou ou não se aplica ao uso atual |
| SessionObjectIncomplete | Processo de assembly: session object incompleto. Por exemplo, RendererFeature não está configurado corretamente no URP |
| NoAvailabileFrameSource | Processo de assembly: nenhum frame source disponível. Por exemplo, todos os frame sources estão indisponíveis ou nenhum frame source foi adicionado. Apenas na configuração session padrão, essa situação indica o suporte do dispositivo para a função AR atualmente selecionada |
| FrameSourceIncomplete | Processo de assembly: frame source incompleto. Geralmente ocorre quando um custom frame source não implementa corretamente a interface frame source |
| FrameFilterNotAvailabile | Processo de assembly: existe um frame filter indisponível. Essa situação existe apenas em algumas opções de assembly. |
| StartFailed | Falha ao iniciar. Por exemplo, ocorre uma exception durante o início |
| RunningFailed | Falha em runtime. Por exemplo, um componente em execução é removido acidentalmente, ou RendererFeature não está configurado corretamente no URP. |
Conteúdo do relatório: informações de disponibilidade
Availability fornece informações de disponibilidade de cada componente na session. Ele contém os seguintes campos:
| Campo | Descrição |
|---|---|
| FrameFilters | Lista de disponibilidade de frame filter verificada durante assembly |
| FrameSources | Lista de disponibilidade de frame source verificada durante assembly |
| PendingDeviceList | Tarefa de download da lista de dispositivos não concluída |
| DeviceList | Resultado do download da lista de dispositivos |
Os campos PendingDeviceList e DeviceList são usados para indicar o status de download da lista de suporte de dispositivos. Quando a primeira etapa de assembly termina, se e somente se PendingDeviceList não estiver vazio, o assembly entra na segunda etapa. É possível usar essa condição para determinar se AssembleUpdate será executado uma segunda vez.