Modularização do MRTK – MRTK2

Um dos grandes novos recursos de Realidade Misturada Toolkit v2 é a melhor componenteização. Sempre que possível, os componentes individuais são isolados de todos, exceto da camada principal da base.

Dependências minimizadas

O MRTK v2 foi desenvolvido intencionalmente para ser modular e minimizar as dependências entre os serviços do sistema (ex: reconhecimento espacial).

Devido à natureza de alguns serviços do sistema (por exemplo: entrada e teletransporte), existe um pequeno número de dependências.

Embora se espere que os serviços precisem de um ou mais componentes do provedor de dados, não há links diretos entre eles. O mesmo acontece com os recursos do SDK (por exemplo: componentes da Interface do Usuário).

Comunicação de componente

Para garantir que não haja links diretos entre componentes, o MRTK v2 utiliza interfaces para se comunicar entre serviços, provedores de dados e código de aplicativo. Essas interfaces são definidas e toda a comunicação é roteada por meio do componente principal Realidade Misturada Toolkit.

Using the spatial awareness system via interfaces

Minimizando o volume de importação do MRTK

Neste momento, o MRTK é importado como um único pacote de base (ignorando por um momento a existência do pacote de exemplos, que é um pacote completamente opcional). É possível tornar esse volume menor cortando manualmente os arquivos importados, embora este seja um processo altamente manual que não tem um guia bem definido.

É possível desmarcar itens arbitrários durante a importação do pacote foundation. No entanto, não é recomendável fazer isso em um estágio inicial de desenvolvimento, pois pode interromper a funcionalidade. Depois de descobrir o conjunto de recursos final de um aplicativo, a remoção de provedores e serviços desnecessários pode ser feita nas seguintes pastas:

  • MRTK/Serviços
  • MRTK/Provedores
  • MRTK/SDK/Features

Observação

O MRTK v2.x requer o conteúdo da pasta Assets/MRTK/Core.

Recursos futuros

Arquitetura do aplicativo

O MRTK terá suporte para permitir que os aplicativos sejam criados com uma variedade de arquiteturas, incluindo:

Ao selecionar uma arquitetura de aplicativo, é importante considerar a flexibilidade de design e o desempenho do aplicativo. As arquiteturas descritas aqui não devem ser adequadas para cada aplicativo.

Localizador de serviço MixedRealityToolkit

O MRTK habilita (e configura automaticamente) cenas de aplicativo para usar o componente do localizador de serviço padrão MixedRealityToolkit . Esse componente inclui suporte para configurar sistemas MRTK e provedores de dados por meio de inspetores de configuração e gerencia o tempo de vida dos componentes e comportamentos principais (ex: quando atualizar).

Todos os sistemas são representados no inspetor de configuração principal, independentemente de estarem presentes ou não no projeto. Consulte o Guia de Configuração do Realidade Misturada para obter mais informações.

Componentes de serviço individuais

Alguns desenvolvedores expressaram o desejo de incluir componentes de serviço individuais na hierarquia de cena do aplicativo. Para habilitar esse uso, os serviços precisarão ser encapsulados em um registrador personalizado ou ser auto-registrador/autogerenciamento.

Um serviço de auto-registro implementaria e IMixedRealityServiceRegistrar se registraria para que o código do aplicativo pudesse descobrir a instância de serviço por meio de um registro.

Um serviço de autogerenciamento pode ser implementado como um objeto singleton na hierarquia de cena. Esse objeto forneceria e a propriedade de instância que o código do aplicativo poderia usar para acessar diretamente a funcionalidade do serviço.

Localizador de serviço personalizado

Alguns desenvolvedores solicitaram a capacidade de criar um componente de localizador de serviço personalizado. Os localizadores de serviço personalizado implementariam a IMixedRealityServiceRegistrar interface e gerenciariam o ciclo de vida e os comportamentos principais dos serviços ativos.

Arquitetura híbrida

O MRTK dará suporte a uma arquitetura híbrida na qual os desenvolvedores podem combinar as abordagens anteriores conforme necessário ou desejado. Por exemplo, um desenvolvedor pode começar com o localizador de MixedRealityToolkit serviço e adicionar um serviço de auto-registro.

Observação

Ao optar por uma arquitetura híbrida, é importante estar atento a qualquer duplicação de trabalho (por exemplo: adquirir dados do controlador de vários componentes).