Проверка доступности сессии и поддержки устройств

Перед запуском AR обычно необходимо проверить, доступна ли сессия и поддерживает ли текущее устройство требуемые функции AR. В этой статье объясняется, как выполнить эти проверки.

Перед началом

Ознакомьтесь с основными концепциями, компонентами и рабочим процессом сессии в разделе Введение в ARSession
Узнайте основы поддержки устройств и отчетов сессий в Unity в разделе Поддержка устройств и отчеты
Узнайте, как создать сессию

Получение отчета в процессе запуска

Если сессия запускается сразу после сборки, отчет сессии можно получить через событие StateChanged.

Необходимо подписаться на событие StateChanged до запуска сессии. Обычно безопасно выполнять подписку в методе Awake():

void Awake()
{
    Session.StateChanged += HandleSessionStateChange;
}

Состояния сессии, на которые следует обратить внимание в обработчике событий: Ready и Broken. Состояние Ready означает, что сессия успешно запущена, что также указывает на доступность сессии на текущем устройстве. Состояние Broken означает, что запуск сессии не удался, что указывает на недоступность сессии на текущем устройстве.

Состояние Broken не всегда возникает из-за неподдерживаемого устройства. Поэтому для получения конкретной причины сбоя необходимо использовать SessionReport.BrokenReason.

void HandleSessionStateChange(ARSession.SessionState status)
{
    if (status == ARSession.SessionState.Ready)
    {
        // сессия доступна на текущем устройстве
    }
    else if (status == ARSession.SessionState.Broken)
    {
        // сессия недоступна на текущем устройстве
        if (Session.Report.BrokenReason == SessionReport.SessionBrokenReason.NoAvailabileFrameSource ||
            Session.Report.BrokenReason == SessionReport.SessionBrokenReason.FrameFilterNotAvailabile)
        {
            // выбранные компоненты не поддерживаются текущим устройством
        }
        else
        {
            // причины, не связанные с устройством
        }
    }
}

Причины SessionReport.SessionBrokenReason.NoAvailabileFrameSource и SessionReport.SessionBrokenReason.FrameFilterNotAvailabile указывают, что компоненты сессии недоступны на текущем устройстве; другие причины обычно не связаны с устройством. Строго говоря, эти две причины означают, что функции AR в текущей конфигурации (и только в этой конфигурации) не могут работать на данном устройстве. Под конфигурацией подразумеваются выбранные функции и настройки объекта сессии. Подробный отчет о доступности можно получить из Report.

В случае SessionReport.SessionBrokenReason.NoAvailabileFrameSource, сессия может автоматически восстановиться, если во время запуска при обновлении списка устройств через интернет обнаружится, что устройство теперь поддерживается.

Получение отчета перед запуском

Если необходимо проверить до запуска сессии и принять решение о запуске на основе результатов, можно вручную вызвать Assemble() и использовать событие AssembleUpdate для получения отчета о доступности компонентов.

Необходимо подписаться на событие AssembleUpdate до сборки сессии:

Session.AssembleUpdate += OnAssembleUpdate;

На первом этапе сборки все еще можно использовать ARSession.SessionState и Report для проверки поддержки сессии. Однако отчеты второго этапа не обновляются в сессии.

Поэтому при ручном вызове Assemble() обычно необходимо обрабатывать отчет о доступности компонентов в событии AssembleUpdate, чтобы определить, доступна ли сессия на текущем устройстве.

Важно проверить доступность компонентов в списке SessionReport.AvailabilityReport.FrameSources. Если доступен хотя бы один компонент frame source, то часть SessionReport.AvailabilityReport.FrameSources доступна на текущем устройстве.

Также необходимо проверить доступность компонентов в списке SessionReport.AvailabilityReport.FrameFilters. Однако критерии проверки различаются в зависимости от опций сборки: может требоваться доступность всех frame filter или любого количества frame filter. По умолчанию требуется доступность всех frame filter.

При конфигурации по умолчанию можно использовать следующий код для проверки доступности компонентов сессии на текущем устройстве:

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;
        // компоненты сессии доступны на текущем устройстве, можно запускать сессию
        Session.StartSession();
    }
    else
    {
        // компоненты сессии недоступны на текущем устройстве
    }
    if (report.PendingDeviceList.Count <= 0)
    {
        Session.AssembleUpdate -= OnAssembleUpdate;
    }
}

Обратите внимание, что событие AssembleUpdate может сработать дважды. В приведенном примере кода подписка отменяется после подтверждения доступности компонентов.

Этот метод проверки не позволяет выявить другие ошибки, которые могут возникнуть во время запуска сессии, но они обычно не связаны с устройством. При необходимости можно выполнить дополнительную проверку после запуска сессии через событие StateChanged.

Варианты действий при недоступности компонентов сессии

При разработке приложений обычно стремятся обеспечить совместимость с как можно большим количеством устройств. Поэтому, если компоненты сессии недоступны на текущем устройстве, можно рассмотреть следующие варианты:

Использовать альтернативные функции AR
Измените конфигурацию компонентов сессии, выбрав функции AR, поддерживаемые текущим устройством. Подробнее о изменении конфигурации компонентов сессии см. в разделе Создание сессии.
Предоставить не-AR опыт
При недоступности компонентов сессии предоставьте не-AR опыт. Например, в сценариях навигации полезно предоставить традиционную 2D-навигацию, если AR-навигация невозможна.
Предложить пользователю сменить устройство
В некоторых сценариях пользователи могут использовать устройства без поддержки AR. В этом случае можно предложить им сменить устройство для лучшего опыта.

При выборе этих вариантов следует учитывать конкретные потребности приложения и целевую аудиторию. В AR-приложениях, если на некоторых устройствах действительно невозможно предоставить AR или альтернативное решение, все равно необходимо предоставить пользователю понятное сообщение, чтобы он понимал ограничения текущего устройства.

Следующие шаги