Série 01 de Otimização de Desempenho do iOS｜Metas e Escopo da Otimização de Desempenho do iOS

Quando o tema otimização de desempenho é mencionado, a primeira reação geralmente é:

• Gagueira ou não
• Sem quedas de quadro
• É rápido para começar?

Claro, todos esses são problemas de desempenho, mas se você entender a otimização de desempenho apenas como “tornar a página mais rápida”, será fácil se distrair mais tarde. Porque os problemas de desempenho em projetos reais são basicamente um grupo de problemas de qualidade misturados.

No mesmo produto, problemas de desempenho podem aparecer como:

• A primeira tela abre lentamente
• A lista não desliza suavemente
• Ocasionalmente, quadros perdidos na página de detalhes
• A memória não recua quando sobe
• Consumo anormal de energia
• É muito lento entrar novamente na página depois de passar do fundo para o primeiro plano.

Portanto, a primeira pergunta que a otimização de desempenho realmente precisa responder é:

De que tipo de lentidão é a “lentidão” de que estamos falando agora?

1. A otimização do desempenho está otimizando a qualidade geral de execução.

Problemas reais de desempenho do iOS podem ser divididos pelo menos nas seguintes categorias:

• Hora de inicialização
• Congelamento de página e queda de quadro
• Uso e reciclagem de memória
• Energia e calor
• Eficiência no uso de rede e recursos

Parece que todos esses tipos de problemas podem ser classificados como “desempenho”, mas suas causas, métodos de solução de problemas e métodos de otimização são completamente diferentes.

Por exemplo:

• Inicialização lenta, geralmente relacionada a links de inicialização e caminhos de inicialização a frio
• O atraso da lista geralmente está relacionado à carga de trabalho do thread principal, ao layout e à decodificação de imagem.
• Alta memória pode estar relacionada à estratégia de cache, ciclo de vida do objeto e retenção de imagem
• Bateria alta geralmente está relacionada a pesquisas frequentes, tarefas em segundo plano e atualizações inválidas

Se você não classificar o problema primeiro, é fácil que uma falsa ocupação apareça mais tarde: Abri muitas ferramentas e observei muitos indicadores, mas nunca cheguei perto do problema central.

2. O desempenho percebido pelo usuário e o desempenho do índice do sistema não são a mesma coisa, mas ambos são importantes

As questões de desempenho podem ser divididas aproximadamente em duas perspectivas:

1. Problemas de desempenho percebidos pelo usuário

Os usuários podem sentir isso diretamente, como:

• A página travou ao abri-la.
• Listar quedas de quadros deslizantes
• Os resultados da pesquisa saem muito lentamente
• Quando o aplicativo é aberto, a tela fica em branco por um longo tempo

Esse tipo de questão costuma ser de alta prioridade porque impacta diretamente a experiência e a retenção.

2. Problemas de desempenho do indicador

Os usuários podem não conseguir descrevê-lo claramente, mas gradualmente aparecerá como:

• Febre
• Consumo de energia
• Frequentemente morto em segundo plano
• A memória permanece em alto nível por muito tempo

Esse tipo de problema pode não necessariamente se transformar imediatamente em uma crítica negativa, mas lentamente o tiro sairá pela culatra na qualidade de todo o produto.

O problema para muitas equipes é: Concentre-se apenas no primeiro e pense “simplesmente não perca frames”; ou apenas focar nos indicadores da ferramenta, esquecendo que o usuário na verdade não se preocupa com um determinado número em si, mas se ele eventualmente ficará preso, gerará calor e consumirá energia.

3. Muitas das chamadas “otimizações de desempenho” são essencialmente questões de limites de engenharia.

Este é o ponto mais subestimado.

Muitos problemas de desempenho foram finalmente investigados, e o verdadeiro problema estava na perda de controle no nível de engenharia:

• A página dá muito trabalho que deveria ser afundado
• Muita lógica desnecessária é colocada na fase de inicialização
• Carregamento, cache e decodificação de imagens não são em camadas
• Os limites entre a reutilização de listas e a atualização de dados são confusos
• Os mesmos dados são processados várias vezes

Isto significa que a otimização do desempenho é muitas vezes um “pagamento da dívida estrutural”.

Portanto, se os limites das responsabilidades de um projeto são originalmente muito confusos, os problemas de desempenho subsequentes muitas vezes não serão problemas isolados, mas uma das manifestações de problemas estruturais.

4. O erro de julgamento mais comum na otimização de desempenho: atribuir toda a lentidão à “renderização” ou ao “dispositivo”

Uma situação comum é que, ao ver um cartão, você primeiro pensa em:

• O equipamento é muito antigo?
• Existem muitas animações?
• É porque o SwiftUI em si não é bom?

Claro que isto é possível, mas as situações mais comuns em projetos reais são:

• Muito processamento de dados é feito no thread principal
• Decodificação de imagens enquanto rola a lista
• Muitas atualizações inválidas acionadas por uma mudança de estado
• Muitas inicializações não críticas são feitas quando a primeira tela é aberta

Em outras palavras, o problema muitas vezes não está na “estrutura de renderização”, mas em “permitir que o thread principal assuma muito trabalho que é desproporcional às ações atuais do usuário”.

Portanto, a otimização do desempenho é responder primeiro:

-Em qual camada está o gargalo atual?

• Este trabalho acontecerá neste momento
• Não era para acontecer aqui?

5. A otimização de desempenho é um conjunto de “recursos de classificação de problemas”

Uma situação comum é que quando você pensa em otimização de desempenho, você busca:

• Dicas de otimização de inicialização
• Listar dicas de otimização
• Dicas de cache de imagens

As técnicas são certamente úteis, mas podem facilmente se transformar em digitação cega se o problema não for categorizado primeiro.

Um ponto de partida mais prático geralmente é:

1. O problema é inicialização, atraso, memória ou consumo de energia.
2. Este problema é do tipo percepção do usuário ou do tipo indicador?
3. Está concentrado em uma determinada página ou em todo o aplicativo?
4. Recorre de forma consistente ou aparece apenas esporadicamente em determinadas vias?

Esta etapa não parece ser uma “exibição de habilidades”, mas determina se a investigação subsequente terá um rumo.

6. A otimização do desempenho geralmente retorna à “responsabilidade e limites”

Porque os problemas de desempenho dizem essencialmente: Em algum momento, o sistema assume muito trabalho que não deveria.

Por exemplo:

• Inicialização excessiva foi feita quando a página foi aberta.
• Os cálculos de decodificação e layout são realizados simultaneamente ao rolar a lista
• Uma certa estratégia de cache faz com que a memória fique ocupada por muito tempo
• Uma certa mudança de estado faz com que as visualizações multicamadas sejam reconstruídas repetidamente

Essas perguntas eventualmente forçaram uma nova resposta:

• Quem deve fazer este trabalho?
• Quando deve ser feito?
• Isso precisa ser feito sempre?
• Pode ser adiado, dividido ou armazenado em cache?

Portanto, a otimização do desempenho muitas vezes envolve “reorganizar a distribuição do trabalho do sistema”.

7. Conclusão: O que realmente precisa ser otimizado na otimização de desempenho é o desequilíbrio entre a experiência do usuário e os recursos do sistema.

Para resumir, eu diria:

O que a otimização de desempenho do iOS realmente precisa otimizar é a incompatibilidade entre a carga de trabalho do sistema e a percepção do usuário por trás de problemas específicos, como inicialização, atraso, memória e consumo de energia.

Portanto o primeiro passo é sempre distinguir o tipo de problema:

• Onde está a lentidão?
• O que é importante?
• Onde é gasto?
• Isso vai acontecer neste momento

Somente se essas questões forem esclarecidas primeiro é que as otimizações subsequentes não se tornarão um acúmulo de experiência sem objetivo.