Desenvolvimento

17 ago, 2016

Isso ainda é um app!

Publicidade

ATENÇÃO: o texto a seguir pode conter algumas palavras de baixo calão…

Recentemente recebi em algum lugar as seguintes páginas:

A premissa básica dos dois: você não precisa de uma quantidade gigantesca de Javascript, CSS, tracking, analytics, etc. para fazer um site. Você não precisa de um banner dinâmico gigante, de propagandas e de mais um monte de “conteúdo” que só deixa o site mais pesado, consome a banda/franquia do usuário e não mostra nenhum conteúdo relevante. Isso se tornou um problema tão grande que foram criados os ad-blockers – ferramentas que eliminam propagandas das páginas web e mostram apenas o verdadeiro conteúdo útil. E, mais recentemente, os ad-blockers foram disponibilizados também para dispositivos mobile – o que se tornou um problema para os sites, uma vez que a maior parte deles ganha dinheiro com essas propagandas. Isso levou os sites a desenvolverem soluções anti–add-blocker. E assim segue a vida de gato-e-rato.

Como trabalho com apps para iOS, tenho pensado sobre o assunto. Em tempos de iPhone 6s com câmera com capacidade de filmar em 4K, ainda temos dispositivos com 16GB de armazenamento. Aí o dono do iPhone tem duas opções: desinstalar a maioria dos aplicativos para conseguir tirar algumas fotos, ou não desinstalar e não tirar a foto do almoço da família ou filmar a criança de 2 anos brincando com o filhotinho de cachorro. Acho que esta não é a opção que ele escolhe. O que podemos, então, fazer a respeito? Diminuir nossos apps, é claro!

Fui à caça do tamanho de alguns aplicativos na App Store. Vamos ver o resultado.

Vamos analisar agora alguns aplicativos nacionais:

  • SafraNet – aplicativo do Banco Safra, tem 16MB, mas parece ser apenas uma webview, ou seja, todo o conteúdo como assets está online, sendo baixados sob demanda.
  • Banco do Brasil tem 22MB (pelo que conheço, um dos apps de bancos brasileiros mais integrados com o iOS).
  • Itaú 30 Horas tem 35MB.
  • Nubank – a fintech do momento, tem 40MB.
  • Bradesco tem 65MB – e até onde sei também possui diversas funcionalidades como webviews, assim como o Safra.
  • Banco Original – outro banco que quer funcionar 100% pelo mobile – tem 76MB.

Agora, o real motivo de me preocupar com o tamanho dos apps:

  • Twitter (cliente oficial) tem 126MB.
  • Facebook tem incríveis 214MB.

O quanto de assets o app oficial do Twitter tem a mais que o do Tweetbot pra ser 10x maior? O que um cliente de rede social como o Facebook tem para ser quase maior que dois navegadores e um app de GPS JUNTOS? Um browser embutido ele não tem, já que usa o Safari do sistema…

Inicialmente, a Apple limitava o download de atualizações via 3G/4G para no máximo 50MB. Acima disso, a atualização deveria ser feita via Wi-Fi. Mas recentemente esse limite foi expandido para 100MB. Talvez assim esses apps não lançariam updates tão frequentes e tão grandes… Armazenamento é “barato”. Dados via GSM não.

Desde o iOS 9 temos um conjunto de funcionalidades chamadas App Thinning, composta de 3 tecnologias separadas:

  • App Slicing: em geral, submetemos para a loja pacotes contendo imagens usadas por todos os dispositivos da Apple, mas por que um usuário de iPhone 4s precisa baixar imagens otimizadas o para iPad Pro? Por que o iPad precisa baixar imagens de iPhone? Com essa funcionalidade, isso é evitado separando os conjuntos de imagens para cada dispositivo. Com isso, os outros dispositivos não têm necessidade de baixar aquele conjunto de áudio, vídeo ou imagens.
  • On Demand Resources: Nem todos os recursos – arquivos de áudio e imagens, entre outros – são necessários no momento de abertura do app. Com esse recurso, podemos marcar conjuntos de arquivos que serão baixados apenas quando o usuário chegar a determinada tela. Isso diminui o download inicial, e se o usuário nunca acessar essa funcionalidade do app o conteúdo nunca é baixado. Mas uma vez que o download foi feito, o dispositivo acessa diretamente, sem ter que refazer o download – diferente de um cache, que pode ser limpo e exigir re-download.
  • BitCode: ao submeter o aplicativo para a loja, enviamos um pacote com binários compilados para uma representação intermediária do processador. Assim, um usuário com iPhone 4s – e CPU mais antiga – baixa apenas o executável compatível com a sua CPU – gerada sob demanda nos servidores da Apple, sem a necessidade de incluir binários otimizados para o iPad Pro.

Agora podemos ver parte do porquê o Tweetbot é tão pequeno, e o Twitter e Facebook são tão grandes: o Tweetbot é otimizado para iOS 9, usando e abusando do App Thinning. O Facebook ainda mantém suporte para o iOS 7 (se considerarmos que o Facebook tem 1,59 bilhão de usuários, com 65% deles acessando diariamente, e que 2,03% dos usuários do iOS ainda usam versões anteriores do iOS 8, temos possivelmente 21 milhões de usuários de iOS 7 acessando o Facebook diariamente. Dificilmente eles irão descartar o suporte para esses dispositivos, mas isso não justifica um aplicativo tão grande, com atualizações quinzenais. Mesmo com download incremental – outra funcionalidade que facilita download de atualizações –, o app do Facebook tem em média atualizações de aproximadamente 110MB.

Outro ponto importante no tamanho do aplicativo é o uso desenfreado de SDKs de terceiros. Recentemente, conversei com um amigo que trabalha em um aplicativo com umas 5 ou 6 ferramentas diferentes de analytics, porque times diferentes na empresa são acostumados a usar ferramentas diferentes. Aí uma delas estava dando problema, e ele saiu perguntando quem usava aquela ferramenta. Não encontrou ninguém. Alguém no passado disse: “coloca, a ferramenta parece legal, vamos usar” e puft! Ele removeu a ferramenta de analytics, eliminou uma fonte de crashes e ninguém dentro da empresa percebeu. Eu já trabalhei em um app que quase dobrou de tamanho pelo simples fato de passar a usar o Realm como banco de dados, sendo que depois percebi que foi matar mosca com tiro de canhão, pois para aquela funcionalidade um simples SQLite – já embutido no app – ou até mesmo de um pequeno cache (des)arquivando localmente os objetos já seria suficiente.

Mas é só no tamanho do binário que podemos ajudar o usuário? Não! APIs também podem ser muito otimizadas. Recentemente, passei por um cliente de mobile commerce que usava um back-end “pronto”, um produto de uma grande empresa, e tinha uma API desenvolvida por uma empresa terceira. Uma das maiores reclamações dos clientes em relação ao app era a lentidão. Parte inicial do meu trabalho lá foi identificar o que causava isso. Com o Charles Proxy em mãos, fui analisar o tráfego de dados.

A resposta da primeira requisição tinha 64KB. Isso só o JSON, que não incluía as imagens. Essa requisição era feita a cada vez que o usuário exibia a página inicial do aplicativo. Abriu o app: 64KB+ imagens de uns 10 produtos (que também não eram otimizadas). Entrou em um produto, voltou para a página inicial, mais 64KB de resposta (ao menos o app usava uma biblioteca de cache e as imagens não eram baixadas novamente). Para uma lista que deveria conter dados de uns 10 ou 20 produtos, 64KB é MUITO! E tem mais. Ao entrar na página de detalhes do produto – algo que deveria listar os dados necessários para exibir aquela página de detalhes –, a resposta incluía detalhes de mais 18 produtos! Não lembro exatamente o que era, mas era algo como seis produtos de recomendados para o usuário, seis de “quem comprou esse produto que você está vendo também se interessou por esses” e seis de “produtos com vendas bombando!”. Mas não era apenas a lista com as informações mínimas necessárias: nome, tamanho, preço, link da imagem. Eram todos os detalhes de 18 produtos que nem eram exibidos no aplicativo – esses dados só eram úteis para quem acessava via browser – de novo, sem discriminar se era um browser no celular ou no computador.

Esse foi um caso extremo, que deixa o app lento e consome muita franquia – lembrando que ainda tem uma parcela gigantesca no Brasil de pessoas que têm franquias diárias não-cumulativas de 10MB. Mas otimizar as APIs é um passo tão importante quanto otimizar o app – talvez até mais importante, já que o app você só baixa uma vez, mas uma API ruim você consome toda vez que o app é usado.

Assim, lembrando dos dois links no começo do artigo: não é preciso enviar dados desnecessários, imagens desnecessárias, construir APIs ruins, incluir bibliotecas de terceiros e um monte de ferramentas de analytics. Isso ainda é a m***a de um app. ?