iOS Performance Optimization Series 05｜Práticas eficazes para otimização de inicialização do iOS

A otimização de inicialização é um tópico que pode facilmente ser transformado em uma “coleção de pedaços”.

As pessoas geralmente se lembram de muitas experiências:

• Faça menos inicialização
• Carregamento lento
• Torne a primeira tela simples
• Não faça muitas solicitações na inicialização

É claro que essas sugestões estão todas corretas, mas se o julgamento central não for compreendido, muitas vezes acaba se tornando “Parece que mudamos muitas coisas, mas a inicialização ainda não é significativamente mais rápida”.

A verdadeira chave para a otimização de startups é uma pergunta muito simples:

Quais tarefas realmente pertencem ao caminho crítico que deve ser concluído antes que o usuário veja a primeira tela e quais tarefas são convenientemente inseridas na fase de inicialização por conveniência?

1. A causa raiz da inicialização lenta geralmente é que o caminho crítico está ficando mais grosso.

Muitos projetos não demoram a começar inicialmente. A verdadeira desaceleração geralmente ocorre porque, à medida que a funcionalidade aumenta, mais e mais lógica é amontoada em “faça isso assim que o aplicativo iniciar” por padrão:

• Inicialização da configuração
• Inicialização de ponto enterrado
• Preparação do ambiente de rede
• Restauração do status do usuário
• Solicitação da página inicial
• Leitura de cache local
• Vários registros SDK

Tudo parece razoável por si só, mas o problema é que quando eles são empilhados na fase de inicialização, o caminho crítico torna-se cada vez mais pesado.

Portanto, os problemas reais mais comuns com otimização de startups são: **O trabalho que não deveria ter sido espremido neste momento está acumulado neste momento há muito tempo. **

2. Primeiro, distinga entre inicialização a frio, inicialização a quente e o “tempo disponível” que os usuários realmente percebem.

Se esta camada não for claramente distinguida, a otimização subsequente será facilmente tendenciosa.

Porque a “inicialização lenta” mencionada pelos usuários pode referir-se a coisas diferentes:

• Não há tela por muito tempo depois de clicar no ícone
• A página inicial sai, mas ainda não está operacional.
• O frame da página inicial saiu primeiro e demorou muito para completar o conteúdo.

Na verdade, eles correspondem a diferentes estágios de lentidão.

Do ponto de vista da engenharia, pelo menos devemos distinguir:

• Partida a frio: processo do zero
• Warm start: o processo foi retomado na memória
• O momento em que o usuário está realmente disponível: o momento em que o usuário pode ver e começar a interagir

Para iniciar a otimização, você precisa saber exatamente onde está perdendo tempo.

3. O primeiro passo que vale mais a pena é colocar o trabalho em camadas na fase inicial.

Costumo dividir o trabalho na fase de startup em três categorias:

1. Deve ser preenchido antes da primeira tela

Por exemplo:

• O esqueleto de interface mais básico
• Inicialização da dependência principal
• Status do usuário principal que deve ser conhecido imediatamente após a inicialização

2. Concluído o mais rápido possível após a primeira tela aparecer

Por exemplo:

• Pré-busca de dados secundários
• Algumas atualizações de configuração
• Conteúdo complementar de UI não crítico

3. Pode ser atrasado ou em segundo plano

Por exemplo:

• Preparação para certos locais de sepultamento
• Não afeta a limpeza do cache da página atual
• Aquecimento de recursos da página secundária

Esta etapa é mais valiosa do que qualquer truque de um ponto porque leva diretamente a ver: Acontece que grande parte da lentidão se deve ao fato de “não deveríamos estar fazendo isso agora”.

4. A razão pela qual muitas otimizações de inicialização não trazem benefícios é que elas apenas escrevem código local mais rapidamente, mas não alteram o caminho crítico.

Este é um mal-entendido muito comum.

Por exemplo, otimizar um determinado período de inicialização de 40ms a 10ms parece bom. Mas se essa inicialização não aparecer no caminho crítico, então a otimização mais eficaz pode ser “não faça isso aqui”.

Portanto, para julgar se vale a pena fazer uma otimização de inicialização, o que vejo com mais frequência é:

• É trabalho no caminho crítico?
• Pode ser retirado do caminho crítico?
• É algo em que os usuários devem confiar atualmente?

Isso é mais importante do que simplesmente observar a função demorar.

5. O carregamento do conteúdo da página inicial geralmente retarda a experiência de inicialização

Muitos aplicativos parecem iniciar lentamente, não necessariamente porque o processo é muito lento, mas porque o conteúdo disponível na primeira tela aparece tarde demais.

Por exemplo:

• O esqueleto da página inicial foi renderizado
• Mas você tem que esperar que várias solicitações retornem antes que elas estejam “realmente disponíveis”
• Alguns módulos esperam uns pelos outros
• O cache local não é carregado primeiro

A lentidão experimentada pelos usuários neste momento está, na verdade, mais próxima de um “problema de estratégia de conteúdo da primeira tela”, em vez de apenas um problema técnico de inicialização.

Portanto, a otimização de inicialização geralmente está vinculada à estratégia da primeira tela:

• Quais módulos devem aparecer simultaneamente
• Quais módulos podem ser usados como telas esqueleto?
• Qual conteúdo pode exibir primeiro os resultados armazenados em cache?

Muitas das chamadas startups lentas são, na verdade, causadas pela organização irracional do conteúdo na primeira tela.

6. Um julgamento mais próximo do combate real: o que está lento atualmente é a “inicialização” ou a “montagem da primeira tela”

Os dois muitas vezes se confundem.

Inicialização lenta

A questão é mais tendenciosa:

-SDK

• Serviços globais
• Leitura de configuração
• Injeção de dependência

A montagem da primeira tela é lenta

A questão é mais tendenciosa:

• O módulo da página inicial é muito pesado
• Trabalhar muito assim que a página aparece
• A cadeia de dependência de dados da primeira tela é muito longa

A otimização nessas duas direções é completamente diferente. O primeiro requer o desmantelamento da inicialização e o atraso na execução, enquanto o último requer o reexame da estrutura da página e da estratégia de conteúdo.

7. Conclusão: A premissa para iniciar a otimização ser verdadeiramente lucrativa é primeiro traçar o caminho crítico.

Para resumir, eu diria:

A otimização de inicialização é realmente lucrativa. Superficialmente, parece que existem muitas habilidades. Na verdade, está mais perto de distinguir primeiro: quais tarefas pertencem ao caminho crítico que deve ser concluído antes da primeira tela, e quais são apenas encargos que foram convenientemente inseridos na fase de inicialização há muito tempo.

Quando o caminho crítico não estiver claro, a otimização pode facilmente se transformar em diligência parcial. Uma vez que o caminho crítico esteja claro, muitas direções de otimização ficarão muito claras.