Em novembro de 2016, com a reescrita do aplicativo de passageiros do Uber, fizemos alguns avanços significativos para reduzir nossa taxa de falha e melhorar o tempo de atividade de nossos recursos principais. No entanto, um problema irritante era o encerramento do aplicativo causado por exceções de memória insuficiente (OOM) ou outros motivos difíceis de detectar. Com base em relatos, recebemos relatórios de que o aplicativo não iniciava em situações de pouca memória, particularmente em dispositivos mais antigos. Mas a questão é que tínhamos poucas ferramentas para rastrear essas questões.

Com isso em mente, a Uber Engineering desenvolveu e abriu o seu próprio Startup Reason Reporter. Neste artigo, discutimos a forma como criamos essa poderosa ferramenta para nos ajudar – e a outros – a detectar o motivo de inicialização no iOS e, no processo, criar aplicativos mais confiáveis.

Então… Por que meu aplicativo falhou?

Do ponto de vista do desenvolvedor, detectar uma falha típica no iOS é algo bastante direto. O framework de fundação fornece um callback NSSetUncaughtExceptionHandler, que oferece ao desenvolvedor uma oportunidade de registrar informações sobre exceções não capturadas. Quando um aplicativo é encerrado por outros motivos, no entanto, pode ser muito difícil determinar o que deu errado. Em ambos os casos, a experiência é a mesma: o aplicativo para de funcionar e falha. Buscamos obter mais informações sobre a frequência desses tipos de falhas para determinar como podemos rastreá-las e, por sua vez, preveni-las.

Nossa implementação do Startup Reason Reporter se baseia no processo de eliminação do Facebook para reduzir os eventos OOM descritos no Facebook Engineering Blog. De acordo com esse framework, um lançamento de um novo aplicativo pode ocorrer por uma quantidade limitada de razões, incluindo:

1. O app foi lançado pela primeira vez
2. O app está em desenvolvimento e falhou como parte do debugging
3. O app falhou em uma execução anterior
4. O OS foi atualizado
5. O app foi atualizado
6. O app foi forçado a parar em uma execução anterior
7. O telefone foi iniciado
8. O aplicativo foi encerrado em segundo plano
9. O telefone ficou sem memória e encerrou o aplicativo

Para restringir a lista de possíveis motivos, o Startup Reason Reporter assume que o aplicativo foi lançado pela primeira vez. Em seguida, ele roda através de cada uma dessas possibilidades em sequência, com base em informações salvas do lançamento anterior. Se não pudermos determinar o motivo pelo qual o aplicativo foi lançado a partir dos dados armazenados, assumimos que o app foi encerrado porque o telefone executou OOM.

Persistência de informações executadas anteriormente

Criticamente, o Startup Reason Reporter exige que haja algum tipo de mecanismo de armazenamento para persistir as informações necessárias da execução anterior do aplicativo. Nossa implementação do Startup Reason Reporter permite que você use qualquer mecanismo de armazenamento que você preferir, desde que implemente UBApplicationStartupReasonReporterPriorRunInfoProtocol. Esse protocolo abstrai todas as informações necessárias para determinar o motivo de inicialização, como a versão anterior do aplicativo e se o app foi o último em segundo plano, ou em primeiro plano. Nós fornecemos uma implementação concreta, UBApplicationStartupReasonReporterPriorRunInfo, que é baseada em NSUserDefaults, mas reconhecemos que isso pode não ser apropriado para todos os casos de uso.

Desafios

O Startup Reason Reporter depende muito dos dados disponíveis. Em particular, o sinalizador  previousRunDidCrash deve ser preciso para relatar devidamente os problemas OOM. Em suma, a suposição padrão é de que todas as falhas que não se enquadram nos buckets conhecidos são consideradas eventos OOM. Portanto, se os dados fornecidos forem imprecisos, alguns relatados pelo Startup Reason Reporter podem ser outros problemas. A captura de todas as variantes de falhas está além do escopo desta discussão, mas é importante capturar todos os tipos de falhas, como tempo limite de vigilância, falhas de segmentação e exceções.

Próximos passos

O Startup Reason Reporter é escrito em Objective-C, mas também funciona em Swift. O uso é bastante direto: administre as informações necessárias para uma instância do UBApplicationStartupReasonReporter. Ele tornará o motivo da inicialização disponível através da propriedade startupReason. O resultado pode, então, ser alimentado para o seu pipeline de análise para análise posterior.

Vê algo que deixamos passar ou tem uma ideia de um hack que pode tornar este projeto melhor? Compartilhe suas contribuições no Startup Reason Reporter no GitHub!

Se abordar os desafios de engenharia móvel na escala do Uber é atraente para você, considere fazer parte do nosso time na equipe de iOS.

Para saber mais sobre o desenvolvimento de dispositivos móveis na Uber, confira nossas apresentações do Uber Mobility Meetup, no canal do YouTube da Uber Engineering.

***

Este artigo é do Uber Engineering. Ele foi escrito por Marissa Alvarado-Lima, Stanley Chan, Chris Duarte e Ed Wolf. A tradução foi feita pela Redação iMasters com autorização. Você pode conferir o original em: https://eng.uber.com/uchat/