iOS Performance Optimization Series 02｜O ponto de partida da solução de problemas de desempenho do iOS: atraso, inicialização lenta, memória alta e bateria alta

Quando muitas equipes mencionam solução de problemas de desempenho, sua primeira reação é “abrir instrumentos”. Isso certamente é verdade, mas se você nem mesmo distinguir o tipo de problema primeiro, poderá facilmente cair em um estado mais tarde:

• Eu olhei muitas fotos
• Também registrei vários indicadores
• Mas ainda não consigo dizer onde está o principal problema

Então o primeiro passo que enfatizo é sempre a classificação.

Devido aos diferentes tipos de problemas de desempenho, as entradas de solução de problemas são completamente diferentes. Se você seguir na direção errada no início, quanto mais ferramentas você tiver mais tarde, mais fácil será ficar sobrecarregado de informações.

1. Primeiro pergunte claramente: Do que exatamente os usuários estão reclamando?

Esta etapa parece básica, mas é onde muitas soluções de problemas se perdem.

Você precisa primeiro tentar traduzir a pergunta em palavras mais específicas, em vez de um “aplicativo um pouco lento” geral.

Por exemplo:

• É lento para começar frio ou lento para começar quente?
• Uma determinada página abre lentamente ou todo o aplicativo está lento?
• A rolagem está travada ou a resposta fica lenta após clicar?
• Fica cada vez mais preso depois de muito tempo de uso ou fica preso assim que é ligado?
• É febre grave ou consumo anormal de energia?

Uma vez que o problema seja específico, o escopo da análise será bastante reduzido.

2. Inicialização lenta, atraso, memória alta e bateria alta são originalmente quatro caminhos diferentes para solução de problemas.

Embora todos sejam chamados de “problemas de desempenho”, quando se trata de solução de problemas, eles devem ser tratados como quatro tipos diferentes de problemas.

1. Inicialização lenta

Você deve prestar mais atenção a:

• A partida a frio e a quente são lentas?
• O que o thread principal faz durante a fase de inicialização
• Foi feita muita inicialização antes de renderizar a página inicial?
• As tarefas não críticas foram colocadas no caminho crítico?

2. Gagueira/quadros perdidos

Você deve prestar mais atenção a:

• O que o thread principal está fazendo no momento da queda de frames
• É layout, desenho, decodificação, processamento de dados ou muitas atualizações de status?
• Se aparece apenas em páginas específicas ou em listas específicas

3. Alta memória

Você deve prestar mais atenção a:

• É um pico alto ou é um máximo de longo prazo que não cairá? -É uma imagem, cache, vazamento de objeto ou um objeto grande é mantido por muito tempo?
• Se o problema ocorre após um caminho de função específico

4. Bateria alta/calor

Você deve prestar mais atenção a:

• Existem muitas tarefas em segundo plano?
• Se pesquisas, posicionamento e solicitações de rede são muito frequentes
• Se a CPU está continuamente ocupada -Se algumas páginas têm atualização inválida ou tarefas ativas de longo prazo

Diferentes tipos de problemas devem ser abordados de diferentes direções. Misturá-los só levará a muitas informações ao mesmo tempo, mas nenhuma conclusão real.

3. Se o problema não puder ser reproduzido de forma estável, não se apresse em ir mais fundo.

Esta é a etapa que muitas equipes tendem a pular.

Se um problema ainda estiver neste estado:

• “Às vezes pode ser lento”
• “Ocasionalmente preso”
• “Um colega disse que seu celular está quente”

O mais importante neste momento é tornar as condições de recorrência o mais específicas possível:

• qual dispositivo
• Qual versão do sistema
• Qual caminho operacional
• Partida a frio ou partida a quente
• O Wi-Fi ainda está fraco
• Login ou modo visitante

Porque o maior medo na solução de problemas de desempenho é confundir os limites do problema. Sem um caminho de reprodução estável, todas as análises subsequentes serão facilmente desviadas.

4. Prefiro restringir o escopo primeiro, em vez de buscar uma explicação completa.

Uma situação comum é que, ao solucionar problemas de desempenho, você queira “explicar todo o problema detalhadamente” desde o início. Mas no trabalho real, uma forma mais eficiente geralmente é dividida em duas etapas:

Etapa um: Limite o escopo

Vamos primeiro descobrir onde está o problema:

• link inicial
• uma determinada página
• uma lista
• uma determinada cena fotográfica
• uma tarefa em segundo plano

Etapa dois: aprofundamento direcionado

Depois de restringir o escopo, use ferramentas e dados mais específicos para identificar gargalos.

O valor desta sequência é: Primeiro, construa um “mapa do problema” em vez de procurar cegamente respostas em indicadores enormes.

5. Um julgamento muito prático: este é um “problema de caminho crítico” ou um “problema de acumulação de longo prazo”

Esses dois tipos costumam ser misturados, mas a lógica de solução de problemas é diferente.

Problemas de caminho crítico

Por exemplo:

• Partida lenta a frio
• A página abre lentamente
• Resposta lenta após clicar

Esse tipo de problema é mais como “muito trabalho é feito em um determinado momento”, e o que precisa ser encontrado é o gargalo no momento crítico.

Problema de acumulação de longo prazo

Por exemplo:

• Fica cada vez mais preso depois de muito tempo de uso.
• A memória está ficando cada vez mais alta
• A bateria continua alta

Esse tipo de problema é mais parecido com “a estratégia de operação de longo prazo do sistema não é saudável”. O que precisa ser observado são os custos cumulativos e as questões do ciclo de vida.

Esta distinção é muito prática, porque determinará diretamente se devemos focar num processo instantâneo ou observar a tendência ao longo de um período de tempo.

6. Mal-entendidos comuns: tire conclusões antes de classificar os tipos

É fácil fazer estes julgamentos prematuros na solução de problemas de desempenho:

• “Deve ser um problema de imagem”
• “Isso deveria ser culpa do SwiftUI”
• “Isso parece um vazamento de memória”

Essas suposições às vezes são corretas, mas se você tirar conclusões muito cedo, será fácil que a análise subsequente gire em torno de apenas uma hipótese.

Então prefiro responder primeiro:

• Que tipo de problema é esse?
• Em que caminho isso ocorre?
• Quais são as condições de recorrência?
• É esporádico ou estável?

É mais importante primeiro classificar o problema corretamente do que primeiro adivinhar o motivo.

7. Uma sequência inicial mais próxima do combate real

Se alguém me lançasse uma questão de desempenho hoje, eu normalmente começaria com esta sequência:

1. Pergunte com clareza sobre o fenômeno percebido pelo usuário.
2. Determine se é inicialização, atraso, memória ou bateria.
3. Confirme se pode ser reproduzido de forma estável.
4. Confirme se o problema está concentrado em uma determinada página ou caminho.
5. Decida qual ferramenta usar em seguida.

Essa sequência parece muito simples, mas pode reduzir significativamente a situação de “a ferramenta está muito aberta, mas a direção ainda não está clara”.

8. Conclusão: Divida primeiro o problema e depois use as ferramentas, a eficiência será muito maior

Para resumir, eu diria:

A primeira etapa mais importante na solução de problemas de desempenho do iOS é primeiro dividir os problemas em diferentes tipos, como “inicialização lenta, atraso, memória alta e bateria alta” e, em seguida, decidir o caminho de análise.

Porque uma vez que os problemas de desempenho não são classificados primeiro, não importa quanta informação venha depois, será difícil chegar realmente perto da resposta.