Comprobar la disponibilidad de la session y el soporte del dispositivo
Antes de iniciar AR, normalmente primero hay que comprobar si la session está disponible y si el dispositivo actual admite las funciones AR necesarias. Este artículo explica cómo hacer esas comprobaciones.
Antes de empezar
- Consulte Introducción a ARSession para entender los conceptos básicos, los componentes y el flujo de trabajo de una session.
- Consulte Soporte del dispositivo e informes para entender los conceptos básicos del soporte de dispositivos y los informes de session en Unity.
- Aprenda cómo crear una session.
Obtener el informe durante el proceso de inicio
Si la session se inicia directamente después del assemble, puede obtener el informe de session mediante el evento StateChanged.
Debe suscribirse al evento StateChanged antes de iniciar la session; normalmente es seguro hacerlo en Awake():
void Awake()
{
Session.StateChanged += HandleSessionStateChange;
}
Los estados de session que hay que vigilar en el manejo del evento son Ready y Broken. El estado Ready indica que la session se inició correctamente, es decir, que está disponible en el dispositivo actual. El estado Broken indica que el inicio falló, es decir, que la session no está disponible en el dispositivo actual.
El estado Broken no siempre aparece cuando el dispositivo no es compatible. Por eso también hay que usar SessionReport.BrokenReason para obtener la causa exacta del fallo.
void HandleSessionStateChange(ARSession.SessionState status)
{
if (status == ARSession.SessionState.Ready)
{
// session disponible en el dispositivo actual
}
else if (status == ARSession.SessionState.Broken)
{
// session no disponible en el dispositivo actual
if (Session.Report.BrokenReason == SessionReport.SessionBrokenReason.NoAvailabileFrameSource ||
Session.Report.BrokenReason == SessionReport.SessionBrokenReason.FrameFilterNotAvailabile)
{
// el componente seleccionado no es compatible con el dispositivo actual
}
else
{
// causa no relacionada con el dispositivo
}
}
}
Las causas SessionReport.SessionBrokenReason.NoAvailabileFrameSource y SessionReport.SessionBrokenReason.FrameFilterNotAvailabile indican que los componentes de la session no están disponibles en el dispositivo actual; las demás causas suelen ser independientes del dispositivo. En sentido estricto, estas dos causas significan que la configuración actual, y solo esa configuración, no puede ejecutar las funciones AR en ese dispositivo. La configuración se refiere a las funciones y ajustes elegidos en el objeto session. Puede obtener un informe detallado de disponibilidad desde Report.
En el caso de SessionReport.SessionBrokenReason.NoAvailabileFrameSource, si al actualizar la lista de dispositivos en línea durante el inicio de la session se detecta que el dispositivo ya es compatible, la session puede recuperarse automáticamente.
Obtener el informe antes de iniciar
Si desea decidir antes de iniciar la session y, según el caso, arrancarla o no, puede llamar manualmente a Assemble() y usar el evento AssembleUpdate para obtener el informe de disponibilidad de componentes.
Debe suscribirse al evento AssembleUpdate antes del assemble de la session.
Session.AssembleUpdate += OnAssembleUpdate;
En la primera fase del assemble aún puede usar ARSession.SessionState y Report para juzgar si la session está soportada. Pero el informe de la segunda fase no se actualiza en la session.
Por eso, cuando se llama manualmente a Assemble(), normalmente hay que procesar el informe de disponibilidad en el evento AssembleUpdate para determinar si la session está disponible en el dispositivo actual.
Hay que prestar especial atención a la disponibilidad de los componentes en la lista SessionReport.AvailabilityReport.FrameSources. Si al menos un componente frame source está disponible, la parte SessionReport.AvailabilityReport.FrameSources está disponible en el dispositivo actual.
También hay que prestar atención a la disponibilidad de los componentes en la lista SessionReport.AvailabilityReport.FrameFilters. Pero el criterio cambia según las opciones de assemble: puede requerirse que todas las frame filters estén disponibles, o que lo esté solo una parte de ellas. Con la opción predeterminada, se exige que todas las frame filters estén disponibles.
Con la configuración por defecto, puede usar el siguiente código para comprobar si los componentes de session están disponibles en el dispositivo actual:
void OnAssembleUpdate(SessionReport.AvailabilityReport report)
{
if (report.FrameSources.Any(f => f.Availability == SessionReport.AvailabilityReport.AvailabilityStatus.Available) &&
report.FrameFilters.All(f => f.Availability == SessionReport.AvailabilityReport.AvailabilityStatus.Available))
{
Session.AssembleUpdate -= OnAssembleUpdate;
// los componentes de la session están disponibles en el dispositivo actual, se puede iniciar la session
Session.StartSession();
}
else
{
// los componentes de la session no están disponibles en el dispositivo actual
}
if (report.PendingDeviceList.Count <= 0)
{
Session.AssembleUpdate -= OnAssembleUpdate;
}
}
Tenga en cuenta que el evento AssembleUpdate puede dispararse dos veces. En el ejemplo anterior, la suscripción se cancela después de confirmar que los componentes están disponibles.
Este método no permite detectar otros errores posibles durante el inicio de la session, pero esos errores suelen ser independientes del dispositivo. Si hace falta, puede complementar la comprobación tras iniciar la session mediante el evento StateChanged.
Qué hacer cuando los componentes de la session no están disponibles
En el desarrollo de aplicaciones, normalmente se busca compatibilidad con el mayor número posible de dispositivos. Cuando los componentes de la session no están disponibles en el dispositivo actual, puede considerar estas opciones:
Degradar a otras funciones AR
Modifique la configuración de los componentes de la session y elija las funciones AR que sí admita el dispositivo actual. Consulte crear una session para ver cómo cambiar la configuración.Ofrecer una experiencia no AR
Cuando los componentes de la session no estén disponibles, ofrezca una experiencia sin AR. Por ejemplo, en escenarios de navegación, si no se puede usar navegación AR, una navegación 2D tradicional resulta muy útil.Pedir al usuario que cambie de dispositivo
En algunos casos, el usuario puede usar un dispositivo que no admite funciones AR. En ese caso, puede pedirle que cambie de dispositivo para obtener una mejor experiencia.
Al elegir estas opciones, puede valorar las necesidades concretas de la aplicación y el público objetivo. En una aplicación AR, si algunos dispositivos realmente no pueden ofrecer AR ni una solución degradada, sigue siendo importante mostrar un buen mensaje al usuario para que entienda las limitaciones del dispositivo.
Siguientes pasos
- Aprenda cómo controlar la ejecución de la session
- Aprenda fuente de frames y selección en tiempo de ejecución
- También puede consultar estos ejemplos para ver casos de uso después de obtener el informe:
- ejemplo Workflow_ARSession usa el evento StateChanged y muestra una UI para el estado Broken, además de usar AssembleUpdate para mostrar en la UI la disponibilidad de cada componente
- El ejemplo SpatialMap_Sparse_AllInOne usa el evento AssembleUpdate para comprobar con antelación el soporte del dispositivo y mostrar avisos si no está disponible
- El ejemplo MotionTracking_DeviceMotionAndPlaneDetection usa el evento StateChanged y muestra una UI para el estado Broken
- El ejemplo MegaBlock_Basic usa el evento StateChanged y muestra una UI para el estado Broken