Eu trabalho na Mutual . Ela trabalha no Brasil, no campo da igualdade de crédito. Ajudamos mutuários e credores a se conectarem. Os primeiros buscam boas apostas, enquanto os segundos buscam renda que excede o que o mercado pode oferecer. Nosso produto é usado por uma ampla gama de usuários, trabalhamos em um país grande. Como resultado, nossos aplicativos iOS e Android React baseados em nativos são baixados para dispositivos muito diferentes.
Note-se que a maioria dos nossos usuários instala aplicativos em dispositivos econômicos. Podemos tirar essas conclusões usando os dados da biblioteca de classes de dispositivos do Facebook no ano .. Esta biblioteca, após receber informações sobre o modelo do dispositivo, informa em que ano esse dispositivo seria considerado um telefone principal de gama alta. Por exemplo, o telefone mais popular entre nossos usuários é o Samsung Galaxy A10. Este telefone, embora tenha sido lançado em 2019, poderia ser considerado o carro-chefe apenas em 2013. Analisando dados em dispositivos de usuários, podemos dizer que 85% desses dispositivos só poderiam ser reconhecidos como dispositivos de ponta em 2015 ou versões anteriores. Por esse motivo, temos requisitos especiais para otimizar nosso aplicativo móvel. O objetivo da otimização é que mesmo usuários com dispositivos fracos possam usar confortavelmente nosso aplicativo.Porcentagem de dispositivos que poderiam ser reconhecidos como carro-chefe em um ano específicoNesse sentido, prestamos muita atenção ao tamanho do aplicativo. No caso de sua versão do Android, era 26,8 MB. Embora esse tamanho não seja tão grande, é definitivamente mais do que o tamanho médio dos aplicativos de nossos usuários. Este valor, de acordo com o Google Play Console, é de 16,3 MB. O tamanho do aplicativo pode ser um fator decisivo para usuários com planos tarifários limitados ou para aqueles com dispositivos com pouca memória, o que força os usuários a selecionar cuidadosamente os aplicativos que eles instalarão. Como resultado, alguns aplicativos precisam ser desinstalados. Isso é especialmente importante no caso do aplicativo Mutual, pois os mutuários pagam parcelas mensais por meio desse aplicativo. Quando o mutuário desinstala nosso aplicativo, as chances de ele efetuar o pagamento no prazo são bastante reduzidas.E isso afeta diretamente os ganhos dos investidores que usam nossa plataforma.O tamanho do aplicativo Mútuo é muito maior que o tamanho médio dosaplicativos de nossos usuários.O tamanho do aplicativo afeta não apenas o nível de desinstalações. Tamanho também afeta a taxa de conversão das configurações do aplicativo. Aqui está um bom artigo sobre isso, escrito pela equipe do Google Play. Este artigo discute a importância do tamanho do aplicativo. Em particular, ele afirma que todos os 6 MB adicionais do tamanho do arquivo APK reduzem a taxa de conversão das instalações em 1%.Eles também falam sobre o fato de que nos países em desenvolvimento onde os dispositivos orçamentários são a norma, esse efeito é ainda mais forte. Nomeadamente, reduzir o tamanho do arquivo APK em 10 MB nos mercados emergentes corresponde a um aumento na taxa de conversão das instalações em cerca de 2,5%.Aumentando a taxa de conversão de instalações para cada 10 Mb de redução do tamanho do arquivo APK em diferentes países (de acordo com os dados internos do Google),ficamos muito motivados com a forma como a redução do tamanho do aplicativo pode afetar o nível de desinstalações e a taxa de conversão das configurações do aplicativo. Como resultado, começamos a trabalhar com o objetivo de reduzir o tamanho do aplicativo o máximo possível, levando em consideração sua conveniência para os usuários. A primeira etapa deste projeto foi analisar as recomendações oficiais doGoogle para desenvolvedores do Android.Pacote de aplicativos para Android
Lendo as recomendações, aprendemos que a maneira mais fácil de reduzir o tamanho de um aplicativo é usar um novo método de distribuição de aplicativos chamado Android App Bundle (AAB). Até esse momento, distribuímos o aplicativo, coletando o bom e antigo arquivo Android Package (APK), que pode ser executado na maioria dos dispositivos Android, e enviando-o para o Google Play Console. Mas o pacote AAB contém apenas código e recursos compilados. Como resultado, quando é baixado, o Google é responsável por gerar arquivos APK otimizados para vários tipos de dispositivos, levando em consideração suas especificações e arquitetura da CPU.Acontece que, ao fazer uma simples alteração no processo de compilação do projeto, podemos obter uma redução séria no tamanho do aplicativo sem fazer mais esforço? Isso é bom demais para a verdade!Depois de ler a documentação, alteramos o script de construção React Native Gradle para que ele assembleReleasefosse executado em vez do atual bundleRelease. É tudo o que precisamos para criar o arquivo AAB. Depois de mais algumas modificações feitas na supplyconfiguração do Fastlane em relação ao upload automático de materiais diretamente para a Play Store, mudamos para o AAB, e uma nova versão do nosso aplicativo apareceu no Google Play Console.Somente essa alteração levou a uma redução no tamanho dos arquivos APK transferidos para os dispositivos do usuário. A redução variou de 9,1 a 12,4 Mb. Como se viu, o uso do Android App Bundle é uma técnica eficaz que, de fato, permite reduzir o tamanho do aplicativo.O arquivo APK antigo e o novo pacote AAB, cuja utilização leva ao fato de que o tamanho do aplicativo em dispositivos diferentes pode ser de 14,4 a 17,7 MBTrue, você deve ter cuidado aqui. Se você usa o React Native with Hermes , pode ser necessário atualizar sua dependênciasoloader(veja detalhes aqui ). Caso contrário, existe o risco de fornecer ao usuário um aplicativo que conterá um erro crítico. Tivemos sorte, conseguimos identificar esse problema durante o teste da versão alfa do projeto. Mas o erro pode facilmente entrar em produção, pois não aparece durante o teste local ou na criação do arquivo APK.Otimizando recursos de aplicativos usando o Android Size Analyzer
A próxima sugestão para otimizar aplicativos que encontramos na documentação foi o uso do Android Size Analyzer . Esta é uma ferramenta de linha de comando que analisa aplicativos Android e procura maneiras de reduzir seu tamanho. Lançamos essa ferramenta usando um comando do seguinte formulário:size-analyzer check-bundle [BUNDLE].aab
Como resultado, obtivemos uma lista de excelentes recursos e imagens de aplicativos que podemos otimizar. Também nos foi recomendado configurar o ProGuard.Relatório do analisador de tamanhoGuProGuard
O ProGuard é uma ferramenta para compactar, ofuscar e otimizar o bytecode Java. Ainda não exploramos a possibilidade de usar essa ferramenta, pois aprendemos que ela pode não ser compatível com algumas bibliotecas do Android. Como nos esforçamos para reduzir o tamanho de nosso aplicativo o mais rápido possível, e para simplificar o máximo possível, decidimos deixar esse método de otimização no futuro.▍Grandes recursos de aplicativos
Ao executá-lo size-analyzernovamente, com a chave -d, obtemos uma lista de recursos do aplicativo, classificados por tamanho. Como essa ferramenta não sabe exatamente como os usuários trabalham com o aplicativo, nos deu a oportunidade de decidir independentemente quais recursos devem ser removidos e quais devem ser carregados dinamicamente no aplicativo.Lista de grandes recursos de aplicativos classificados por tamanhoO primeiro e maior recurso desta lista foi o pacote configurável React Native JavaScript. Agora não podemos dividir este pacote e carregá-lo dinamicamente. Mas depois pensaremos sobre isso. Mais abaixo na lista estão arquivos de fonte grandes (TTF) e arquivos de imagem (JPG e PNG).Images Imagens desnecessárias
Chamamos nossa atenção imediatamente para as enormes imagens JPG usadas no Storybook . Usamos esse sistema para desenvolver e testar componentes. São 2 MB de lixo que caíram na versão de produção do projeto. Erro vergonhoso! Quando algo assim acontece, sentimos que fizemos alguma estupidez séria. Mas no mundo complexo do desenvolvimento de software, todos cometem erros. Acredito que se você falar publicamente sobre seus erros, isso ajudará outros desenvolvedores a aprender com esses erros. Existe a possibilidade de você cometer os mesmos erros se não analisar a estrutura de recursos do aplicativo, cujo tamanho está aumentando gradualmente.▍ Fontes
Depois que nos livramos rapidamente de imagens desnecessárias, passamos a analisar outros elementos da lista de recursos. Ficou claro que havia muitas fontes internas nele. Depois de conversarmos sobre isso com nossos designers, eles nos disseram que muitos componentes antigos não diferem na aderência estrita aos manuais tipográficos. Portanto, descobrimos quais componentes podem ser removidos e nos quais você pode usar as fontes atualizadas apropriadas. Graças a isso, conseguimos reduzir o número de fontes usadas de seis para quatro.Outra coisa que notamos foi o tamanho dos arquivos de fonte. O tamanho de cada um deles era de aproximadamente 670 Kb. Isso significa que quatro fontes no pacote descompactado ocupam impressionantes 2,7 Mb. Felizmente, porém, existe uma ferramenta chamada FontForge que permite analisar e modificar profundamente os arquivos de fonte. Usando essa ferramenta, descobrimos que o principal motivo do grande tamanho dos arquivos de fonte são caracteres cirílicos estendidos e glifos desnecessários. Nós poderíamos remover tudo isso com segurança, pois a parte do texto do nosso aplicativo está completamente escrita em português. Graças a essa alteração, conseguimos reduzir o tamanho dos arquivos de fonte de 670 Kb para 70 Kb - em 90%.Exemplos de alguns glifos incluídos em nossas fontes:devido ao fato de termos eliminado fontes desnecessárias e otimizado as demais, conseguimos reduzir o tamanho do aplicativo em 3,8 Mb. Isso levou a uma agradável redução no tamanho total do arquivo APK em 2 MB.Lista de fontes e seus tamanhos antes da otimizaçãoLista de fontes e seus tamanhos após otimizaçãoPtOtimização de imagens
Após analisar as imagens que ainda permaneciam no aplicativo, percebemos que algumas são bastante grandes. Processamos várias dessas imagens com a ferramenta de otimização de gráficos TinyPNG e observamos uma redução significativa no tamanho dessas imagens. Depois disso, decidimos otimizar todas as imagens JPG e PNG usadas no aplicativo. Havia 41 deles.Imagem antes e depois da otimizaçãoIsso nos deu a oportunidade de reduzir o tamanho das imagens de 2,5 MB para 756 KB, ou seja, em 70%. No entanto, devido ao fato de as imagens não terem sido otimizadas anteriormente, elas foram compactadas durante a criação do arquivo APK final. Aconteceu que nossa otimização levou a uma redução no tamanho do aplicativo baixado pelo usuário em apenas 500 Kb.Depois disso, percebemos que já tínhamos esgotado todas as possibilidades de otimização rápida. Continuar a otimização de recursos exigiria grandes esforços ou apenas pequenas melhorias.Reagir a otimização de pacote JavaScript nativo
Depois de descobrirmos os recursos do aplicativo específicos para a plataforma Android, é hora de analisar o pacote JavaScript. A otimização de pacotes pode ser considerada uma boa ideia por três razões. Em primeiro lugar, reduz o tamanho do arquivo APK finalizado. Em segundo lugar, isso leva a um lançamento mais rápido do aplicativo, pois a máquina virtual JS precisa processar menos código. Finalmente, e mais importante, ele acelera as atualizações do OTA que fazemos várias vezes por semana usando o CodePush .▍ Analisador de pacotes e otimização de código
Para tomar uma decisão sobre como reduzir o tamanho do pacote configurável, primeiro, você precisa descobrir o que ocupa mais espaço no pacote configurável. Para fazer isso, usamos a excelente ferramenta de código aberto react-native-bundle-visualizer . Após analisar o projeto com sua ajuda, obtivemos uma visualização na qual todas as pastas e todas as dependências de aplicativos estavam presentes, indicando os tamanhos das entidades correspondentes.Instantâneo das bibliotecas e pastas da base de código do front-end do aplicativo Mutual com a indicação dos tamanhosDescobrimos que o tamanho total do pacote configurável é 5,49 Mb. 57,5% desse volume é representado por dependências da pastanode_modules, 27,5% - código do aplicativo. O que resta, a ferramenta usada por nós não pôde ser identificada. Durante o processo de montagem do pacote configurável, o código não utilizado já foi excluído; portanto, o que vimos foi o código que é realmente usado pelo aplicativo. Mas, mesmo considerando isso, no pacote você pode sempre encontrar algo que pode ser aprimorado.A maior dependência do projeto émath.js. Essa biblioteca, como o próprio nome sugere, implementa muitas operações matemáticas. Não temos uma necessidade especial desta biblioteca devido ao fato de realizarmos todos os cálculos importantes no servidor, após o que simplesmente enviamos os resultados para o aplicativo. Quando analisamos o código do aplicativo, verificou-se que a biblioteca é usada apenas para executar algumas operações simples. Provavelmente foi usado por um desenvolvedor que trabalhava no código do servidor apenas em virtude do hábito. Nós rapidamente extraímos os métodos apropriados da biblioteca e os construímos em nossa base de código, eliminando completamente essa dependência. Isso permitiu reduzir o tamanho do pacote para 4,64 Mb. A recusa de apenas uma biblioteca permitiu reduzir o tamanho do pacote em 15,5%!Como já mencionado, usamos o Storybook para desenvolver e testar componentes. É verdade que os recursos correspondentes devem estar disponíveis apenas em ambientes local e intermediário. Os usuários finais não precisam disso. Graças a isso, usamos a variável ENVIRONMENTpara controlar a inclusão da parte correspondente do aplicativo. Embora isso seja adequado para restringir o acesso, o empacotador não pode saber qual valor está gravado nessa variável. Por causa dessa limitação, todo o código do Storybook caiu no pacote de produção.Para corrigir o problema, isolamos a importação desta seção em um único arquivo. Em seguida, criamos duas versões desse arquivo: uma que inclui o Storybook e a outra para produção, que contém apenas o layout do componente. Para alternar entre esses arquivos ao preparar a versão de produção do pacote configurável, escrevemos um script que é executado antes da criação do projeto e alteramos um arquivo para outro. Graças a esse método, conseguimos remover completamente o código do Storybook da versão de produção do aplicativo, removendo a dependência node_modulese o código usual da configuração das “histórias” do Storybook.Pasta Storybook atualizada com duas versões do arquivo deíndice.Estas duas alterações reduziram o tamanho do pacote de 5,49 MB para 4,2 MB. Isso significa que, entre outras coisas, o aplicativo carregará mais rápido e atualizará mais rapidamente.O tamanho do pacote final era de 4,2 MB.Após todas essas melhorias, baixamos novamente o aplicativo na Play Store. Agora fomos informados de que o tamanho do arquivo APK finalizado estará na faixa de 10,5 a 13,7 Mb. Isso, considerando que o aplicativo originalmente tinha um tamanho de 26,8 MB, significa simplesmente uma incrível redução no tamanho do projeto em cerca de 60%! Portanto, como dissemos em um artigo da equipe do Google Play, podemos esperar que a taxa de conversão das instalações aumente em 3,75%.Comparação da versão APK original do aplicativo com a versão final do AAB, na qual são feitas todas as melhorias descritas acimaSumário
Nós, como programadores voltados para negócios, sabemos que, às vezes, as empresas, para o desenvolvimento mais rápido de um projeto, podem muito bem aumentar sua dívida técnica. Isto é especialmente verdade para jovens startups como a Mutual, que estão tentando encontrar seu lugar no mercado. Mas se você não observar essa dívida, poderá cometer erros irritantes, como enviar 2 MB de imagens de teste para produção e uso injustificado de uma enorme biblioteca. Dívidas técnicas não devem ficar fora de controle e causar problemas.Além disso, muitas vezes acontece que os desenvolvedores simplesmente perdem as oportunidades disponíveis para otimizar projetos. Portanto, às vezes é recomendável analisar criticamente seus projetos. Apenas para verificar se você perdeu alguma oportunidade de otimizar rapidamente o tamanho, a velocidade ou algum outro aspecto do aplicativo. Levamos apenas dois dias para analisar a aplicação, planejar o trabalho e fazer melhorias no projeto, o que nos permitiu reduzir o tamanho da aplicação em 60%. É difícil encontrar outra coisa que possa produzir os mesmos resultados em tão pouco tempo.Como você otimiza seus projetos React Native?