Melhorando o Desempenho

Esta página descreve problemas de desempenho comuns e melhores práticas para mitigá-los.

Calculo de Script

Operações caras em código Lua levarão mais tempo para processar e, portanto, podem afetar a avaliarde quadros. A menos que seja executado em paralelo, o código Lua é executado em sincronia e bloqueia o subprocesso principal até que ele encontre uma função que gere o Subprocesso.

Problemas Comuns

• Operações intensivas em estruturas de tabela - Operações complexas, como serialização, des serialização e clonagem profunda, incursem um alto custo de desempenho, especialmente em estruturas de tabela grandes. Isso é particularmente verdadeiro se essas operações forem recursivas ou envolver iteração sobre estruturas de dados muito grandes.

• Eventos de alta frequência - Vincular operações caras a eventos baseados em quadro de RunService sem limitar a frequência que essas operações são repetidas em cada quadro, o que geralmente resulta em um aumento desnecessário do tempo de execução. Esses eventos incluem:

  • RunService.PreAnimation
  • RunService.PreRender
  • RunService.PreSimulation
  • RunService.PostSimulation
  • RunService.Heartbeat

Mitigação

• Invoca código em RunService eventos, geralmente, limitando o uso a casos em que a invocação de alta frequência é essencial (por exemplo, atualizando a Câmera). Você pode executar a maioria do outro código em outros eventos ou com menos frequência em um loop.
• Quebre tarefas grandes ou caras usando task.wait() para espalhar o trabalho por vários quadros.
• Identifique e otimize operações desnecessariamente caras e use multithreading para tarefas de cálculo que não precisam acessar o modelo de dados.
• Alguns scripts do lado do servidor podem se beneficiar de Geração de Código Nativo, um simples cabeçalho que compila um script em código de máquina, em vez de código de bytes.

MicroProfiler Óculos

Para mais informações sobre a depuração de scripts usando o MicroProfiler, veja a biblioteca debug, que inclui funções para rastrear código específico e aumentar a especificidade, como debug.profilebegin e debug.profileend. Muitos métodos da API do Roblox chamados por scripts também têm suas próprias etiquetas de MicroProfiler que podem for

Uso de Memória do Script

Fugas de memória podem ocorrer quando você escreve scripts que consomem memória que o coletor de lixo não pode liberar corretamente quando não está mais em uso. Fugas são especificamente pervasivas no servidor, pois elas podem estar online continuamente por muitos dias, enquanto uma sessão de cliente é muito mais curta.

Os seguintes valores de memória na Console de Desenvolvedor podem indicar um problema que precisa de investigação adicional:

• LuaHeap - Alto ou crescente consumo sugere uma fuga de memória.
• InstânciaCount - Crescer números consistentes de instâncias sugerem que referências em alguns instantes em seu código não estão sendo coletadas.
• PlaceScriptMemory - Fornece um script por dano de script na memória.

Problemas Comuns

• Saindo de conexões conectadas - O motor nunca coleta eventos conectados a uma instância e quaisquer valores referenciados dentro do retorno de chamada conectado. Portanto, conexões ativas de eventos e código dentro das instâncias conectadas, funções conectadas e valores referenciados, estão fora do alcance do coletor de memória, mesmo depois que os eventos são executados.

  Embora os eventos sejam desconectados quando a instância a que eles pertencem for destruída, um erro comum é assumir que isso se aplica a objetos Player . Depois que um usuário sai de uma experiência, o motor não destró

• Tabelas - Inserir objetos em tabelas, mas não remover quando eles não são mais necessários causa o consumo de memória desnecessário, especialmente para tabelas que rastreiam dados do usuário quando eles se juntam. Por exemplo, o seguinte código de exemplo cria uma tabela adicionando informações do usuário a cada vez que um usuário se juntar:

  Exemplo
  local playerInfo = {}
  Players.PlayerAdded:Connect(function(player)
      playerInfo[player] = {} -- alguma informação
  end)

  Se você não remover essas entradas quando elas não são mais necessárias, a tabela ainda cresce em tamanho e consome mais memória à medida que mais usuários se juntam à sessão. Qualquer código que itera sobre esta tabela também se torna mais caro computacionalmente à medida que a tabela cresce em tamanho.

Mitigação

Para limpar todos os valores usados para prevenir vazamentos de memória:

• Desconecte todas as conexões - Vá através de sua base de código para garantir que cada conexão seja limpa via um dos seguintes caminhos:

  • Desconectando manualmente usando a função Disconnect().
  • Destruindo a instância ao qual o evento pertence com a função Destroy().
  • Destruindo o objeto de script que a conexão rastreia de volta.

• Remova objetos e personagens do jogador após sair - Implmente o código para garantir que nenhuma conexão persista após um usuário sair, como no seguinte exemplo:

  Exemplo
  Players.PlayerAdded:Connect(function(player)
    player.CharacterRemoving:Connect(function(character)
      task.defer(character.Destroy, character)
    end)
  end)
  
  Players.PlayerRemoving:Connect(function(player)
      task.defer(player.Destroy, player)
  end)

Cálculo de Física

Simulação de física excessiva pode ser uma causa chave do aumento do tempo de execução por quadro, tanto no servidor quanto no cliente.

Problemas Comuns

• Frequência de passagem de tempo de física excessiva - Por padrão, a frequência de passagem de comportamento é em modo adaptativo, onde as etapas de física ocorrem em 60 Hz, 120 Hz ou 240 Hz, dependendo da complexidade do mecanismo de física.

  Um modo fixo com precisão aprimorada da física também está disponível, o que força todas as montagens de física a passar por 240 Hz (quatro vezes por quadro). Como resultado, isso resulta em um cálculo significativamente mais eficiente por quadro.

• Número excessivo de complexidade de objetos simulados - Quanto mais conjuntos 3D forem simulados, maior será a duração das cálculos de física em cada quadro. Muitas vezes, experiências terão objetos sendo simulados que não precisam ser ou terão mecanismos que têm mais restrições e juntas do que eles precisam.

• Detecção de colisão precisa demais - As peças de malha têm uma propriedade CollisionFidelity para detectar colisões que oferece uma variedade de modos com diferentes níveis de desempenho. Modo de detecção de colisão precisa para peças de malha tem o maior custo de desempenho e leva mais tempo para o motor para calcular.

Mitigação

• Ancorar peças que não requerem simulação - Ancorar todas as peças que não precisam ser conduzidas pela física, como para NPCs estáticos.

• Use adaptive physics stepping - Adaptive stepping dinamicamente ajusta a taxa de cálculos de física para mecanismos de física, permitindo que as atualizações de física sejam feitas com menos frequência em alguns casos.

• Reduza a complexidade do mecanismo * Onde possível, minimize o número de restrições ou juntas de física em uma montagem.

  • Reduza a quantidade de colisão de autocolisão dentro de um mecanismo, como aplicando limites ou restrições de colisão a limpos de ragdoll para impedi-los de colidir uns com os outros.

• Reduza a utilização de precisão de colisão precisa para malhas * Para pequenos ou não interativos objetos onde os usuários raramente notariam a diferença, use a fidelidade da caixa.

  • Para pequenos objetos de tamanho médio, use a fidelidade da caixa ou do casco, dependendo da forma.

  • Para objetos grandes e muito complexos, construa colisões personalizadas usando partes invisíveis quando possível.

  • Para objetos que não exigem colisões, desabilite colisões e use a fidelidade da caixa ou do casco, pois a geometria de colisão ainda é armazenada na memória.

  • Você pode renderizar geometria de colisão para fins de diagnóstico no Studio ativando fidelidade de colisão no widget Opções de Visualização no canto superior direito da janela de visualização 3D.

    Alternativamente, você pode aplicar o filtro CollisionFidelity = Precise ao Explorer, que mostra um contador de todas as peças de malha com a fidelidade precisa e permite que você selecione facilmente.

  • Para uma abordagem de caminhada em profundidade sobre como escolher uma opção de fidelidade de colisão que equilibrar seus requisitos de precisão e desempenho, veja Definir parâmetros de física e renderização.

MicroProfiler Óculos

Uso de Memória Física

O movimento e a detecção de colisão gastam memória. As peças de malha têm uma propriedade CollisionFidelity que determina a abordagem usada para avaliar os limites de colisão do malha.

Problema Comum

Os modos de colisão padrão e precisos consumem significativamente mais memória do que os dois outros modos com formas de colisão de baixa fidelidade.

Se você ver altos níveis de consumo de memória sob PhysicsParts , você pode precisar explorar reduzir a fidelidade de colisão de objetos em sua experiência.

Como Mitigar

Para reduzir a memória usada para a fidelidade da colisão:

• Para peças que não precisam de colisões, desative suas colisões ao configurar BasePart.CanCollide, BasePart.CanTouch e BasePart.CanQuery para 1> false1> .
• Reduza a fidelidade das colisões usando a configuração CollisionFidelity. Box tem o menor sobreposição de memória e Default e 1> Enum.CollisionFidelity.Precise|

  • É geralmente seguro definir a fidelidade de colisão de qualquer peça ancorada pequena para Box.
  • Para malhas grandes muito complexas, você pode querer construir sua própria malha de colisão com menores objetos com fidelidade de colisão de caixa.

Humanóides

Humanoid é uma classe que fornece uma ampla gama de funcionalidades para personagens jogador e não jogador (NPCs). Embora seja poderosa, um Humanoid vem com um custo de cálculo significativo.

Problemas Comuns

• Saindo todos os tipos de estado humano ativados em NPCs - Existe um custo de desempenho para deixar certos HumanoidStateTypes ativados. Desabilite qualquer que não seja necessário para seus NPCs. Por exemplo, a menos que seu NPC esteja indo para escalar escadas, é seguro desativar o estado Climbing.
• Instantiando, modificando e respawnando modelos com Humanoids frequentemente * Isso pode ser intenso para o motor processar, especialmente se esses modelos usarem Roupas em camadas . Isso também pode ser problemático em experiências onde os avatares respawnam com frequência.

  • No MicroProfiler , longas etiquetas de updateInvalidatedFastClusters (sobre 4 ms) geralmente são um sinal de que a instalação/modificação de avatar está desencadeando exageradas inválidações.
• Usando Humanoids em casos onde eles não são necessários - NPCs estáticos que não se movem geralmente não têm necessidade da classe Humanoid.
• Jogar animações em um grande número de NPCs do servidor - Animações de NPCs que são executadas no servidor precisam ser simuladas no servidor e replicadas para o cliente. Isso pode ser desnecessário.

Mitigação

• Jogue animações de NPC no cliente - Em experiências com um grande número de NPCs, considere criar o Animator no cliente e executar as animações localmente. Isso reduz o trabalho no servidor e a necessidade de replicação desnecessária. Também torna possíveis otimizações adicionais (como apenas jogar animações para NPCs que estão perto do personagem).
• Use alternativas amigáveis de desempenho aos Humanóides - Modelos NPC não necessariamente precisam conter um Objetohumanoide.

  • Para NPCs estáticos, use um simples AnimationController, porque eles não precisam se mover, mas só precisam jogar animações.
  • Para mover NPCs, considere implementar seu próprio controle de movimento e usar um AnimationController para animações, dependendo da complexidade de seus NPCs.
• Desabilitar estados não utilizados de humanóide - Use Humanoid:SetStateEnabled() para ativar apenas estados necessários para cada humanóide.
• Modelos de NPC da piscina com ressurgimento frequente - Em vez de destruir um NPC completamente, envie o NPC para uma piscina de NPCs inativos. Desta forma, quando um novo NPC for necessário para ressurgir, você pode simplesmente reativar um dos NPCs da piscina. Este processo é chamado de pooling, que minimiza a quantidade de vezes que os personagens precisam ser instantiados.
• Apenas faça NPCs quando os usuários estão perto deles - Não faça NPCs quando os usuários não estão em alcance, e crie-os quando os usuários saírem de alcance.
• Evite fazer alterações na hierarquia do avatar depois de ser instantiado. - Algumas modificações na hierarquia do avatar têm implicações de desempenho significativas. Algumas otimizações estão disponíveis:

  • Para animações procedurais personalizadas, não atualize as propriedades JointInstance.C0 e JointInstance.C1. Em vez disso, atualize a propriedade Motor6D.Transform.
  • Se você precisar anexar quaisquer objetos BasePart a qualquer objeto de avatar, faça isso fora da hierarquia do avatar Model.

MicroProfiler Óculos

Renderizando

Uma porção significativa do tempo que o cliente gasta em cada quadro é na renderização da cena na janela atual. O servidor não faz nenhuma renderização, então esta seção é exclusiva para o cliente.

Desenhar Chamadas

Um chamado de desenho é um conjunto de instruções do motor para oGPU para renderizar algo. Chamadas de desenho têm grande sobreposição. Normalmente, quanto menor o número de chamadas de desenho por quadro, menos tempo de cálculo é gasto renderizando um quadro.

Você pode ver quantas chamadas de renderização estão ocorrendo com o item renderização de estatísticas > tempo de execução no Studio. Você pode ver o renderização de estatísticas no cliente pressionando 1> Shift1> 3> F2 3>.

Quanto mais objetos precisam ser desenhos em sua cena em um determinado quadro, o mais chamadas de desenho são feitas ao GPS. No entanto, o motor Roblox utiliza um processo chamado instanciar para colapsar meshes idênticos com as mesmas propriedades de textura em um único chamada de desenho. Especificamente, vários meshes com as mesmas propriedades de 2>MeshId2> são processados em um único

• SurfaceAppearances são idênticas. TextureIDs são idênticas quando Class.Surface não existe.
• Os materiais são idênticos quando ambos SurfaceAppearance e MeshPart.TextureID não existem.

Outros Problemas Comuns

• Densidade de objetos excessiva - Se um grande número de objetos estiver concentrado com uma alta densidade, então renderizar esta área da cena requer mais chamadas de renderização. Se você estiver encontrando sua taxa de quadros caindo quando você olha para uma certa parte do mapa, isso pode ser um bom sinal de que a densidade de objetos nesta área é muito alta.

  Objetos como decalques, texturas e partículas não são bem sincronizados e introduzem chamadas de desenho adicionais. Preste atenção extra a esses tipos de objetos em uma cena. Em particular, as alterações de propriedade para ParticleEmitters podem ter um impacto dramático no performance.

• Falhas ao instituir oportunidades de instalação perdidas - Muitas vezes, uma cena incluirá a mesma malha duplicada várias vezes, mas cada cópia da malha tem diferentes IDs de malha ou textura. Isso impede o insticionamento e pode levar a chamadas de desenho desnecessárias.

  Uma causa comum desse problema é quando um conjunto inteiro de cenas é importado de uma vez, em vez de recursos individuais sendo importados no Roblox e depois duplicados para montar a cena.

• Complicação de objetos excessiva - Embora não seja tão importante quanto o número de chamadas de desenho, o número de triângulos em uma cena influencia o tempo que leva para renderizar. Cenas com um número muito grande de meshes complexos são um problema comum, assim como cenas com o conjunto de propriedade MeshPart.RenderFidelity definido para Enum.RenderFidelity.P

• Excessivo sombreamento de sombra - Manipular sombras é um processo caro, e mapas que contêm um grande número e densidade de objetos de luz que sombream (ou um grande número e densidade de pequenas peças afetadas por sombras) geralmente têm problemas de desempenho.

• Alta transparência sobreposição - Colocar objetos com transparência parcial perto um do outro força o motor a renderizar os pixels sobreposição múltiplas vezes, o que pode causar performance. Para mais informações sobre identificar e corrigir este problema, see Excluir camadas de transparência sobreposição múltiplas vezes, .

Mitigação

• Instancia meshes idênticos e reduzir a quantidade de meshes únicos - Se você garantir que todos os meshes idênticos têm os mesmos IDs de recursos subjacentes, o motor pode reconhecê-los e renderizá-los em um único chamado de desenho. Certifique-se de carregar cada meshes em um mapa apenas uma vez e depois du
• Culling - Culling descreve o processo de eliminação de chamadas de desenho para objetos que não são fatores no quadro de renderização final. Por padrão, o motor pula chamadas de desenho para objetos fora do campo de visão (frustum culling), mas não pula chamadas de desenho para objetos ocultos da visão por outros objetos (oculation cull

  • Ocultar MeshPart e BasePart que estão muito longe da câmera ou configuração.
  • Para ambientes internos, implemente um sistema de sala ou portal que oculta objetos não atualmente ocupados por nenhum usuário.
• Reduzindo a fidelidade de renderização - Definir a fidelidade de renderização para Automático ou Performance . Isso permite que os malhas retornem a alternativas menos complexas, o que pode reduzir o número de polígonos que precisam ser desenhos.
• Desabilitando a sombreamento em partes e objetos de luz apropriados - A complexidade das sombras em uma cena pode ser reduzida selecionando desativar sombreamento de propriedades em objetos de luz e partes. Isso pode ser feito no tempo de edição ou dinamicamente em tempo de execução. Alguns exemplos são:

  • Use a propriedade BasePart.CastShadow para desativar o sombreamento em pequenas peças onde sombras não são visíveis. Isso pode ser particularmente efetivo quando aplicado apenas a peças que estão muito longe da Câmerado usuário.

    Isso pode resultar em artefatos visuais em sombras.

  • Desabilitar sombras em objetos em movimento quando possível.

  • Desabilitar Light.Shadows em instâncias de luz onde o objeto não precisa castizar sombras.

  • Limite o alcance e o ângulo de instâncias de luz.

  • Use menos instâncias de luz.

MicroProfiler Óculos

Redes e Replicação

A rede e a replicação descrevem o processo pelo qual os dados são enviados entre o servidor e os clientes conectados. A informação é enviada entre o cliente e o servidor a cada quadro, mas quantidades maiores de informações exigem mais tempo de execução.

Problemas Comuns

• Tráfego remoto excessivo - Enviar uma grande quantidade de dados através de objetos RemoteEvent ou RemoteFunction ou invocá-los com muita frequência pode levar a uma grande quantidade de tempo de CPU gastos processando pacotes entrantes a cada quadro. Erros comuns incluem:

  • Replicando dados a cada quadro que não precisa ser replicado.
  • Replicando dados na entrada do usuário sem nenhum mecanismo para limitá-lo.
  • Despachando mais dados do que é necessário. Por exemplo, enviar todo o inventário do jogador quando eles comprarem um item, em vez de apenas detalhes do item comprado.

• Criação ou remoção de árvores de instância complexas - Quando uma alteração é feita no modelo de dados no servidor, ela é replicada para clientes conectados. Isso significa criar e destruir grandes hierarquias de instância, como mapas em tempo de execução, pode ser muito intenso de rede.

  Um culpado comum aqui é o complexo dado de animação salvo pelos plugins do Editor de Animação em racks. Se esses não forem removidos antes que o jogo seja publicado e o modelo animado seja clonado regularmente, uma grande quantidade de dados será replicada sem necessidade.

• Serviço de Tweet do Lado do Servidor - Se TweenService é usado para tweenar um servidor de propriedade, o tweened property é replicado para cada cliente a cada quadro. Não só isso resulta no tween sendo jittery como os clientes' latência floqueia, mas causa muito tráfego de rede desnecessário.

Mitigação

Você pode usar as seguintes táticas para reduzir a replicação não necessária:

• Evite enviar grandes quantidades de dados de uma vez através de eventos remotos. Em vez disso, apenas envie os dados necessários em uma frequência mais baixa. Por exemplo, para o estado de um personagem, replica-o quando ele muda em vez de todos os quadros.
• Chunk up complexos árvores de instância como mapas e load them in pieces to distribute the work replicating these across multiple frameworks.
• Limpar metadados de animação , especialmente a diretoria de animação de modelos, após a importação.
• Limite a replicação de instância não necessária , especialmente em casos em que o servidor não precisa ter conhecimento das instâncias sendo criadas. Isso inclui:

  • Efeitos visuais, como uma explosão ou um feitiço mágico. O servidor só precisa saber a localização para determinar o resultado, enquanto os clientes podem criar visuais localmente.
  • Modelos de visão de item em primeira pessoa.
  • Mova objetos no cliente, não no servidor.

MicroProfiler Óculos

Uso de Memória de Recursos

O mecanismo de maior impacto disponível para os criadores para melhorar o uso de memória do cliente é ativar Instância Streaming.

streaming de instância

O streaming de instância carrega selecionadamente partes do modelo de dados que não são necessárias, o que pode levar a um tempo de carregamento significativamente reduzido e aumentar a capacidade do cliente para evitar quedros quando estiver sob pressão de memória.

Se você estiver enfrentando problemas de memória e tiver a transmissão de instância desativada, considere atualizar sua experiência para suportá-la, especialmente se seu mundo 3D for grande. A transmissão de instância é baseada em distância no espaço 3D, então mundos maiores naturalmente se beneficiam mais.

Se a streaming de instância é habilitada, você pode aumentar a agressividade dela. Por exemplo, considere:

• Reduzindo o uso do persistente StreamingIntegrity .
• Reduzindo o raio de streaming .

Para mais informações sobre as opções de streaming e seus benefícios, veja Propriedades de Streaming.

Outros Problemas Comuns

• Duplicação de recursos - Um erro comum é carregar o mesmo recurso várias vezes, resultando em diferentes IDs de recursos. Isso pode levar ao mesmo conteúdo sendo carregado para a memória várias vezes.
• Volume de recursos excessivo - Mesmo que os recursos não sejam idênticos, há casos em que as oportunidades de reutilizar o mesmo recurso e salvar memória são perdidas.
• Arquivos de áudio - Arquivos de áudio podem ser um contribuição surpreendente para o uso de memória, particularmente se você carregar todos eles no cliente de uma vez em vez de apenas carregar o que você precisa para uma parte da experiência. Para estratégias, see Tempos de carregamento .
• Texturas de alta resolução - A memória de gráficos é consumida por um textura, não relacionada com o tamanho da textura no disco, mas sim com o número de pixels na textura.

  • Por exemplo, um tecido de 1024x1024 pixels consome quatro vezes a memória gráfica de uma textura de 512x512.
  • As imagens carregadas no Roblox são transcodificadas para um formato fixo, então não há vantagem de memória em carregar imagens em um modelo de cor associado a menos bytes por pixel. Da mesma forma, compactar imagens antes de carregar ou remover o canal alfa das imagens que não o necessitam pode diminuir o tamanho das imagens no disco, mas não melhora ou apenas melhora um pouco a otimização de memória.
  • Você pode identificar o consumo de memória de gráficos para uma textura dada expandindo a categoria Textura de Gráficos na Console de Desenvolvedor.

Mitigação

• Apenas carregar recursos uma vez - Reutilize o mesmo ID de recurso em objetos e garantir que os mesmos recursos, especialmente malhas e imagens, não sejam carregados separadamente várias vezes.
• Encontre e corrija itens duplicados. - Procure por peças de malha idênticas e texturas que sejam carregadas várias vezes com IDs diferentes.

  • Embora não haja API para detectar a semelhança de recursos automaticamente, você pode coletar todos os IDs de recursos na sua posição (seja manualmente ou com um script), baixá-los e compará-los usando ferramentas de comparação externas.
  • Para peças de malha, a melhor estratégia é usar IDs de malha exclusivos e organizá-los por tamanho para identificar manualmente duplicados.
  • Em vez de usar texturas separadas para diferentes cores, faça o upload de uma única textura e use a propriedade SurfaceAppearance.Color para aplicar vários tons a ele.
• Importando recursos no mapa separadamente - Em vez de importar um mapa inteiro de uma vez, importe e reconstrua recursos no mapa individualmente e reconstrua-os. O importador 3D não faz nenhum de duplicação de malhas, então se você importar um grande mapa com muitos separados pequenos ladrilhos, cada um deles será importado como um recurso
• Limite o número de pixels das imagens para não mais do que a quantidade necessária. A menos que uma imagem esteja ocupando uma grande quantidade de espaço físico na tela, geralmente precisa de no máximo 512x512 pixels. A maioria das imagens menores deve ser menor que 256x256 pixels.
• Use Sheets de Trim para garantir a reutilização máxima de textura em mapas 3D. Para etapas e exemplos sobre como criar Sheets de Trim, veja Criando Sheets de Trim.

Tempos de Carregamento

Muitas experiências implementam telas de carregamento personalizadas e usam o método ContentProvider:PreloadAsync() para solicitar recursos para que imagens, sons e malhas sejam baixados no fundo.

A vantagem desta abordagem é que ela permite que você garanta que as partes importantes de sua experiência sejam carregadas completamente sem pop-in. No entanto, um erro comum é usar demais este método para pré-carregar mais recursos do que são realmente necessários.

Um exemplo de uma má prática é carregar o todo o mundoWorkspace. Embora isso possa impedir o pop-in de texto, ele significativamente aumenta o tempo de carregamento.

Em vez disso, use apenas ContentProvider:PreloadAsync() em situações necessárias, que incluem:

• Imagens na tela de carregamento.
• Importe imagens no seu menu de experiência, como fundos de botão e ícones.
• Recursos importantes na área de início ou spawn.

Se você precisar carregar um grande número de recursos, recomendamos que você forneça um botão Pular Carregamento .