Pegue essas dicas úteis sobre perfilagem avançada

Em junho, realizamos um webinar com especialistas da Arm, da equipe Unity Studio Productions e da SYBO Games, criadora de Subway Surfers. A mesa redonda resultante focou em dicas e estratégias de perfil para jogos móveis, as implicações comerciais de um desempenho ruim e como a SYBO lançou um jogo móvel de sucesso com 3 bilhões de downloads até agora.

Vamos mergulhar em algumas das perguntas de acompanhamento que não tivemos tempo de cobrir durante o webinar. Você também pode assistir à gravação completa.

Ouvimos muito sobre o Profiler do Unity em relação ao perfil de CPU, mas não tanto sobre o Profile Analyzer (disponível como um pacote do Unity). Há planos para melhorá-lo ou integrá-lo ao conjunto de ferramentas do Profiler principal?

Não há planos imediatos para integrar o Profile Analyzer ao Editor principal, mas isso pode mudar à medida que nossas ferramentas de perfil evoluem.

O Unity tem planos de adicionar uma opção para o módulo de Profiler de Uso de GPU aparecer em porcentagens como faz em milissegundos?

Essa é uma ótima ideia, e embora não possamos dizer sim ou não no momento deste post no blog, é um pedido que foi compartilhado com nossas equipes de P&D para possível consideração futura.

Você tem planos para lidar com erros de “Aplicativo Não Respondendo” (ANR) que são relatados pela loja Google Play e não contêm nenhum rastreamento de pilha?

Embora não tenhamos planos específicos para rastrear ANR sem rastreamento de pilha no momento, consideraremos isso para o roteiro futuro.

Como posso compartilhar meu feedback para ajudar a influenciar o desenvolvimento futuro das ferramentas de perfil do Unity?

Você pode acompanhar os recursos futuros e compartilhar feedback através do nosso quadro de produtos e fóruns. Estamos também realizando uma pesquisa para saber mais sobre a experiência de nossos clientes com as ferramentas de perfil. Se você já usou ferramentas de perfil antes (diariamente ou apenas uma vez) ou está trabalhando em um projeto que requer otimização, adoraríamos receber sua opinião. A pesquisa foi projetada para levar no máximo 5 a 10 minutos para ser concluída.

Ao participar, você também terá a chance de optar por uma entrevista de acompanhamento para compartilhar mais feedback diretamente com a equipe de desenvolvimento, incluindo a oportunidade de discutir protótipos potenciais de novos recursos.

Existe uma boa regra para determinar o que conta como um dispositivo de baixo custo viável para se direcionar?

Uma regra prática que ouvimos de muitos desenvolvedores de jogos Unity é direcionar dispositivos que têm cinco anos na época do lançamento do seu jogo, pois isso ajuda a garantir a maior base de usuários. Mas também vemos equipes reduzindo seu escopo de data de lançamento para dispositivos que têm apenas três anos se estiverem visando uma qualidade gráfica mais alta. Uma aplicação 3D visualmente complexa, por exemplo, terá requisitos de dispositivo mais altos do que uma aplicação 2D simples. Essa abordagem permite um "mínimo especificado" mais alto, mas reduz o tamanho da base de instalação inicial. É essencialmente uma decisão de negócios: Custará mais desenvolver e dar suporte a dispositivos antigos do que o que seu jogo ganhará rodando neles?

Às vezes, os requisitos técnicos do seu jogo ditarão suas especificações mínimas de alvo. Então, se seu jogo usar grandes quantidades de memória de textura mesmo após a otimização, mas você absolutamente não pode reduzir a qualidade ou a resolução, isso provavelmente elimina a possibilidade de rodar em telefones com memória insuficiente. Se sua solução de renderização exigir shaders de computação, isso provavelmente elimina dispositivos com drivers que não suportam OpenGL ES 3.1, Metal ou Vulkan.

É uma boa ideia olhar para dados de mercado do seu público-alvo prioritário. Por exemplo, as especificações de dispositivos móveis podem variar muito entre países e regiões. Lembre-se de definir alguns "orçamentos" de alvo para que as metas de benchmarking do que é aceitável sejam definidas antes de escolher dispositivos de baixo custo para testes.

Para jogos de serviço ao vivo que rodarão por anos, você precisará monitorar sua compatibilidade continuamente e se adaptar ao longo do tempo com base tanto na sua base de usuários real quanto nos dispositivos atuais no mercado.

É suficiente testar o desempenho exclusivamente em dispositivos de baixo custo para garantir que o jogo também funcione suavemente em dispositivos de alto custo?

Pode ser, se você tiver uma carga de trabalho uniforme em todos os dispositivos. No entanto, você ainda precisa considerar variações entre hardware de diferentes fornecedores e/ou versões de drivers.

É comum que jogos graficamente ricos tenham níveis de fidelidade gráfica – quanto maior o nível visual, mais recursos são necessários em dispositivos capazes. Essa seleção de nível pode ser automática, mas cada vez mais, os próprios usuários podem controlar a escolha através de um menu de configurações gráficas. Para este estilo de desenvolvimento, você precisará testar pelo menos um dispositivo alvo "mínimo" por recurso/nível de carga de trabalho que seu jogo suporta.

Se o seu jogo detectar as capacidades do dispositivo em que está sendo executado e adaptar a saída gráfica conforme necessário, ele pode ter um desempenho diferente em dispositivos de maior desempenho. Portanto, certifique-se de testar em uma variedade de dispositivos com os diferentes níveis de qualidade para os quais você programou o título.

Observação: Nesta seção, especificamos se o especialista que responde é da Arm ou da Unity.

Você tem conselhos para detectar a faixa de potência de um dispositivo para suportar configurações de qualidade automáticas, particularmente para dispositivos móveis?

Arm: Normalmente, vemos desenvolvedores fazendo agrupamento grosseiro de capacidades com base em modelos de CPU e GPU, bem como na contagem de núcleos de sombreador da GPU. Isso nunca é perfeito, mas está "mais ou menos certo." Muitos estúdios coletam análises ao vivo de dispositivos implantados, para que possam complementar o agrupamento automatizado com opções específicas do dispositivo para contornar problemas pontuais onde o agrupamento de capacidades não é preciso o suficiente.

Em relação à pergunta anterior, para conteúdo graficamente rico, vemos uma tendência em dispositivos móveis em direção a menus de configurações onde os usuários podem escolher ativar ou desativar efeitos, permitindo assim que façam escolhas de desempenho que atendam às suas preferências.

Unity: A memória do dispositivo e a resolução da tela também são fatores importantes para escolher configurações de qualidade. Quanto às texturas, os desenvolvedores devem estar cientes de que Texturas de Renderização usadas por efeitos ou pós-processamento podem se tornar um problema em dispositivos com telas de alta resolução, mas sem muita memória para corresponder.

Dada a variedade de configurações disponíveis (CPU, GPU, SOC, memória, móvel, desktop, console, etc.), você pode sugerir uma maneira de categorizar dispositivos para reduzir o número de níveis que você precisa otimizar?

Arm: O número de níveis que sua equipe otimiza é realmente uma decisão de design de jogo e de negócios, e deve ser baseado em quão importante é empurrar a qualidade visual para a proposta de valor do jogo. Para alguns gêneros, isso pode não importar, mas para outros, os usuários terão altas expectativas em relação à fidelidade visual.

O limite de memória de textura difere entre modelos e marcas de dispositivos Android que têm a mesma quantidade de memória total do sistema?

Arm: Para uma aproximação de primeira ordem, esperaríamos que a quantidade total de memória de textura fosse semelhante entre fornecedores e gerações de hardware. Haverá pequenas diferenças causadas pelo layout de memória e restrições de alinhamento, então não será exatamente o mesmo.

É o uso da CPU ou da GPU que contribui mais para o superaquecimento em dispositivos móveis?

Arm: Depende totalmente do conteúdo. A CPU, GPU ou DRAM podem individualmente superaquecê-lo se forem exigidas ao máximo, mesmo que você ignore completamente os outros dois. O equilíbrio exato variará com base na carga de trabalho que você está executando.

Que dicas você pode dar para perfilagem em dispositivos que têm limitação térmica? Qual margem você miraria para evitar a limitação térmica (ou seja, visando 20 ms em vez de 33 ms)?

Arm: Otimizar o tempo de quadro pode ser enganoso no Android porque os dispositivos constantemente ajustam a frequência para otimizar o uso de energia, tornando o tempo de quadro uma medida incompleta por si só. Preferencialmente, monitore os ciclos da CPU e da GPU por quadro, bem como a largura de banda da memória da GPU por quadro, para obter um valor que seja independente da frequência. A meta de ciclos que você precisa dependerá do design do chip de cada dispositivo, então você precisará experimentar.

Qualquer otimização ajuda quando se trata de gerenciar o consumo de energia, mesmo que não melhore diretamente a taxa de quadros. Por exemplo, reduzir os ciclos da CPU reduzirá a carga térmica, mesmo que a CPU não seja o caminho crítico para o seu jogo.

Além disso, otimizar a largura de banda da memória é uma das maiores economias que você pode fazer. Acessar a DRAM é ordens de magnitude mais caro do que acessar dados locais no chip, então fique de olho no seu orçamento de triângulo e mantenha os tipos de dados na memória o menor possível.

Unity: Para limitar o impacto da frequência do clock da CPU nas métricas de desempenho, recomendamos tentar operar a uma temperatura consistente. Existem algumas abordagens para fazer isso:

• Executar quente: Execute o dispositivo por um tempo para que ele atinja um estado quente estável antes da perfilagem.
• Executar frio: Deixe o dispositivo esfriar por um tempo antes de fazer o perfil. Essa estratégia pode eliminar confusão e inconsistência nas sessões de perfil, capturando dados que provavelmente não serão limitados termicamente. No entanto, tais capturas sempre representarão o melhor desempenho que um usuário verá, em vez do que ele pode realmente ver após longas sessões de jogo. Essa estratégia também pode atrasar o tempo entre as execuções de perfil devido à necessidade de esperar primeiro pelo período de resfriamento.

Com alguns hardwares, você pode fixar a frequência do clock para métricas de desempenho mais estáveis. No entanto, isso não é representativo da maioria dos dispositivos que seus usuários estarão usando e não relatará um desempenho real preciso. Basicamente, é uma técnica útil se você estiver usando uma configuração de integração contínua para verificar mudanças de desempenho em seu código ao longo do tempo.

Alguma opinião sobre Vulkan vs OpenGL ES 3 no Android? Vulkan é geralmente mais lento em termos de desempenho. Ao mesmo tempo, muitos dispositivos não suportam vários recursos no ES3.

Arm: Drivers e versões de motor recentes melhoraram muito a qualidade das implementações do Vulkan disponíveis; portanto, para uma carga de trabalho equivalente, não deve haver uma diferença de desempenho entre OpenGL ES e Vulkan (se houver, por favor, nos avise). A transição para Vulkan está ganhando velocidade e esperamos ver mais pessoas escolhendo Vulkan por padrão nos próximos um ou dois anos. Se você tiver contraexemplos de áreas onde Vulkan não está se saindo bem, por favor, entre em contato conosco. Adoraríamos ouvir de você.

Quais ferramentas podemos usar para monitorar a largura de banda da memória (RAM <-> VRAM)?

Arm: O Streamline Profiler no Arm Mobile Studio pode medir a largura de banda entre GPUs Mali e a DRAM externa (ou cache do sistema).

Você deve dividir ativos gráficos por níveis de dispositivo ou resolução de dispositivo?

Arm: Você pode obter o melhor resultado ajustando os ativos, mas é caro fazer isso. Comece reduzindo a resolução e a taxa de quadros, ou desativando alguns efeitos de pós-processamento opcionais.

Qual é a melhor maneira de registrar estatísticas de métricas de desempenho da nossa versão de desenvolvimento?

Arm: Você pode usar a ferramenta Performance Advisor no Arm Mobile Studio para capturar e exportar automaticamente métricas de desempenho das GPUs Mali, embora isso venha com uma ressalva: A geração de relatórios JSON requer uma licença da Edição Profissional.

Unity: O Profiler do Unity pode ser usado para visualizar métricas comuns de renderização, como contagens de vértices e triângulos no Módulo de Renderização. Além disso, você pode incluir pacotes personalizados, como System Metrics Mali, em seu projeto para adicionar métricas de GPU Mali de baixo nível ao Profiler do Unity.

Quais são suas recomendações para perfilagem de código de shader?

Você precisa de um GPU Profiler para fazer isso. A escolha depende da sua plataforma alvo. Por exemplo, em dispositivos iOS, o GPU Profiler do Xcode inclui o Shader Profiler, que detalha o desempenho do shader linha por linha.

O Arm Mobile Studio suporta Mali Offline Compiler, uma ferramenta de análise estática para código de shader e núcleos de computação. Esta ferramenta fornece algumas estimativas gerais de desempenho e recomendações para a família de GPUs Arm Mali.

Ao fazer perfilagem, a regra geral é testar seu jogo ou aplicativo no(s) dispositivo(s) alvo(s). Com a indústria se movendo em direção a mais tipos de chipsets (Apple M1, Arm, x86 da Intel, AMD, etc.), como os desenvolvedores podem perfilar e identificar problemas nas muitas configurações de hardware diferentes em um tempo razoável?

A proliferação de chipsets é principalmente uma preocupação nas plataformas de desktop. Há um número limitado de arquiteturas de hardware para testar em jogos de console. Em dispositivos móveis, há a série A da Apple para dispositivos iOS e uma variedade de arquiteturas Arm e Qualcomm para Android – mas selecionar uma lista gerenciável de dispositivos móveis representativos é bastante simples.

No desktop é mais complicado porque há uma ampla gama de chipsets e arquiteturas disponíveis, e comprar Macs e PCs para testes pode ser caro. Nosso melhor conselho é fazer o que você puder. Nenhum estúdio tem tempo e dinheiro infinitos para testes. Geralmente, não esperaríamos grandes surpresas ao comparar o desempenho entre uma CPU Intel x86 e um processador AMD com especificações semelhantes, por exemplo. Desde que o jogo funcione confortavelmente em sua máquina com especificações mínimas, você deve estar razoavelmente confiante sobre outras máquinas. Também vale a pena considerar o uso de Unity Analytics para registrar taxas de quadros, especificações do sistema e configurações de opções dos jogadores para identificar pontos críticos ou configurações problemáticas.

Estamos vendo mais estúdios mudarem para usar pelo menos algum nível de testes automatizados para perfilagem regular em dispositivos, com estatísticas resumidas publicadas onde toda a equipe pode acompanhar o desempenho em uma variedade de dispositivos-alvo. Com cenas de teste bem projetadas, isso geralmente pode ser transformado em um processo mecânico adequado para automação, para que você não precise de um artista técnico experiente ou testador de QA executando builds manualmente pelo processo.

Você já viu problemas de desempenho em dispositivos de alta gama que não ocorrem em dispositivos de baixa gama?

É incomum, mas já vimos isso. Frequentemente, o problema está em como o projeto é configurado, como o uso de shaders sofisticados e texturas de alta resolução em dispositivos de alta gama, o que pode colocar pressão extra na GPU ou na memória. Às vezes, um dispositivo móvel de alta gama ou console usará uma tela de telefone de alta resolução ou saída de TV 4K como um ponto de venda, mas não necessariamente terá poder de GPU ou memória suficiente para cumprir essa promessa sem otimização adicional.

Se você usar as versões atuais do C# Job System, verifique se há uma sobrecarga de agendamento de trabalho que escala com o número de threads de trabalho, que por sua vez, escala com o número de núcleos de CPU. Isso pode resultar em código que roda mais lentamente em um Threadripper™ com 64+ núcleos do que em uma CPU modesta de 4 ou 8 núcleos. Esse problema será abordado em versões futuras do Unity, mas, enquanto isso, tente limitar o número de threads de trabalho definindo JobsUtility.JobWorkerCount.

Quais são algumas dicas para definir um bom orçamento de quadros?

Na maior parte do tempo, quando falamos sobre orçamentos de quadros, estamos falando sobre o orçamento total de tempo para o quadro. Você calcula 1000/quadros por segundo (fps) alvo para obter seu orçamento de quadros: 33,33 ms para 30 fps, 16,66 ms para 60 fps, 8,33 ms para 120 Hz, etc. Reduza esse número em cerca de 35% se você estiver em um dispositivo móvel para dar uma chance aos chips de esfriar entre cada quadro. Dividir o orçamento para obter sub-orçamentos específicos para diferentes recursos e/ou sistemas provavelmente é exagero, exceto para projetos com sistemas muito específicos e previsíveis, ou aqueles que fazem uso intenso de Time Slicing.

Geralmente, a perfilagem é o processo de encontrar os maiores gargalos – e, portanto, os maiores ganhos potenciais de desempenho. Então, em vez de dizer: "A física está levando 1,2 ms quando o orçamento permite apenas 1 ms", você pode olhar para um quadro e dizer: "A renderização está levando 6 ms, tornando-se o maior custo de CPU da thread principal no quadro." Como podemos reduzir isso?

Parece que fazer perfilamento cedo e frequentemente ainda não é um conhecimento comum. Quais são seus pensamentos sobre por que isso pode ser o caso?

Construir, lançar, promover e gerenciar um jogo é um trabalho difícil em múltiplas frentes. Portanto, sempre haverá inúmeras prioridades competindo pela atenção de um desenvolvedor, e o perfilamento pode ser deixado de lado. Eles sabem que é algo que deveriam fazer, mas talvez não estejam familiarizados com as ferramentas e não sintam que têm tempo para aprender. Ou, eles não sabem como encaixar o perfilamento em seus fluxos de trabalho porque estão pressionados a completar recursos em vez de otimização de desempenho.

Assim como com bugs e dívidas técnicas, problemas de desempenho são mais baratos e menos arriscados de resolver no início, em vez de mais tarde no ciclo de desenvolvimento de um projeto. Nosso foco é ajudar a desmistificar ferramentas e técnicas de perfilamento para aqueles desenvolvedores que não estão familiarizados com elas. É isso que o e-book de perfilamento e seus posts de blog e webinars relacionados visam apoiar.

Há uma maneira de excluir certos métodos da instrumentação ou incluir apenas métodos específicos ao usar o Perfilador Profundo no Unity Profiler? Ao usar muitas tarefas async/await, criamos grandes rastros de pilha, mas como podemos evitar desacelerar tanto o cliente quanto o Profiler ao fazer Perfilamento Profundo?

Você pode habilitar pilhas de chamadas de alocação para ver as pilhas de chamadas completas que levam a alocações gerenciadas (mostradas em magenta na visualização da linha do tempo do Unity CPU Profiler). Além disso, você pode – e deve! – instrumentar manualmente métodos e processos de longa duração espalhando ProfilerMarkers pelo seu código. Atualmente, não há como habilitar automaticamente o Perfilamento Profundo ou desabilitar o perfilamento completamente em partes específicas de sua aplicação. Mas adicionar manualmente ProfilerMarkers e habilitar pilhas de chamadas de alocação quando necessário pode ajudá-lo a investigar áreas problemáticas sem precisar recorrer ao Perfilamento Profundo.

A partir do Unity 2022.2, você também pode usar nosso IgnoredByDeepProfilerAttribute para impedir que o Unity Profiler capture chamadas de método. Basta adicionar o atributo IgnoredByDeepProfiler a classes, estruturas e métodos.

Onde posso encontrar mais informações sobre Deep Profiling no Unity?

Deep Profiling é abordado em nossa documentação do Profiler. Então, há o recurso mais completo e único para informações de profiling, o Guia Definitivo para profiling de jogos Unity e-book, que vincula à documentação relevante e outros recursos ao longo do caminho.

É correto que o Deep Profiling é útil apenas para o Allocations Profiler e que distorce tanto os resultados que não é útil para encontrar travamentos no jogo?

Deep Profiling pode ser usado para encontrar as causas específicas de alocações gerenciadas, embora pilhas de chamadas de alocação possam fazer a mesma coisa com menos sobrecarga, no geral. Ao mesmo tempo, o Deep Profiling pode ser útil para investigar rapidamente por que um ProfilerMarker específico parece estar demorando tanto, já que é mais conveniente habilitar do que adicionar numerosos ProfilerMarkers aos seus scripts e reconstruir seu jogo. Mas sim, ele distorce bastante o desempenho e, portanto, não deve ser habilitado para profiling geral.

Vale a pena definir VSync para cada VBlank? Meu jogo móvel roda a uma taxa de fps muito baixa quando está desativado.

Dispositivos móveis forçam o VSync a ser habilitado em um nível de driver/hardware, então desativá-lo nas configurações de Qualidade do Unity não deve fazer diferença nessas plataformas. Não ouvimos de nenhum caso em que desativar o VSync afete negativamente o desempenho. Tente fazer uma captura de perfil com o VSync habilitado, junto com outra captura da mesma cena, mas com o VSync desativado. Então, compare as capturas usando Profile Analyzer para tentar entender por que o desempenho é tão diferente.

Como você pode determinar se a thread principal está esperando pela GPU e não o contrário?

Isso é abordado no Guia Definitivo para profiling de jogos Unity. Você também pode obter mais informações no post do blog, Detectando gargalos de desempenho com o Unity Frame Timing Manager.

De modo geral, o sinal característico é que a thread principal espera pela thread de Renderização enquanto a thread de Renderização espera pela GPU. Os nomes dos marcadores específicos diferirão dependendo da sua plataforma alvo e da API gráfica, mas você deve ficar atento a marcadores com nomes como “PresentFrame” ou “WaitForPresent.”

Existe um processo sólido para encontrar vazamentos de memória em profiling?

Use o Memory Profiler para comparar instantâneas de memória e verificar vazamentos. Por exemplo, você pode tirar uma captura de tela no seu menu principal, entrar no seu jogo e depois sair, voltar ao menu principal e tirar uma segunda captura de tela. Comparar esses dois dirá se algum objeto/alocação do jogo ainda está presente na memória.

Faz sentido otimizar e reescrever parte do código para o sistema DOTS, para dispositivos móveis incluindo VR/AR? Você usa este sistema em seus projetos?

Vários projetos de jogos agora fazem uso de partes do Data-Oriented Technology Stack (DOTS). Containers Nativos, o Sistema de Trabalho C#, Matemática, e o compilador Burst são todos pacotes totalmente suportados que você pode usar imediatamente para escrever código C# (HPC#) otimizado, paralelizado e de alto desempenho para melhorar o desempenho da CPU do seu projeto.

Um número menor de projetos também está usando Entidades e pacotes associados, como o Renderizador Híbrido, Unity Physics, e NetCode. No entanto, neste momento, os pacotes listados são experimentais, e usá-los envolve aceitar um grau de risco técnico. Esse risco deriva de uma API que ainda está evoluindo, recursos ausentes ou incompletos, bem como a curva de aprendizado de engenharia necessária para entender o Design Orientado a Dados (DOD) para aproveitar ao máximo o Sistema de Componentes de Entidade (ECS) da Unity. O engenheiro da Unity, Steve McGreal, escreveu um guia sobre melhores práticas do DOTS, que inclui alguns fundamentos do DOD e dicas para melhorar o desempenho do ECS.

Como você faz para definir limites nas chamadas de SetPass ou na complexidade do shader? Você pode até definir limites com antecedência?

A renderização é um processo complexo e não há uma maneira prática de definir um limite rígido no número máximo de chamadas de SetPass ou uma métrica para a complexidade do shader. Mesmo em uma plataforma de hardware fixa, como um console único, os limites dependerão do tipo de cena que você deseja renderizar e do que mais está acontecendo na CPU e na GPU durante um quadro.

É por isso que a regra sobre quando perfilar é "cedo e frequentemente". As equipes tendem a criar uma demonstração de "fatia vertical" no início da produção – geralmente um curto burst de jogabilidade desenvolvido ao nível de fidelidade visual pretendido para o jogo final. Esta é sua primeira oportunidade de perfilar a renderização e descobrir quais otimizações e limites podem ser necessários. O processo de profiling deve ser repetido toda vez que uma nova área ou outro grande pedaço de conteúdo visual for adicionado.

Aqui estão recursos adicionais para aprender sobre otimização de desempenho:

Blogs

• Otimize o desempenho do seu jogo para dispositivos móveis: Dicas de especialistas sobre gráficos e ativos
• Otimize o desempenho do seu jogo para dispositivos móveis: Dicas de especialistas sobre física, UI e configurações de áudio
• Otimize o desempenho do seu jogo para dispositivos móveis: Dicas de especialistas sobre criação de perfis, memória e arquitetura de código dos principais engenheiros da Unity
• Dicas de especialistas sobre como otimizar os gráficos do seu jogo para consoles
• Criação de perfis no Unity 2021 LTS: O que, quando e como

Páginas de como fazer

• Ferramentas de criação de perfis e depuração
• Como criar perfis de memória no Unity
• Melhores práticas para criar perfis de desempenho de jogos

E-books

• Otimize o desempenho do seu jogo para console e PC
• Otimize o desempenho do seu jogo para dispositivos móveis
• Guia definitivo para a criação de perfis de jogos no Unity

Aprenda tutoriais

• Criação de perfis de desempenho da CPU em builds Android com Android Studio
• Aplicações de criação de perfis – Feito com Unity

Conteúdo técnico ainda mais avançado está chegando em breve – mas, enquanto isso, sinta-se à vontade para sugerir tópicos para cobrirmos no fórum e confira a gravação completa do webinar em mesa redonda.