Background task no app: o que roda, o que nao roda e como sincronizar sem prometer milagre

Quase todo app corporativo mobile encontra cedo a mesma pressao: "da para sincronizar sozinho em background?", "da para atualizar a fila sem o usuario abrir a tela?", "da para mandar tudo quando a internet voltar?". A resposta curta e desconfortavel: da para fazer parte disso, mas nao do jeito magico que muita especificacao imagina.

Em mobile, o sistema operacional manda mais do que o desenvolvedor. Bateria, rede, politicas de plataforma, aparelho real e comportamento do usuario definem quando uma tarefa pode rodar. Quando o time ignora isso, promete sincronizacao imediata, perde previsibilidade e transforma o suporte em adivinhacao.

Este guia organiza um caminho mais maduro para React Native com Expo: entender o que realmente pode rodar em background, como ligar isso a fila local e a API e como evitar promessas que o sistema operacional nunca assinou.

1. Background task e trabalho diferido, nao automacao instantanea

A documentacao do Expo BackgroundTask define a ideia central com bastante clareza: uma background task e uma unidade de trabalho diferivel, executada fora do ciclo normal da aplicacao, com foco em otimizar bateria e consumo do dispositivo. A mesma referencia explica que a biblioteca usa WorkManager no Android, BGTaskScheduler no iOS e expo-task-manager para executar tarefas JavaScript.

Isso muda a conversa desde o inicio. Background task nao e "rode agora em silencio sempre que eu quiser". E "rode quando o sistema permitir, em uma janela que faca sentido para o aparelho e para a plataforma".

Exemplos de uso saudavel:

• reprocessar uma fila pequena de acoes pendentes;
• fazer refresh leve de conteudo local;
• consultar se existe update compativel para aplicar depois;
• buscar metadados simples que deixam a proxima abertura mais pronta;
• finalizar pendencias pequenas que nao precisam da tela aberta.

Quando o time entende isso cedo, o app deixa de prometer milagre e passa a desenhar comportamento realista.

2. Nem tudo que parece fundo de tela deve ir para background

Um erro comum e empurrar qualquer incomodo de UX para "rodar em background". Nem toda tarefa deve sair da frente do usuario.

Normalmente nao vale prometer background para:

• fluxo que depende de confirmacao imediata do usuario;
• aprovacao irreversivel ou financeira;
• upload pesado que precisa de transparencia operacional maior;
• sequencia longa com varias chamadas que ainda exigem contexto humano;
• qualquer acao cujo atraso sem prazo claro quebraria a expectativa do negocio.

Nesses casos, e melhor assumir interface explicita, status visivel e retomada controlada do que fingir que o sistema vai concluir tudo sozinho.

3. AppState e background task resolvem problemas diferentes

A documentacao do React Native AppState explica que a API informa quando o app esta active, background ou inactive, alem de expor eventos como change, focus e blur no Android. Isso ajuda a decidir o comportamento da interface e da sessao quando a pessoa sai e volta do app.

Ja a background task existe para trabalho diferido fora do ciclo da tela. As duas coisas se complementam, mas nao devem ser confundidas:

• AppState ajuda a tratar retorno ao foreground, bloqueio local, refresh visual e retomada de fluxo;
• Background task ajuda a executar trabalho eventual quando o app nao esta ativo.

Se o projeto mistura essas responsabilidades, acaba pedindo reautenticacao no lugar errado ou tentando usar AppState para simular agendamento real de segundo plano.

4. O sistema operacional escolhe a hora, nao o seu backlog

A referencia do Expo BackgroundTask e bem direta: a tarefa pode nao rodar imediatamente depois do agendamento. Ela rodara em algum momento futuro se o sistema decidir que as condicoes estao adequadas. A mesma documentacao reforca que rede disponivel e bateria suficiente fazem parte dessas condicoes.

Em outras palavras:

• voce pode sugerir um intervalo minimo;
• voce nao controla o minuto exato;
• o sistema pode adiar bastante;
• a tarefa pode simplesmente nao rodar quando as condicoes nao ajudam.

Essa restricao nao e bug. E parte do contrato da plataforma. O app precisa ser desenhado para continuar coerente mesmo quando a execucao atrasar.

5. Android e iOS tem ritmos diferentes em background

Segundo a documentacao da Expo, o Android usa WorkManager e aceita intervalo minimo de 15 minutos para execucao. Ainda assim, o trabalho roda apenas em algum momento depois desse prazo, de acordo com as condicoes do sistema. No iOS, o BGTaskScheduler decide a melhor hora observando bateria, rede e padroes de uso; intervalos curtos podem ser ignorados e a plataforma frequentemente empurra esse trabalho para janelas mais favoraveis, inclusive periodos como a noite.

Isso tem impacto pratico: nao faz sentido vender o mesmo SLA de background para Android e iOS como se ambos obedecessem o seu cronograma. O desenho maduro assume comportamento assinado pelo sistema, nao pelo desejo do time.

6. Se o usuario matar o app, seu plano muda

A documentacao do Expo BackgroundTask tambem deixa claro que tarefas em segundo plano param se o usuario matar o app. Quando o app e reiniciado, as tarefas podem voltar a existir; se o sistema matar o processo ou o aparelho reiniciar, elas podem ser retomadas. A propria referencia ainda lembra que, no iOS, deslizar o app para fora do switcher efetivamente o encerra, enquanto no Android isso varia por fabricante.

Traducao operacional: fila local importante precisa sobreviver sem depender da fantasia de que a tarefa sempre rodara logo depois. O app deve conseguir retomar a pendencia quando o usuario abrir novamente, sem perder contexto e sem mentir sobre o que ja foi sincronizado.

7. TaskManager entra na arquitetura, nao apenas no snippet

A documentacao do Expo TaskManager explica que a biblioteca da suporte a tarefas de longa duracao, especialmente as que podem rodar em background, e que outras bibliotecas do ecossistema a usam por baixo dos panos. A mesma referencia destaca um detalhe que vira erro facil em projeto real: TaskManager.defineTask precisa ser chamado em escopo de modulo, fora do componente React. Em projetos com Expo Router, a propria documentacao recomenda mover isso para um arquivo separado e importa-lo no layout raiz para registrar a tarefa antes da navegacao.

Esse ponto parece pequeno, mas e arquitetural. Se o registro da task fica perdido dentro de uma tela, o app funciona no fluxo feliz e falha justamente quando a execucao de background precisa encontrar aquela definicao sem depender da interface atual.

8. Uma fila boa em background processa lotes pequenos e idempotentes

Background task combina muito bem com fila local, desde que a fila tenha disciplina. O artigo offline, fila e sincronizacao com API ja explica a importancia de status, tentativas e idempotencia. Em background, isso fica ainda mais serio.

Uma tarefa madura costuma:

• pegar poucos itens por execucao;
• respeitar prioridade e tipo da acao;
• registrar sucesso, falha e retry de forma rastreavel;
• parar cedo se a rede ou o estado da sessao nao ajudam;
• evitar repeticao destrutiva quando o mesmo comando volta.

Sem esse desenho, o app transforma a janela de background em corrida de chamadas, gasto de bateria e duplicidade de efeito no backend.

9. O backend precisa colaborar com sincronizacao diferida

Quando o app tenta concluir trabalho fora da tela, a API precisa responder como parceira dessa arquitetura. Isso pede pelo menos:

• endpoints idempotentes ou identificadores de operacao;
• erros que diferenciem retry automatico de revisao manual;
• respostas pequenas e objetivas para caberem bem na janela disponivel;
• estado de sessao previsivel para fila pausada ou retomada;
• telemetria minima por versao e dispositivo.

Essa costura continua muito ligada ao checklist de API REST. Em app corporativo, background task sem contrato de API vira apenas um jeito diferente de empilhar falhas.

10. Nao use background para esconder upload pesado sem estrategia

Em teoria, parece bonito dizer que foto, video ou anexo grande "sobe sozinho depois". Na pratica, isso envolve tamanho de arquivo, variacao de rede, expiracao de sessao, cota de bateria e comportamento muito diferente entre plataformas. Para fluxos de anexo, o artigo upload de fotos e anexos no app continua o ponto principal.

Background pode ajudar a retentar ou completar pequenos passos auxiliares. Mas upload pesado ou sensivel costuma precisar de UX clara, indicador visivel e retomada consciente, nao de invisibilidade total.

11. Menos tarefas costuma ser melhor do que muitas tarefas

A documentacao do Expo BackgroundTask informa que iOS e Android limitam o numero de tarefas agendadas por app e, por isso, a implementacao da Expo usa um unico worker em ambas as plataformas. Ela tambem registra que a ultima task registrada define o intervalo minimo de execucao.

Esse detalhe tem consequencia direta: sair criando varias tarefas independentes para cada miniuso e um caminho ruim. Em geral, vale muito mais ter um worker bem pensado, com um pequeno orquestrador interno de pendencias, do que uma colecao de agendamentos concorrendo entre si.

12. Background task nao e polling sem fim

A referencia do Expo trata minimumInterval como atraso minimo, nao relogio exato. Tambem deixa claro que o sistema tenta minimizar wakeups e preservar bateria. Isso reforca uma regra simples: background task nao deve ser usada como substituto de polling agressivo.

Boas perguntas antes de agendar:

• o dado realmente precisa ser atualizado sem abrir o app?
• ha evento de push ou retorno ao foreground que resolveria isso com menos custo?
• o valor do refresh justifica bateria, rede e complexidade?
• esse trabalho ainda faz sentido se rodar com atraso?

Se a resposta final for "nao", talvez a solucao certa seja carregar melhor o app quando ele volta, e nao insistir em atividade escondida.

13. Teste em aparelho real e use as ferramentas certas

A documentacao do Expo BackgroundTask diz que a API de tarefas em background no iOS nao esta disponivel no simulador e so funciona em dispositivo fisico. A mesma referencia mostra a funcao triggerTaskWorkerForTestingAsync() para desenvolvimento e explica que, no Android, voce pode inspecionar jobs com adb. Ela tambem ressalta que esse disparo de teste nao funciona em builds de producao.

Resumo pragmatico:

• teste em aparelho real;
• valide comportamento com app em background de verdade;
• use o trigger de dev para acelerar repeticao local;
• nao confunda teste de debug com garantia de comportamento em producao.

Esse ponto conversa bem com development build e EAS Build, porque muito time tenta validar background serio no ambiente errado.

14. Observabilidade precisa mostrar se a tarefa ajudou ou so complicou

Quando uma tarefa roda sem tela, o diagnostico fica mais dificil. Vale acompanhar pelo menos:

• quantas execucoes aconteceram por versao e plataforma;
• quanto da fila foi realmente processado;
• quantas falhas vieram de rede, sessao ou contrato de API;
• quantos itens continuaram pendentes na abertura seguinte;
• quanto retrabalho humano foi evitado de fato.

O artigo observabilidade do app em producao ajuda a fechar esse ciclo. Sem telemetria, background task vira boato tecnico: parece estar la, mas ninguem sabe quando rodou nem se ajudou.

15. Checklist rapido para um desenho mais honesto

1. Definir que trabalho e realmente diferivel.
2. Separar AppState de agendamento real em background.
3. Assumir que a plataforma decide o horario, nao a especificacao.
4. Projetar fila local pequena, rastreavel e idempotente.
5. Evitar upload pesado e fluxo irreversivel como promessas invisiveis.
6. Registrar a task em escopo de modulo, nao dentro da tela.
7. Concentrar o trabalho em um worker simples, em vez de varios concorrentes.
8. Testar em aparelho real e com app realmente fora da frente.
9. Medir sucesso, falha e atraso por plataforma.
10. Explicar ao negocio que background e janela oportunista, nao prazo garantido.

16. Erros comuns

• prometer sincronizacao instantanea sem controle do sistema;
• usar background para esconder fluxo mal resolvido na interface;
• misturar AppState com scheduler real;
• registrar task no lugar errado e depender da tela aberta;
• tentar processar lote grande demais em uma execucao curta;
• esquecer que o usuario pode matar o app;
• nao ter idempotencia na API;
• testar so em simulador ou em debug feliz.

17. Quando vale ajuda tecnica

Se a equipe precisa decidir o que vai para fila, o que pode rodar em segundo plano, como tratar rede instavel, como repartir responsabilidade entre app e API e como explicar isso para a operacao, provavelmente o problema ja e de arquitetura, nao de um pacote isolado. Nesse ponto, um diagnostico tecnico ajuda a evitar que o app prometa automacao de fundo onde a plataforma so oferece oportunidade limitada de execucao.

Background task madura nao e a que faz mais coisa escondida. E a que faz poucas coisas certas, no momento em que o sistema permitir, sem mentir para o usuario nem para o negocio.

Referencias editoriais: Expo BackgroundTask, Expo TaskManager e React Native AppState.