Os 6 principais motivos pelos quais os aplicativos para dispositivos móveis falh

  • Mason Williams
  • Avatar de Mason Williams Autor do Tópico
  • Offline
  • JCB! Novato
  • JCB! Novato
Mais
3 anos 5 meses atrás #102911 por Mason Williams
Mason Williams created the topic: Os 6 principais motivos pelos quais os aplicativos para dispositivos móveis falh
As pessoas odeiam quando os aplicativos travam, ou mesmo quando eles ficam lentos ou congelam por alguns segundos. De acordo com uma pesquisa da Dimensional Research, 61 por cento dos usuários esperam que os aplicativos móveis sejam iniciados em quatro segundos, enquanto 49 por cento desejam respostas às entradas em dois segundos. Se um aplicativo travar, travar ou apresentar erros, 53 por cento dos usuários o desinstalarão.

Quer o seu público-alvo sejam os consumidores ou a multidão empresarial, desapontá-los é o caminho rápido para o congelamento. Falei com vários desenvolvedores de dispositivos móveis e perguntei sobre os problemas mais comuns que eles encontraram. Aqui estão seis das principais maneiras pelas quais seu desenvolvimento pode se desviar e deixar seu aplicativo em risco de cair em um precipício de desempenho.

1. Gerenciamento de memória
Uma das maiores áreas de problema de acordo com praticamente todos com quem conversei é o gerenciamento de memória. Um aplicativo pode estar girando muitos threads e absorvendo recursos de memória ou sendo executado em um sistema que tem muitos aplicativos abertos. As pessoas escrevem códigos como se apenas seus aplicativos existissem, diz Sachin Agarwal, vice-presidente de marketing da OpsClarity. Seu software precisa ser um "bom cidadão no ecossistema de aplicativos", diz ele. "Eu vejo alguns aplicativos de notícias e eles estão olhando para quase um gig de dados. Eles estão arquivando notícias do mês passado. Há um nível de cidadania corporativa que precisa surgir nos aplicativos móveis."

Não que o problema seja o mesmo para todos os desenvolvedores. "No iOS, há mais coisas que você pode fazer para aproveitar o Objective-C para lidar com muitos dos problemas de memória", disse Andrew Whiting, vice-presidente de desenvolvimento de negócios da Solstice Mobile. Mas há uma compensação. "No Android, você tem um controle [de memória] muito mais profundo e geralmente pode fazer com que ele faça exatamente o que você quer, o que adiciona complexidade."

"Você entra em coisas [com o Android] como [executar] sem memória em Java, o que normalmente achamos correlacionado com coisas como carregar grandes imagens ou processar bitmaps", diz Jonathan Karon, gerente sênior de engenharia de software da New Relic, que distribui um SDK móvel que informa sobre o desempenho técnico e compilou causas comuns de problemas. "Na verdade, há um número surpreendente de problemas com linker no Android, onde uma classe não pode ser encontrada, ou há uma exceção chamada link não classificado." Por outro lado, os aplicativos iOS costumam sofrer da exceção NSInternalInconsistency, que acontece quando um desenvolvedor altera uma matriz ou coleção de dados em um lugar "enquanto outra coisa está lendo a lista de coisas que estão lá."

2. Ciclo de vida do software
O processo iterativo de desenvolvimento de aplicativos, com sua série constante de lançamentos frequentes, abre portas para chegar ao mercado com um produto mínimo viável e, em seguida, aprimorá-lo com o tempo, construindo um público. Mas a perda do ciclo de vida do software tradicional introduz complicações significativas devido às dependências do sistema operacional e APIs de terceiros.

“Se você olhar as últimas atualizações do Android, os aplicativos travam muito”, diz Agarwal. "O próprio sistema operacional é instável. Ou o sistema operacional é atualizado e o aplicativo não foi atualizado." Ou o usuário não baixa a nova versão. "Você não tem controle e isso se refere a um processo de desenvolvimento central."

O crescimento da computação móvel e em nuvem aumentou o uso de serviços de terceiros e suas APIs associadas, que economizam tempo e ajudam a colocar um aplicativo no mercado mais rapidamente. Mas eles têm seus próprios problemas.

“Muitas das bibliotecas são os denominadores comuns mais baixos”, diz Whiting. "Eles estão tentando resolver os problemas de todos e não estão fazendo uma solução ideal para ninguém." Por exemplo, uma determinada API pode ter uma limitação de desempenho para um determinado aplicativo.

A API também pode usar técnicas que podem ser complicadas, como swizzling de método iOS. Um desenvolvedor altera os mapeamentos de um nome de método para uma implementação, o que permite a modificação do método original quando o código original, como uma API da Apple, não está disponível. “Você poderia chamá-la de uma das 'artes negras' do desenvolvimento de aplicativos iOS”, diz Raman Bhatia, diretor de dispositivos móveis da agência de viagens online Fareportal. "[Mas] se o código do seu aplicativo for escrito de uma determinada maneira, isso pode causar uma falha."

APIs também podem introduzir modificações inesperadas. "Latências de API, taxas de erro, largura de banda de dados, versão da API usada e o número de solicitações de API podem levar a pequenos problemas que se tornam grandes problemas", disse Agarwal. Depois, há a cadeia de dependências para as próprias APIs, que cria a necessidade de ferramentas especializadas para rastrear tudo.

Uma API também pode causar outros problemas, como erros de memória. "Você está apontando para um objeto que já removeu da memória, e isso geralmente não é um problema se você criou todos os objetos porque sabe se pode ou não se referir a ele", diz Long Le, cofundador e desenvolvedor do We Get Fit, um próximo aplicativo de fitness para Apple Watch e iPhone. "O problema acontece quando você traz estruturas de terceiros. Você nunca tem certeza do que eles estão limpando e o que estão criando."

3. Teste inadequado
A necessidade de teste é óbvia, mas obter cobertura adequada, especialmente com a abundância de versões e dispositivos Android, pode ser um desafio. Existem simuladores, mas o software em execução em um servidor pode não apresentar as mesmas limitações de desempenho. shell shockers unblocked

Por exemplo, um thread de um aplicativo pode tentar ler um banco de dados ao mesmo tempo que um segundo thread está tentando modificar o mesmo banco de dados. "É um problema de tempo", disse Wayne Carter, arquiteto-chefe de dispositivos móveis da Couchbase. "Se eles não chegarem no momento exato, o problema não surge. Pode ser encoberto com algo tão simples como uma declaração de log." Um simulador geralmente não exibe as mesmas limitações básicas de desempenho de um dispositivo móvel, então a condição de corrida não é aparente.

Existem serviços que executam emparelhamentos de diferentes dispositivos e variações de sistemas operacionais e os tornam disponíveis, mas isso provavelmente seria mais caro do que um simulador. A escolha torna-se uma troca entre orçamentos e necessidades.

O teste deve ser combinado com benchmarking em relação aos padrões da indústria e às expectativas do usuário para ter certeza de que o que parece aceitável para os desenvolvedores também é aceitável para os usuários. O teste também deve ocorrer em uma base contínua. Monitore o desempenho e procure feedback do usuário sugerindo problemas e, em seguida, corrija o mais rápido possível.

4. Gerenciamento de rede
À medida que os aplicativos dependem cada vez mais do acesso à rede, tanto para dados quanto para serviços de terceiros, o gerenciamento de rede se tornou uma fonte de problemas.

"O motivo mais importante [travamento dos aplicativos] é a capacidade de resposta e o travamento de seu aplicativo quando você está tentando obter alguns dados ou envia algo e está esperando uma resposta", disse Pravin Vazirani, vice-presidente associado de operações for Chetu, uma consultoria de desenvolvimento de software. Pode ser que o desenvolvedor tenha uma boa conexão Wi-Fi, mas o usuário está em uma rede móvel em uma área com recepção ruim.

Uma mudança nas redes, causada pela passagem de 3G para 2G, entrada e saída de elevadores ou perda de recepção é particularmente difícil e pode resultar em pacotes perdidos ou embaralhados. Felizmente, "muitas dessas condições podem ser [modeladas] com alguns cenários", disse Roi Carmel, vice-presidente sênior de produtos e estratégia da empresa de testes de aplicativos móveis Perfecto Mobile.

Uma boa maneira de lidar com um problema de rede é informar o usuário sobre a quebra de conectividade e oferecer, quando possível, a chance de fazer algo que possa ser do seu interesse. Se as pessoas compreenderem a causa do que é uma condição temporária além do controle do aplicativo, é mais provável que permaneçam calmas e não fiquem incomodadas com o software ou o nome da marca associado a ele.

5. Condição de erro e tratamento de exceções
Dadas as complicações do desenvolvimento móvel, alguns erros são inevitáveis, seja uma mudança inesperada de API, um problema de memória que evitou a detecção anterior ou uma condição de rede que encerra a conectividade ou mesmo apenas diminui a velocidade de dados durante a transmissão de arquivos grandes como imagens ou vídeo .

O que se interpõe entre tal situação e uma falha é um bom tratamento de erros e exceções. Dessa forma, um aplicativo não pode ser executado por uma tentativa inesperada de divisão por zero, uma resposta inserida incorretamente de um usuário, uma API que repentinamente começou a fornecer texto como uma resposta em vez de um valor numérico ou a perda temporária de conectividade.

Em qualquer um desses casos, um aplicativo devidamente codificado notará o inesperado e terá uma maneira elegante de encerrar um processo ou atividade enquanto informa o usuário sobre o erro. Pode não ser o ideal, mas se você conseguir manter as linhas de comunicação abertas, há uma chance melhor de manter o usuário.

6. Muito código
Mas talvez o melhor conselho seja manter um aplicativo simples. Forneça a ferramenta de propósito único que as pessoas desejam e use o exercício para codificar apenas o que for necessário. "O melhor e mais livre de bugs é o código que você não escreve", diz Felipe Laso-Marsetti, engenheiro de sistemas sênior da empresa de desenvolvimento móvel corporativo Lextech Global Services.

Você pode criar um aplicativo sem bugs de forma realista, principalmente na primeira rodada? Provavelmente não. No entanto, você pode se concentrar nessas fontes de problemas e fazer o melhor para criar um tratamento de exceção forte para as coisas que podem e irão dar errado. Murphy pode vagar pelo mundo do desenvolvimento de software, mas você pode ter certeza de que ele age o mais levemente possível.

Please Entrar ou Registrar to join the conversation.