⌛ Tempo de recapitulação

No meu último blog eu falei sobre como reduzi o tamanho do meu aplicativo de 75MB para 34MB em apenas 2 semanas (Veja!). Mas isso não é tudo, também melhorei o desempenho geral do nosso aplicativo em até 80%?.

Vamos descobrir COMO!!

? A tradição

Depois de uma simples rodada de análise, descobri alguns dos principais problemas em nosso aplicativo, levando a uma experiência e desempenho ruins do usuário. Que dia!

• Main Villain - UI inteira do aplicativo congelada ao gerar resposta em tempo real

• Side Villain – Tempo de resposta lento e sem taxas de quadros

• Amante do vilão - Muitas chamadas de API

• The Undead Army – Mau tratamento de erros e travamentos

• Sofrimentos - Mais uso de CPU e custos de servidor

• O Manchado - EU!

Daí começa uma batalha sem vida de recriação do universo com uma esperança mundial melhor.

O Plano Taiti (mas desta vez funciona)

Então comecei abordando primeiro os problemas mais fáceis, pois é mais fácil ignorar a grande depressão do que combatê-la no momento.

1. ⚛️ Maldição de Reação

A sabedoria e a maldição dos ReactJs são estados. À medida que envelhecemos no React, percebemos que quanto menos estados, melhor é a aplicação. Portanto, esta obra de arte em particular estava usando 22 (Sim, malditos 22 useStates) em uma única tela de bate-papo onde tudo que você pode fazer é enviar mensagem e receber mensagem.

Cereja no topo!
Estávamos usando a implementação de eventos do lado do servidor para obter dados pedaço por pedaço de server , que no caso era palavra por palavra. Então, se você tiver uma consulta que tenha uma resposta de 100 palavras (ESTA É A MENOS RESPOSTA). Na verdade, ele receberá 100 eventos.

Então, se você conhece a matemática, 100*22 = 2.200 re-renderizações cada vez que obtemos uma resposta.

Preciso explicar mais alguma coisa? ( NÃO )

Então comecei a recriar a tela inteira e reduzi o número para 6 estados agora. Com funcionalidade melhor e mais suave como antes.

Isso é 72% mais desempenho que o anterior !!

2. ❄️ O Deserto Congelado

Agora, depois de testemunhar o Radahn do React, podemos facilmente concluir que o aplicativo vai congelar bastante, certo?

Agora, mesmo com 6 estados, o problema principal permanece o mesmo: 100*6. Ainda estamos pendurados, mas com menos estados.

A principal causa foi o react dom sendo atualizado em cada pedaço. Então, para resolver isso, usamos "Processamento em lote e geração de taxas de quadros.

Inferno, sim!

Então, basicamente, em vez de atualizar o DOM cada vez que obtemos um pedaço, estávamos criando lotes de pedaços e atualizando-os em uma taxa de quadros dinâmica fixa. Essas taxas de quadros foram chamadas do sistema operacional para que cada dispositivo tenha um FPS diferente de acordo com a capacidade do sistema, dando ao aplicativo um desempenho mais robusto e compatível.

Capturamos um conjunto limitado de pedaços em um lote e mantemos a resposta até que o quadro seja liberado e repetimos a mesma coisa até que todos os pedaços sejam processados.

Portanto, em vez de atualizar o DOM 100 vezes, atualizamos o DOM apenas 3-4 vezes.

Agora faça as contas e calcule a melhoria de desempenho do dever de casa!

3. ? Seja um bom ouvinte!

Não funcionou para mim conseguir uma namorada, mas certamente funcionou para tornar o aplicativo muito melhor.

As APIs são uma maneira legal e agradável de obter dados, mas usá-las com sabedoria é uma habilidade sua! Agora, este aplicativo estava usando esta API para obter o status do usuário no back-end. Mas o melhor é que estava usando a cada 3 segundos !!

Entendi, o desenvolvedor tinha inseguranças, mas não era isso que eles queriam dizer ao trazer equilíbrio entre vida pessoal e profissional.

a) Buscando

Para obter os dados do usuário sempre que o usuário usar o aplicativo, é necessário fazer a chamada no início do aplicativo ou sempre que o aplicativo for chamado recentemente (escuta de estado do aplicativo). Chamá-lo a cada 3 segundos não apenas usa recursos móveis em um fluxo infinito, mas também causa sobrecarga no servidor.

Em vez de obter 100 solicitações de 100 usuários, o serviço receberá 100 solicitações de 1 usuário. Não parece muito escalável e confiável para mim.

Além de criar vazamentos e usos de memória não rastreáveis, o que cria problemas em usos mais longos.

b) Fluxo de dados

Agora, depois de resolver aquele ataque DDOS interno, descobri que este aplicativo estava usando muitas APIs cujos dados estavam ficando fantasmas no ar (manipulação deficiente de dados). Em vez de armazenar dados em cache e usá-los novamente no mesmo fluxo, o aplicativo estava chamando APIs novamente.

Garanti que os dados fossem armazenados em cache e fluíssem linearmente para o fluxo e que a API fosse chamada apenas quando necessária para uma nova instância.

Ponto para lembrar!

Isso resultou em melhor integridade do servidor e menos tempo de inatividade para nosso back-end devido a muitas solicitações de API. Como a execução do back-end custa à empresa, é crucial usar APIs de forma eficaz e somente quando necessário

Não apenas para back-end, mas também para front-end, fazer chamadas extras de API consome mais sistema, pois é necessário fazer mais handshakes e protocolos HTTP sempre que você faz uma chamada.

3. ? Não é um erro se não o reconhecemos!

Uma das coisas cruciais para lidar com APIs é ERROS. Consolá-los com os logs não é suficiente, pois torna a experiência do usuário muito pior do que seus bons usos.

É importante lidar com erros de qualquer ação usando algum tipo de sistema de feedback. Pode ser um alerta ou pop-up ou brinde ou qualquer coisa. Mas o usuário deve saber por que e como isso aconteceu para que possa relatar ou pelo menos saber o que fez de errado!

4. ? Suas memórias

Tenho você, mano! Ela não vai voltar, mas os vazamentos de memória vão. Uma das principais coisas que esquecemos ao anexar qualquer ouvinte ou chamada de API é remover sua instância depois de fecharmos essa atividade.

Este aplicativo tinha um tom disso, chamadas de API eram chamadas mesmo depois que a atividade era fechada ou em segundo plano. Causando uso desnecessário da CPU e consumo excessivo de recursos, tornando o aplicativo mais lento e difícil de usar.

A limpeza adequada deles torna o aplicativo mais rápido e menos complicado.

5. Declaração de Desempenho

Agora, uma maneira básica de usar qualquer ativo é importá-lo e usá-lo corretamente ?

Mas você sabe como funciona? Cada vez que você importa um item por padrão, ele é alocado na memória com uma inicialização. Então, se você importar e declarar uma imagem ou componente em 5 arquivos como este

importar perfil de '../../profile'

import Profile from '../../profile'

Em vez disso, você deve chamar todos os ativos em um arquivo de índice e importar o objeto dele, dessa forma ele será declarado apenas uma vez e será usado por Referência em todos os lugares.

Reduzindo assim o uso de memória para 4/5.

✅ Conclusão -

Você é um bom homem, Arthor! (Desculpe, acabei de completar RDR2 e foi um ótimo jogo).

Com essas mudanças, o desempenho do aplicativo aumentou muito, não apenas com melhor saúde do lado móvel, mas também com melhor otimização do lado do servidor.

A avaliação da loja passou de 3,5 para 4,1 em apenas 1 semana de uso !!!

Lembre-se de que não se trata apenas de um código, mas de uma história sobre como os usuários interagem com ele.

Como desenvolvedor Frontend, todo o produto depende de nós. Não importa o quão escalável seja o back-end, o produto final que o usuário vai usar já está criado e é a única coisa sobre a qual eles tomam decisões. Portanto, é muito importante para nós proporcionar-lhes uma interação tranquila que leve a melhores negócios para toda a empresa.

? Deixe comentários se gostar do blog ou compartilhe-o com seus amigos para que eles também gostem!