Criação de perfil com instrumentos

Na equipe de Suporte Corporativo, vemos muitos projetos iOS. Em algum momento, em qualquer desenvolvimento para iOS, os desenvolvedores geralmente acabam executando seus jogos e ficam pensando: "Por que diabos isso está rodando tão lentamente?". Existem alguns ótimos conjuntos de ferramentas para análise de desempenho e um dos melhores é o Instruments. Continue lendo para descobrir como usá-lo para encontrar seus problemas!

Para usar o Instruments ou qualquer uma das ferramentas de depuração do XCode, você precisará criar um projeto Unity para o iOS Build Target (com as opções Development Build e Script Debugging desmarcadas). Em seguida, você precisará compilar o projeto XCode resultante com o XCode no modo Release e implantá-lo em um dispositivo iOS conectado.

Após iniciar os Instrumentos (pressionando longamente o botão de reprodução ou selecionando Produtos>Perfil), selecione o Time Profiler. Para iniciar uma execução de criação de perfil, selecione o aplicativo criado no seletor de aplicativos e pressione o botão vermelho Gravar. O aplicativo será iniciado no dispositivo iOS com o Instruments conectado, e o Time Profiler começará a registrar a telemetria. A telemetria aparecerá como um gráfico azul na linha do tempo dos Instrumentos.

PS Para limpar a hierarquia de chamadas, pressione o botão Árvore de chamadas no canto inferior esquerdo do painel Detalhes para mostrar as opções e selecione Achatar recursão e ocultar bibliotecas do sistema.

Uma lista de chamadas de métodos aparecerá na seção de detalhes da janela Instrumentos. Cada chamada de método de nível superior representa um thread dentro do aplicativo.

Em geral, o método principal é a localização de todos os pontos de interesse, pois ele contém todo o código gerenciado.

Expandir o método principal produzirá uma árvore profunda de chamadas de métodos. O ramo principal está entre dois métodos:

• [startUnity] e UnityLoadApplication (esses nomes de métodos às vezes aparecem em CAIXA ALTA).
• PlayerLoop

[startUnity] é interessante porque contém todo o tempo gasto na inicialização do mecanismo Unity. Um método chamado UnityLoadApplication será encontrado abaixo dele. É abaixo do UnityLoadApplication que o tempo de inicialização pode ser criado.

Depois de ter um bom intervalo de tempo do seu aplicativo perfilado, pause o Profiler e comece a expandir a árvore. À medida que você avança na árvore, você notará que o tempo em ms diminui na coluna da esquerda. O que você procura são itens que causem uma redução significativa no tempo. Este será um ponto de encontro para apresentações. Depois de encontrar um, você pode voltar para sua base de código e descobrir o que está acontecendo que está tomando tanto tempo. Pode ser que seja uma operação totalmente necessária, ou pode ter ocorrido em algum momento no passado distante em que você hackeou algum código de pré-produção que foi transferido para seu projeto de produção, ou... bem... pode haver um milhão de razões, na verdade. Se ou como você decidirá consertar esse ponto de acesso, isso dependerá muito de você, pois você conhece sua base de código melhor do que ninguém. :D

Os instrumentos também podem ser usados para procurar por pontos de desempenho amplamente distribuídos — aqueles que não têm um único ponto de acesso grande, mas que aparecem como alguns milissegundos de tempo perdido em muitos lugares diferentes em uma base de código. Para fazer isso, digite um nome de função parcial ou completo na caixa de pesquisa de símbolos do Instruments, exibida ao pressionar ⌘F ou clicar em Localizar/Localizar… no menu Editar . Ao criar o perfil de uma parte do jogo, expanda PlayerLoop e recolha todos os métodos abaixo dele. Ao criar um perfil do tempo de inicialização, expanda UnityLoadApplication e recolha os métodos abaixo dele. O número total de milissegundos desperdiçados em uma operação específica pode ser estimado aproximadamente observando o tempo total gasto em PlayerLoop ou UnityLoadApplication e subtraindo o número de milissegundos localizados na coluna self.

Métodos comuns para procurar:

• “Box(“, “box” e “box” — estes indicam que o boxing de valores C# está ocorrendo; a maioria das instâncias de boxing são trivialmente corrigidas
• “Concat” — a concatenação de strings geralmente é facilmente otimizada
• “CreateScriptingArray” — Todas as APIs Unity que retornam arrays alocarão novas cópias de arrays. Minimize chamadas para esses métodos.
• “Reflexão” — a reflexão é lenta. Use isso para estimar o tempo perdido na reflexão e eliminá-lo sempre que possível.
• “FindObjectOfType” — Use isso para localizar chamadas repetidas ou desnecessárias para FindObjectOfType ou outras APIs Unity conhecidas como lentas.
• “Linq” — Examine o tempo perdido na criação e descarte de consultas Linq; considere substituir hotspots por métodos otimizados manualmente.

Além de criar um perfil de tempo de CPU, o Instruments também permite que você crie um perfil de uso de memória. O criador de perfil de alocações da Instruments fornece duas sondas que oferecem visualizações detalhadas do uso de memória de um aplicativo. A sonda Alocações permite a inspeção dos objetos residentes na memória durante um período de tempo específico. A sonda VM Tracker permite o monitoramento do tamanho do heap de memória suja, que é a principal métrica usada pelo iOS para determinar quando um aplicativo deve ser fechado à força.

Ambas as sondas serão executadas simultaneamente ao selecionar o criador de perfil de alocações em Instrumentos. Como de costume, inicie uma execução de perfil pressionando o botão vermelho Gravar.

Para configurar a sonda de alocações corretamente, certifique-se de que as seguintes configurações estejam corretas. Na parte inferior da janela, certifique-se de que o Período de Alocação (opção do meio) esteja definido como Criado e Persistente. Nas Opções de gravação (menu Arquivo), certifique-se de que Descartar eventos para memória liberada esteja marcado.

A exibição mais útil para examinar o comportamento da memória é a exibição Estatísticas, que é a exibição padrão ao usar a sonda Alocações. Esta exibição mostra uma linha do tempo. Quando usado com as configurações recomendadas, o gráfico exibe linhas azuis indicando o tempo e a magnitude das alocações de memória que ainda estão ativas. Ao observar esse gráfico, você pode observar se há memória de longa duração ou com vazamento, simplesmente repetindo o cenário em teste e garantindo que nenhuma linha azul permaneça ativa entre as execuções.

Outra exibição útil é a exibição de Árvores de Chamadas. Ele exibe a linha de código na qual as alocações são executadas, juntamente com a quantidade de consumo de memória pela qual a linha de código é responsável. Você pode alterar a exibição clicando à direita de Detalhes, conforme mostrado aqui:

Abaixo você pode ver que cerca de 25% do uso total de memória do aplicativo em teste é devido exclusivamente aos shaders. Dado que a localização dos shaders no thread de carregamento, esses devem ser os shaders padrão agrupados com os projetos padrão do Unity, que são então carregados no momento da inicialização do aplicativo.

Assim como antes, depois de identificar um ponto de acesso, o que você fará com ele dependerá totalmente do seu projeto.

Então aí está. Um breve guia para instrumentos. 1000(mais ou menos) palavras e nenhuma referência ao Esquadrão Classe A. Não queremos ter problemas como da última vez. Violações de direitos autorais oficialmente não são engraçadas™.

A equipe de Suporte Empresarial está criando mais guias como esses e publicaremos as versões completas dos nossos guias de Melhores Práticas nos próximos meses!

Adoramos quando um plano dá certo.