Como reduzir o tamanho do APK usando Google Play Services

Manter o tamanho do aplicativo pequeno e enxuto é essencial desde a experiência inicial do usuário. Pode ser crucial na decisão de baixar o seu app de 630 MB ou o do concorrente, que possui apenas 80 MB.

Além de tudo, temos a problemática da conexão do usuário que pode estar utilizando o 5G e também ter uma conexão ruim o que causaria uma demora imensa em um app de 630 MB. Esse aumento pode se tornar exponencial quando não existe um cuidado constante em projetos com muitos times trabalhando em paralelo. Cada Pull Request pode adicionar mais 3 MB, depois 5 MB, depois 7 MB… e, ao longo do tempo, perdemos o controle do tamanho final do aplicativo.

Desafio

Atualmente grandes empresas que possuem grandes projetos com diversos times em paralelo buscam cada vez mais soluções para a redução e controle de seus apps e aqui nesse artigo vamos citar uma dessas formas.

O que é o Google Play Services?

O Google Play Services é um conjunto de serviços distribuído pelo aplicativo Google Play Services que já vem instalado na maioria dos dispositivos Android e roda em segundo plano, oferecendo um conjunto de APIs do Google (como Maps, Localização, Autenticação, ML Kit, entre outras) para ajudar você a construir seu app, melhorar privacidade e segurança, engajar usuários e fazer seu negócio crescer.

Onde está a vantagem

O grande ganho aqui é que, como ele já está presente no sistema do usuário, você só precisa adicionar a dependência correspondente no build.gradle do seu módulo para usar a funcionalidade desejada — ao invés de importar um pacote completo (e pesado) de terceiros que faz a mesma coisa “por fora”.

Ou seja: em vez de carregar no seu APK uma lib gigante com toda a lógica embutida, você importa só a “ponte” para o serviço que já está rodando no aparelho, deixando seu APK (ou AAB) menor. E como essas SDKs são modulares, são compatíveis com versões anteriores e sempre atualizadas, você importa só o módulo que realmente precisa (ex: play-services-location, play-services-maps) em vez do pacote monolítico antigo.

Case real

Vim aqui pra trazer um case real e específico sobre um projeto em que atuo no qual fiz uma entrega que realiza análise de imagens e classifica o conteúdo da imagem usando o TensorFlow localmente. Foi aqui que ao fazer os levantamentos do impacto da entrega notei o aumento absurdo de tamanho do APK. O primeiro ganho foi de 4,7 MB devido a um modelo pré treinado que importei no projeto, esse estava no meu radar, mas o que me impressionou foram outros ~15 MB adicionais referente à biblioteca:

• org.tensorflow:tensorflow-lite:2.16.1

Totalizando o aumento seria de ~20 MB para uma só feature nova, estava fora dos padrões que definimos como aceitável. E foi nesse momento em que procurando soluções que resolvessem a questão do TensorFlow que esbarrei com o uso do Google Play Services.

Hands-on

Quebrei os pontos-chave necessários para introduzir o play services no projeto.

Dependências

A parte mais simples alterada foi o import da biblioteca do Google Play Services:

// antes
implementation("org.tensorflow:tensorflow-lite:2.16.1")
// depois
implementation("com.google.android.gms:play-services-tflite-java:16.4.0")
implementation("com.google.android.gms:play-services-tflite-support:16.1.0")

Inicializar o Play Services

O primeiro passo é inicializar a conexão com o módulo do Play Services no nível do processo. É uma operação única que “abre a porta” para o runtime externo ficar disponível. Sem isso, o Play Services não sabe que seu app vai precisar do TFLite:

Tasks.await(TfLite.initialize(context))

o initialize tem que terminar antes de qualquer create( que veremos a seguir), porque o create pressupõe que a conexão com o runtime já está estabelecida.

Buscar a biblioteca e fazer uso dela

Próximo passo é modificar diretamente o código que é usado para realizar a chamada do TFLite ( TensorFlow).

Antes era necessário somente o carregamento do modelo do TFLite considerando que a lib já tenha sido baixada pelo usuário ao realizar o download do APK. Aqui usamos o Interpreter, que utiliza o runtime embarcado no próprio APK:

// antes 
Interpreter(loadModelFile(modelAssetPath))

Agora precisamos mudar alguns pontos, começando pelo uso da interface InterpreterApi. A diferença é que, em vez de utilizar a implementação embarcada no APK, ela utilizará a implementação do TensorFlow disponibilizada pelo Google Play Services:

// depois 
InterpreterApi.create(
      loadModelFile(modelAssetPath), 
      InterpreterApi.Options().setRuntime(TfLiteRuntime.FROM_SYSTEM_ONLY)
)

Paralelismo e tempo de inicialização

Pra encerrarmos, existe um ponto essencial nessa implementação. Note que no início citamos que o TfLite.initialize(context) precisa ser chamado antes do uso concreto do TensorFlow para isso fiz uso do .await em uma coroutine:

withContext(Dispatchers.IO) {
    // Inicializa o runtime do TFLite via Google Play Services antes de qualquer inferência
    Tasks.await(TfLite.initialize(context))
}

withContext(Dispatchers.Default) {
    NsfwTfliteClassifier(context)
.......

Para que somente depois da inicialização da conexão com o Play Services, possamos chamar a classe NsfwTfliteClassifier para usar a biblioteca de fato:

init {
    labels = loadLabels(labelsAssetPath)
    interpreter = InterpreterApi.create(
        loadModelFile(modelAssetPath),
        InterpreterApi.Options().setRuntime(TfLiteRuntime.FROM_SYSTEM_ONLY),
    )
}

E qual o preço no tempo de carregamento?

Esse preço é irrelevante no quesito de impacto na performance, é uma operação leve onde ocorre basicamente um IPC ( comunicação entre processos ), essa operação não realiza download do runtime nem recompila bibliotecas durante a inicialização do aplicativo. Há somente um custo mínimo de latência por ser uma chamada entre processos.

E qual a frequência dessa chamada?

Sempre que um novo processo da aplicação é iniciado, essa chamada deve ser realizada novamente, por ser uma chamada rápida a chance da sua inicialização impactar na experiência é baixa mas vale conferir, caso haja impacto, o carregamento pode ser feito antecipadamente em uma Splash por exemplo.

Papel do Play Services

Nesse case o Google Play Services disponibiliza o runtime do TensorFlow internamente. Com essa dependência, o app não precisa mais empacotar o runtime no próprio APK — em vez disso, faz uma ponte para usar o runtime que já existe no Google Play Services.

Resultado

A diferença entre um APK que utiliza o runtime embarcado e outro que utiliza o Google Play Services foi de 11,9 MB:

Pra ficar mais claro e demonstrar de onde esses valores foram extraídos, criei um pequeno projeto que já está disponível no GitHub e pode ser instalado no seu celular ou emulador ( emulador precisa ter o Google Play Services ).

Você pode verificar isso procurando pelo aplicativo Google Play Services entre os aplicativos instalados no dispositivo.

[embed]GitHub - ApoloRossi/image-classification Contribute to ApoloRossi/image-classification development by creating an account on GitHub.github.com

Conclusão

Empresas com projetos de médio a grande porte se preocupam bastante com este ponto, principalmente levando em consideração times enormes em que cada Pull Request que adiciona 5 MB num ritmo frenético de entrega pode tornar o seu app colossal e impactar na experiência e até na decisão do usuário. E pra você engenheiro, ter essa visão acaba sendo um diferencial que pode impactar na sua carreira.

Espero que os próximos artigos também agreguem valor à sua carreira, seja no mercado nacional ou internacional. Um abraço!

( Se ficou curioso pra saber como eu medi o tamanho dos APKs, coloquem nos comentários que talvez eu faça um artigo sobre )