Unity Addressables: como projetar tempos de vida explícitos de carregamento e liberação

Um carregamento cria uma responsabilidade

Uma requisição de asset pode durar mais do que a tela que a fez. Um retrato pode terminar de carregar depois que o painel do personagem já foi fechado, ou uma pré-visualização pode ser substituída antes de a textura chegar. Projete esse tempo de vida antes de adicionar um indicador de carregamento. Defina quem é o responsável (owner), quem são os consumidores e qual evento exato encerra a posse. As referências aqui usam a documentação do Addressables 2.7.

Separe conclusão de posse

LoadAssetAsync retorna um handle de operação. Mantenha esse handle enquanto usar o resultado e depois libere-o; a liberação invalida o handle. Operações que falham também exigem a limpeza do handle. [1] A conclusão responde se um resultado está pronto. A posse responde quem precisa mantê-lo vivo. Modele essas duas questões como decisões separadas na sua aplicação.

Conte obrigações, não variáveis

O Addressables usa contagem de referências. Equilibre os carregamentos explícitos com liberações; um asset que chega a zero referências não necessariamente libera a memória de imediato, porque o tempo de vida dos bundles também importa. [2] Um wrapper prático pode registrar uma obrigação de liberação por requisição, com estados como pendente, utilizável, obsoleta e liberada. Torne a limpeza idempotente dentro desse wrapper, para que o fechamento do painel e a conclusão do carregamento não liberem a mesma obrigação duas vezes. Uma variável copiada nunca deve ser o seu registro de posse.

Exemplo: um carrossel de seleção de personagem

Suponha que selecionar o piloto A inicie a requisição de retrato 21. Antes de ela terminar, o jogador seleciona o piloto B, o que cria a requisição 22. Mantenha a requisição 21 rastreada, mas marque o resultado dela como obsoleto. Quando a 21 terminar, examine o resultado, evite atribuir o retrato dela e execute o seu único caminho de limpeza. Quando a 22 terminar com sucesso, exiba o retrato dela e mantenha a posse até o painel substituí-lo ou ser fechado. Um identificador de requisição impede que um callback antigo sobrescreva a nova seleção. Fechar o painel deve invalidar imediatamente o acesso para apresentação, enquanto a requisição pendente continua rastreada até que a limpeza possa ser concluída. Essa política descreve o comportamento da aplicação; ela não pressupõe que ocultar um painel cancele um download.

Limites e evidências úteis

Assets Addressable carregados separadamente não são liberados automaticamente só porque uma cena foi descarregada. [3] Inclua as transições de cena no mesmo plano de posse. Teste carregamentos que falham, mudanças rápidas de seleção, ciclos repetidos de abrir e fechar e um fechamento que ocorre logo antes da conclusão. Registre identificadores de requisição, transições de posse e contagens de liberação. Depois de vários ciclos, compare os assets e bundles retidos, em vez de esperar que a memória do processo caia a cada liberação. Mantenha um cache compartilhado intencional apenas se ele tiver uma política de remoção definida e um orçamento de memória.

Fontes

1. Addressables 2.7: asynchronous operation handles — Unity Technologies.
2. Managing Addressable asset memory — Unity Technologies.
3. Unload Addressable assets — Unity Technologies.