Simplificando Analytics com Kotlin no Android! — Part 2 Reportando Crashes da Aplicação
Objetivos
Ser capaz de rastrear travamentos no Android e reunir as métricas abaixo:
- Sessões afetadas: é a porcentagem de separação em que houve pelo menos uma falha. Uma sessão diária se ajusta a um dia em que o aplicativo foi usado. Por exemplo, se ambos os usuários usarem o aplicativo por dois dias, quatro serão eliminados.
- Sessões sem falhas: é o percentual de separação em que os usuários não foram afetados por falhas. Uma sessão diária se ajusta a um dia em que o aplicativo foi usado.
- Número de conexões: é o número aproximado de combinações estabelecidas.
- Limite de mau comportamento: se o aplicativo tiver uma taxa de acerto igual ou superior ao limite, ele está entre os últimos 25% dos 1.000 principais aplicativos do Google Play (em número de instalações).
Introdução
No post anterior, tentei compartilhar algumas ideias que me ajudaram no passado, mas algumas coisas foram deixadas de fora do post para não torná-lo muito grande.
Então, decidi criar uma pequena série de postagens que cobrisse alguns pontos problemáticos e as soluções para eles que encontrei durante minha carreira, sendo um deles , como as ferramentas de relatório de travamento funcionam e como coletar esses dados de maneira eficiente.
Para esse trabalho hercúleo, você pode precisar de uma ferramenta que sintetize uma avalanche de travamentos em uma lista gerenciável de problemas, forneça informações contextuais e destaque a gravidade e prevalência de travamentos para que você possa identificar a causa raiz mais rapidamente.
Resolver travamentos pode ser difícil. No entanto, se você puder identificar a causa raiz da falha, provavelmente poderá encontrar uma solução para ela.
Muitas situações podem causar uma falha em seu aplicativo. Alguns motivos são óbvios, como verificar um valor nulo ou string vazia, mas outros são mais sutis, como passar argumentos inválidos para uma API ou até mesmo interações multithread complexas.
Falhas no Android produzem um rastreamento de pilha, que é um instantâneo da sequência de funções aninhadas chamadas em seu programa até o momento em que ele travou.
A recomendação do Google é integrar o SDK do Firebase Crashlytics e também usar o Android Vitals, onde pode visualizar rastreamentos de pilha de falhas.
Por exemplo, o Android vitals considera travamentos excessivos quando um aplicativo:
* Exibe pelo menos uma falha em pelo menos 1,09% de suas sessões diárias.
* Exibe duas ou mais falhas em pelo menos 0,18% de suas sessões diárias.
Uma sessão diária se refere a um dia em que seu aplicativo foi usado
É digno de nota que existem algumas soluções disponíveis e eu o aconselho a não reinventar a roda sozinho.
No entanto, fique atento aos conceitos descritos aqui, que podem ajudá-lo a pensar fora da caixa e talvez escolher o mais adequado para você ou ser capaz de identificar problemas mais rapidamente ou até mesmo ser capaz de coletar esses dados para seu próprio data lake ajudando toda a sua tribo a melhorar suas soluções existentes.
This is the way!
Para ser capaz de capturar exceções, precisamos criar uma implementação da interface UncaughtExceptionHandler.
Usando a abstração criada na postagem anterior, podemos conseguir algo assim:
Observe o uncaughtException (thread: Thread, throwable: Throwable) implementado abaixo
Agora você só precisa adicionar nosso kit de relatório de travamento à lista de rastreadores na inicialização do analítico dentro da classe estendida do aplicativo.
Lance uma exceção!
Simule um crash!!
Verifique logcat !!!
Conclusão
Sua infraestrutura de relatórios de falhas se torna uma ferramenta valiosa para a equipe interna: onde falhas de aplicativos podem ser triadas e relatórios de falhas de QA ou CI detalhados são organizados para quando os bugs chegam às mesas dos desenvolvedores.
Quando combinado com o teste de dispositivo automatizados, você tem um excelente começo na reprodução de problemas marginais que, de outra forma, levariam a usuários frustrados e avaliações de uma estrela.
Gosta da biblioteca? veja meu perfil e me dê um aplauso no meio e uma estrela no GitHub. :)
https://www.linkedin.com/in/williamgouvea/
Por último, mas não menos importante, comentários / sugestões são bem-vindos, como sempre. Continue aprendendo e compartilhando!
Referências
Série de blogs do Bugsnag sobre como lidar com exceções
- Part 1: how exceptions work for JVM and Android apps
- Part 2: implementing an UncaughtExceptionHandler in a JVM app
- Part 3: sending crash reports to an error reporting API
- Part 4: capturing non-fatal Android errors
- Part 5: handling obfuscation and minification in Android crash reports
- Part 6: adding useful metadata to crash reports
- Part 7: capturing signals and exceptions in Android NDK apps
