Trabalho fora da tela
Rede, banco, imagem e cálculo rodam em segundo plano. A linha que desenha a tela fica livre para desenhar.
Ecossistema YveTech · Mobile · Por dentro
O app em movimento
Listas rolando sem engasgo, gráficos atualizando e a tela respondendo ao toque antes de o dedo sair. Nada disso é acaso: é um conjunto de decisões técnicas que cabe explicar sem jargão — porque é o que separa um app que as pessoas usam de um que elas toleram.
Você tem 16 milissegundos por quadro
A 60 quadros por segundo, é esse o tempo que o aplicativo tem para desenhar cada um. Passou disso, o olho vê o engasgo.
Fluidez não é uma impressão vaga — é uma conta. Para a tela atualizar 60 vezes por segundo, cada quadro precisa ficar pronto em menos de 16 milissegundos; em aparelhos com tela de 120 Hz, em menos de 8. Se uma leitura de banco, um cálculo pesado ou o processamento de uma imagem acontecer no meio desse intervalo, o quadro perde a hora e a rolagem trava. É por isso que trabalho pesado nunca roda na mesma linha de execução que desenha a tela.
A segunda regra é reciclar. Uma lista de 5.000 pedidos não cria 5.000 telas: cria as dez ou quinze que cabem na tela e reaproveita cada uma à medida que a rolagem avança. Parece detalhe, e é o que decide se o app abre a lista instantaneamente ou se ele consome memória até o sistema encerrá-lo — quase sempre no aparelho mais modesto, que costuma ser o de quem mais usa.
A terceira é responder na hora, ainda que a resposta seja parcial. Quando alguém toca em salvar, a tela reage no mesmo instante: o botão muda de estado, o item aparece na lista, o app segue navegável. A gravação no servidor acontece atrás, e se falhar, o app avisa e desfaz. Sensação de rapidez é, em boa parte, ausência de espera sem resposta.
Aparelho de entrada é o teste de verdade. Um app que roda liso no celular mais caro do time e engasga no do usuário foi otimizado para a pessoa errada.
O que sustenta a fluidez
Seis decisões técnicas que aparecem como sensação e se explicam como engenharia.
Listas recicladas
Só o que está visível existe. Rolagem infinita com memória constante, mesmo em base grande.
Imagens tratadas
Redimensionadas ao tamanho real de exibição, em cache no aparelho e carregadas progressivamente.
Resposta imediata ao toque
A tela reage antes de o servidor confirmar; se der erro, o app avisa e reverte.
Animação com propósito
Transições curtas que explicam de onde a tela veio. Movimento decorativo cansa e atrasa.
Medição contínua
Quadros perdidos, tempo até a primeira tela útil e consumo de memória medidos a cada versão.
A mesma cena, por dentro
O que a vitrine mostra em movimento, congelado nos três momentos que importam.
Como perseguimos isso em cada entrega
Desempenho é requisito de cada ciclo, não um mutirão no fim do projeto.
Definir o alvo
Escolhemos com você o aparelho mais modesto que precisa rodar bem. Ele passa a ser a régua.
Medir antes de otimizar
Perfilamos a tela lenta e descobrimos a causa real. Otimização por palpite costuma complicar o código sem ganho.
Corrigir a causa
Trabalho para segundo plano, consulta reduzida, imagem no tamanho certo, lista reciclada.
Travar o ganho
A medição entra na esteira: se uma versão nova estourar o orçamento de quadro, aparece antes de chegar à loja.
O que faz um app parecer lento
As causas mais comuns, em ordem de frequência no que recebemos para consertar.
- Consulta na linha da tela — banco ou rede sendo lidos enquanto a tela tenta desenhar.
- Imagem gigante em espaço pequeno — foto de 4.000 pixels desenhada num espaço de 300.
- Lista sem reciclagem — todos os itens criados de uma vez, memória subindo até fechar.
- Abertura pesada — tudo carregado na inicialização, inclusive o que só vai ser usado depois.
O que medimos em cada versão
Números acompanhados versão a versão, e não só quando alguém reclama.
- Tempo até a primeira tela útil — quanto o usuário espera para conseguir fazer algo.
- Quadros perdidos por rolagem — quantas vezes o app estourou o orçamento de 16 ms.
- Memória em uso — o pico durante a navegação nas telas mais pesadas.
- Bateria e dados — quanto o app consome em uso típico de um dia.
Sintoma, causa provável e correção
O caminho que percorremos quando alguém diz que o aplicativo está lento.
| O que se percebe | Causa mais comum | Correção usual |
|---|---|---|
| A lista treme ao rolar | trabalho pesado no momento de desenhar cada item | preparar os dados antes e manter a célula simples |
| O app demora a abrir | inicialização carregando o que ainda não é necessário | adiar o não essencial para depois da primeira tela |
| A tela congela ao salvar | espera pela resposta do servidor sem retorno visual | atualizar a tela na hora e confirmar em segundo plano |
| A imagem entra tremendo | foto no tamanho original sendo redimensionada na hora | gerar a versão do tamanho certo e guardar em cache |
| O celular esquenta | atualização em excesso ou animação sem parada | reduzir a frequência e parar o que não está visível |
| Fecha em aparelho antigo | consumo de memória acima do que o modelo suporta | reciclar listas, liberar imagens e testar no aparelho real |
Compromissos desta etapa
O que combinamos antes de começar — e cobramos de nós mesmos durante o projeto.
60 fpsmeta de fluidez nas telas principais
16 msorçamento por quadro desenhado
< 2 salvo até a primeira tela útil
Aparelho realmedição no modelo mais modesto da lista
Perguntas frequentes sobre o app em movimento
As dúvidas que mais aparecem nesta etapa. Sobre prazo, forma de cobrança e contrato, veja as perguntas frequentes da YveTech.
Multiplataforma consegue essa fluidez?
Em aplicativo de negócio, consegue — e o usuário não distingue. React Native e Flutter desenham com aceleração de vídeo e alcançam os mesmos 60 quadros por segundo quando o app é bem construído. A diferença aparece em casos extremos: jogo, gráfico pesado, processamento contínuo de câmera.
Dá para deixar rápido um app que já existe?
Na maioria das vezes, sim, e sem reescrever. Começamos medindo para achar a causa real — costumam ser dois ou três pontos concentrados, não o aplicativo inteiro. Só recomendamos reconstrução quando a arquitetura impede a correção, e nesse caso mostramos por quê.
Por que testar em celular fraco se meus clientes têm bons aparelhos?
Porque a suposição costuma estar errada, e porque o aparelho modesto revela problemas que existem em todos — só que nos bons celulares eles ficam escondidos pela sobra de processamento. Corrigir ali melhora a experiência em toda a base.
Animação atrapalha o desempenho?
Animação curta e com propósito ajuda: ela explica para onde a tela foi e reduz a sensação de espera. O que atrapalha é movimento decorativo, longo ou que continua rodando fora da vista — e isso nós evitamos por padrão.
Seu aplicativo trava onde não devia?
Conte em que tela e em que aparelho. Medimos, achamos a causa e mostramos o que dá para corrigir sem reescrever.
Continue explorando
As quatro etapas do método e os três recortes da operação — cada uma com o seu próprio detalhamento.
Aplicativos MobileVoltar à visão geral da área
Jornada e protótipoAs telas navegáveis validadas com gente de verdade antes do código
DesenvolvimentoNativo ou multiplataforma, decidido pelo seu caso e não por preferência
Publicação assistidaApp Store e Google Play conduzidas por nós, inclusive as recusas
Evolução por dadosO que o uso real revela — e as atualizações que nascem disso
Navegação principalA estrutura de abas pensada para o uso com uma mão só
Ambiente de Aplicativos MobileA malha que sustenta o app: serviços, sincronização, push e distribuição