Participe do evento ⁠#Android11: apresentação de lançamento da versão Beta no dia 3 de junho.

Guia para o processamento em segundo plano

Cada app para Android tem uma linha de execução principal encarregada de gerenciar a IU (inclusive medir e desenhar visualizações), coordenar interações de usuários e receber eventos de ciclo de vida. Se houver muito trabalho nessa linha de execução, o app poderá travar ou ficar mais lento, levando a uma experiência de usuário indesejável. Qualquer cálculo e operação de longa duração, como decodificar bitmaps, acessar o disco ou executar solicitações de rede, precisa ser feito em uma linha de execução separada em segundo plano. Em geral, tudo que leve mais do que alguns milissegundos precisa ser delegado a uma linha de execução em segundo plano. Pode ser necessário que algumas tarefas sejam realizadas enquanto o usuário interage ativamente com o app. Para saber como executar tarefas em linhas de execução em segundo plano e fora da linha de execução de IU principal enquanto o app está sendo usado ativamente, consulte o guia de soluções da linha de execução.

Os aplicativos também podem exigir que algumas tarefas sejam executadas mesmo quando o usuário não estiver usando ativamente o app, como sincronização periódica com um servidor de back-end ou busca constante por novos conteúdos em um app. Os aplicativos também podem exigir que os serviços sejam executados imediatamente após a conclusão, mesmo depois que o usuário tiver concluído a interação com o app. Este guia ajudará você a saber qual solução atende melhor às suas necessidades nesses casos de uso.

Desafios no processamento em segundo plano

As tarefas em segundo plano consomem os recursos limitados de um dispositivo, como a memória RAM e a bateria. Se isso não for feito corretamente, pode resultar em uma experiência ruim para o usuário.

Para maximizar a bateria e aplicar um bom comportamento ao app, o Android restringe o trabalho em segundo plano quando o app, ou uma notificação de serviço em primeiro plano, não está visível para o usuário.

  • O Android 6.0 (API de nível 23) introduziu o Modo "Soneca" e o "App em espera". O "Soneca" restringe o comportamento do app quando a tela está desligada e o dispositivo está parado. O "App em espera" coloca os aplicativos fora de uso em um estado especial que restringe o acesso à rede, às tarefas e às sincronizações.
  • O Android 7.0 (API de nível 24) limitou as transmissões implícitas e introduziu o Modo soneca em movimento.
  • O Android 8.0 (API de nível 26) limitou ainda mais o comportamento em segundo plano, como recebimento de localização em segundo plano e liberação de wakelocks armazenados em cache.
  • O Android 9 (API de nível 28) introduziu os App Standby Buckets, em que as solicitações de recursos do app são priorizadas dinamicamente com base nos padrões de uso dele.

É importante entender as necessidades da tarefa e escolher a solução correta obedecendo às práticas recomendadas do sistema ao programar o job em segundo plano.

Como escolher a solução correta para seu trabalho

  • O trabalho pode ser adiado ou precisa acontecer imediatamente? Por exemplo, se você precisar coletar alguns dados da rede em resposta ao clique do usuário em um botão, esse trabalho precisará ser feito imediatamente. No entanto, se você quiser fazer upload dos registros para o servidor, esse trabalho poderá ser adiado sem afetar o desempenho do app ou as expectativas do usuário.

  • O trabalho depende das condições do sistema? Você pode querer que seu job seja executado somente quando o dispositivo atender a determinadas condições, como estar conectado à energia, ter conexão de Internet etc. Por exemplo, seu app pode precisar compactar periodicamente os dados armazenados. Para evitar que o usuário seja afetado, recomendamos que esse job aconteça apenas quando o dispositivo estiver carregando e ocioso.

  • O job precisa ser executado em um horário específico? Um app de agenda pode permitir que um usuário configure um lembrete para um evento em um horário específico. O usuário espera ver a notificação de lembrete nesse horário. Em outros casos, o app pode não se importar exatamente com quando o job será executado. O app pode ter requisitos gerais, como "O job A precisa ser executado primeiro, depois vêm o job B e o C", mas ele não exige que os jobs sejam executados em um horário específico.

Figura 1. Qual é a melhor maneira de trabalhar em segundo plano?

WorkManager

Para trabalhos que possam ser adiados e executados mesmo se o dispositivo ou aplicativo for reiniciado, use o WorkManager. O WorkManager é uma biblioteca do Android que executa o trabalho de segundo plano adiável quando as condições do trabalho (como disponibilidade de rede e energia) são satisfeitas.

O WorkManager oferece uma API de compatibilidade com versões anteriores (API de nível 14 ou posterior) que aproveita a API JobScheduler (API de nível 23) e versões posteriores para ajudar a otimizar a duração da bateria e os jobs em lote, além de uma combinação de AlarmManager e BroadcastReceiver em dispositivos anteriores.

Serviços de primeiro plano

Para o trabalho iniciado pelo usuário que precisa ser executado imediatamente até o fim, use um serviço em primeiro plano. Usar um serviço em primeiro plano informa ao sistema que o app está fazendo algo importante que não pode ser eliminado. Os serviços em primeiro plano ficam visíveis para os usuários por meio de uma notificação não dispensável na bandeja de notificações.

AlarmManager

Se você precisar executar um job em um horário específico, use o AlarmManager. O AlarmManager inicia seu app, se necessário, para fazer o job no horário especificado. No entanto, se o job não precisar ser executado em um horário específico, o WorkManager é uma opção melhor. O WorkManager consegue equilibrar melhor os recursos do sistema. Por exemplo, se você precisar executar um job a cada hora, mas não precisar que ele seja executado em um horário específico, use o WorkManager para configurar o job recorrente.

DownloadManager

Se o app estiver realizando downloads HTTP de longa duração, use o DownloadManager. Os clientes podem solicitar o download de um URI para um arquivo de destino específico que pode estar fora do processo do app. O Gerenciador de downloads realizará o download em segundo plano, cuidando das interações HTTP e tentando refazer os downloads após falhas ou em todas as mudanças de conectividade e reinicializações do sistema.