Content directories: Beyond the AssetBundle

Sep 22, 2026|6 Min

George Ing - Unity Technologies

Senior Engineering Manager

Esta página da Web foi automaticamente traduzida para sua conveniência. Não podemos garantir a precisão ou a confiabilidade do conteúdo traduzido. Se tiver dúvidas sobre a precisão do conteúdo traduzido, consulte a versão oficial em inglês da página da Web.

Clique aqui.

Um pouco sobre conteúdo no Unity hoje

Desde o Unity 2.1, o humilde AssetBundle tem sustentado o conteúdo do Unity enviado fora do binário do Player. Nestes últimos vinte anos, um número extraordinário de jogos utilizou AssetBundles como sua representação de dados, incluindo alguns dos maiores títulos do mundo.

Em um nível básico, cada AssetBundle é uma unidade indivisível para distribuição, armazenamento e carregamento. Os AssetBundles rastreiam suas dependências em um nível de pacote, formando uma unidade monolítica maior que, para eficiência, precisa ser baixada, carregada e descarregada junta.

Devido a esta especificação, a forma como um título define seu layout de AssetBundle é um fator primordial em tudo, desde o desempenho em tempo de execução até o tamanho do download. Isso é verdade quer usando AssetBundles diretamente, ou via o pacote Addressables.

Hoje, vamos falar sobre algo diferente para o runtime da Unity.

Apresentando diretórios de conteúdo

Diretórios de conteúdo são um substituto fundamental, mais performático e mais granular para AssetBundles. Eles estão disponíveis hoje no Unity 6.6 como uma alternativa para AssetBundles enviados com o Player. Durante a geração Unity 7, a pilha de tecnologia se expandirá para lidar com entrega completa e granular via ar (mais sobre isso mais tarde - é muito legal).

Em vez de assar ativos em grandes unidades carregáveis, os diretórios de conteúdo fornecem ao runtime da Unity a capacidade de identificar, carregar e descarregar individualmente artefatos(malhas, texturas, etc.) com saturação total dos recursos de hardware e deduplicação implícita de conteúdo.

Diagrama mostrando como os ativos do Unity são carregados do armazenamento local para a memória de trabalho. À esquerda, um painel "Armazenamento local" contém nove ícones de ativos do Unity (malhas 3D, atlases de sprites, clipes de áudio e prefabs). Uma seta rotulada "Carregar individualmente" aponta para a direita para um painel "Memória de trabalho" contendo apenas três desses ativos, com espaço vazio abaixo rotulado "Disponível para outros trabalhos." Abaixo da seta, um subtítulo diz "Carregar → usar → liberar."

Gerenciar conteúdo em projetos Unity agora é mais fácil do que nunca, com builds mais rápidos e menos preocupações sobre a localização de ativos e layouts de AssetBundle.

Os jogos que você constrói são menores, mais rápidos, deduplicando implicitamente e obtêm acesso ao gerenciamento de memória dinâmica completo através de um novo tipo de referência carregável. Para quem usa Addressables para conteúdo empacotado com o Player, você pode mudar para diretórios de conteúdo comalterações de código zero.

Como fizemos isso acontecer? Vamos dar uma olhada sob o capô de cada estágio do pipeline.

Uma base familiar: Construir

Em 2019, estávamos discutindo o que queríamos de uma fundação de construção séria no Unity - paralela em todos os núcleos, determinística, totalmente em cache e capaz de compartilhar seus dados de construção entre máquinas. Bem, acabou que alguns dos nossos colegas vinham enviando uma API com exatamente essas propriedades por anos, o framework de importação de ativos.

Então, o processo de construção do diretório de conteúdo é executado dentro da estrutura padrão do importador de ativos. Cada ativo é construído individualmente por um importador de ativos, isolado e fora de processo. As compilações são determinísticas, com cache de banco de dados de ativos, saturação total de todos os núcleos de hardware e suporte nativo a aceleradores para compilações compartilhadas rápidas.

Este pode não ser o primeiro momento em que você ouviu falar sobre este sistema de construção. Alguns de vocês podem se lembrar do pipeline de compilação multi-processo que antecipamos no Unity 2023.1. Esta é a mesma fundação.

Diagrama mostrando como os arquivos de origem são convertidos em ativos do Unity via Build Importer. Dois arquivos FBX produzem dois objetos AssetBundle (mostrados como ícones de pacote azuis e cinzas), enquanto dois arquivos PNG produzem um único ativo de sprite/textura (mostrados como ícones de quadrado xadrez). As setas ramificadas dos arquivos FBX ilustram que um único arquivo de origem 3D pode gerar múltiplos ativos de tempo de execução.

A saída é um grupo solto de artefatos altamente granulares, um pequeno manifesto rastreando dependências entre eles e um novo conjunto de arquivos de diagnóstico para tornar mais fácil do que nunca entender sua compilação.

É incrivelmente simples.

Uma base familiar: Endereçando

Se você abrir um diretório de conteúdo build e der uma olhada nos artefatos, você notará que cada artefato tem um nome com hash bem estranho:

c0152db4dd710be51b2decb997325f34.cf
f0a44ad4a4babd121543fd44032928e7.resS
4226b5c16a50dab6eff0f08dd1253d4b.resource

É o que é legal - isso não é um hash aleatório. Em vez disso, o sistema de diretório de conteúdo usa o mesmo padrão de armazenamento endereçado por conteúdo usado por tecnologias como Git. Cada arquivo de conteúdo é nomeado e referenciado por um hash de seu conteúdo. Este padrão é incrivelmente útil para o tempo de execução do Unity porque permite que ele deduplique conteúdo implicitamente como um recurso nativo.

Dito isto, o armazenamento endereçado por conteúdo com um grafo de dependência verdadeiro corre o risco de alta taxa de alteração. Considere a relação mais simples possível entre dois artefatos:

A → B

Atualize B e as mudanças de hash de B. Infelizmente, porque A referencia B, o hash de A também muda. Pior ainda, isso se espalha por toda a cadeia.

Em vez disso, os artefatos não se referenciam pelo hash de conteúdo, eles se referenciam por ID estável. O manifesto de compilação mantém uma pequena tabela de consulta mapeando IDs estáveis para hashes de conteúdo.

Com isso, o tempo de execução tem tudo o que precisa para carregar!

Uma base familiar: Carregar

Em diretórios de conteúdo, introduzimos um sistema de carregamento dinâmico incrivelmente performático.

Quando um diretório de conteúdo é montado, o sistema de carregamento lê o manifesto e resolve as dependências de ID estável entre os artefatos. Permite que cada artefato seja carregado e descarregado inteiramente de forma independente, com zero poluição de artefatos co-localizados (lembre-se daquele problema com AssetBundles - uma unidade monolítica e indivisível? Sumido.)

Para usuários do DOTS, o formato de arquivo subjacente dos artefatos também pode parecer bem familiar. Os diretórios de conteúdo produzem e carregam a próxima geração do formato de arquivo de conteúdo que introduzimos no DOTS em 2022, trazendo a tecnologia que impulsionou o carregamento de Entities multi-threaded por quatro anos para todos os assets.

Este é um sistema de carregamento que é totalmente assíncrono em ambas as operações de leitura e desserialização. Isso significa maior largura de banda de carregamento e utilização de APIs de leitura assíncrona específicas da plataforma.

Diagrama comparando dois pipelines de carregamento de assets do Unity. A seção superior, rotulada como "AssetBundles", mostra um arquivo serializado processado sequencialmente: cada recurso passa por Leitura, depois Desserialização, um de cada vez, antes de uma etapa final de Awake, com uploads para a GPU ocorrendo apenas no final. Isto é rotulado como "Sequencial." A seção inferior, rotulada como "Diretórios de conteúdo", mostra um arquivo de conteúdo usando um pipeline jobificado: todos os ativos são lidos em paralelo primeiro, depois as etapas Deserialize e Awake de cada ativo são escalonadas e sobrepostas, com uploads de GPU distribuídos ao longo do processo. Isto é rotulado como "Jobified", ilustrando a vantagem de desempenho do carregamento paralelizado sobre a abordagem sequencial do AssetBundle.

Mais empolgantemente, a fundação do diretório de conteúdo nos permite trazer um tipo de referência carregável moderno para Unity pela primeira vez, chamado Loadable.

Loadable bodyMesh;
bodyMesh.Load();

Este é um referenciador carregável real, construído diretamente no motor para projetos baseados em diretório de conteúdo. Objetos referenciados por Loadables serão puxados para o build, mas não serão carregados até que você invoque o Loadable. Acoplar Loadables com a interface ScriptableObject (muito) familiar permite que você organize conteúdo carregado dinamicamente incrivelmente rapidamente.

Esse é um princípio sobre o qual estamos muito entusiasmados. Com diretórios de conteúdo e Loadables como base, qualquer asset no Unity pode se tornar uma unidade carregada e descarregada independentemente - uma capacidade construída diretamente no motor - desde as partes de um criador de personagens até os pedaços de um terreno transmitido, sem layouts de AssetBundle ou definições de grupo para projetar.

Construir jogos em escala no Unity nunca foi tão fácil!

Colocando diretórios de conteúdo à prova: Slime Rancher 2

Nos últimos meses, alguns dos nossos parceiros foram gentis o suficiente para nos permitir testar diretórios de conteúdo com os seus jogos.

Como exemplo, vamos dar uma olhada no excelente jogo Slime Rancher 2 da Monomi Park e em alguns dos benefícios que ele recebe ao mudar para diretórios de conteúdo. (Slime Rancher está disponível no Steam! Slime Rancher, Slime Rancher 2)

Tempo de compilação incremental

Addressáveis (backend do AssetBundle)

32 minutos, 16 segundos