Modularidade do MRTK

um dos ótimos novos recursos da realidade misturada Toolkit v2 é a componentização aprimorada. Sempre que possível, os componentes individuais são isolados de todas, exceto a camada principal da base.

Dependências minimizadas

O MRTK v2 foi desenvolvido intencionalmente para ser modular e minimizar dependências entre serviços do sistema (por exemplo, conscientização espacial).

Devido à natureza de alguns serviços do sistema (por exemplo: entrada e teleportação), há um pequeno número de dependências.

Embora seja esperado que os serviços precisem de um ou mais componentes de provedor de dados, não há links diretos entre eles. O mesmo é verdadeiro para recursos do SDK (por exemplo, componentes de interface do usuário).

Comunicação de componente

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

Usando o sistema de reconhecimento espacial por meio de interfaces

Minimizando a superfície 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 essa superfície menor reduzindo manualmente os arquivos importados, embora esse seja um processo altamente manual que não tenha um guia bem definido.

É possível desmarcar itens arbitrários durante a importação do pacote do Foundation. No entanto, não é recomendável fazer isso em um estágio inicial do desenvolvimento, pois ela pode interromper a funcionalidade. Depois de ter descoberto 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/recursos

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 todos os aplicativos.

Localizador de serviço MixedRealityToolkit

O MRTK habilita (e configura automaticamente) cenas de aplicativos para usar o componente de MixedRealityToolkit localizador de serviço padrão. Este componente inclui suporte para configurar sistemas e provedores de dados MRTK por meio de inspetores de configuração e gerencia a vida útil do componente e os comportamentos principais (por exemplo: quando atualizar).

Todos os sistemas são representados no Inspetor de configuração principal, independentemente de estarem ou não presentes ou habilitados no projeto. Consulte o Guia de configuração da realidade misturada para obter mais informações.

Componentes de serviço individuais

Alguns desenvolvedores expressou um 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 em Autoregistro/autogerenciamento.

Um serviço de registro automático implementaria o IMixedRealityServiceRegistrar e se registrará para que o código do aplicativo pudesse descobrir a instância do 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 a propriedade de instância e o código do aplicativo que 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 personalizados implementariam a IMixedRealityServiceRegistrar interface e gerenciariam o ciclo de vida e os principais comportamentos 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 MixedRealityToolkit localizador de serviço e adicionar um serviço de registro automático.

Observação

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