Tarefas em segundo plano no desenvolvimento móvel: o que são, tipos e como funcionam

O que são tarefas em segundo plano?

Uma tarefa em segundo plano é qualquer código executado quando o aplicativo não está em primeiro plano (tela ativa). Pode incluir: sincronização periódica de dados com o servidor, download de arquivos grandes, processamento de notificações push, rastreamento de geolocalização, atualização de widgets. Cada plataforma tem suas próprias restrições para trabalho em segundo plano: iOS é mais rigoroso (10–30 minutos de tempo em segundo plano), Android é mais flexível, mas endureceu as regras desde a versão 9.

A arquitetura de tarefas em segundo plano é construída em três níveis: (1) tarefas imediatas — executam agora (Foreground Service); (2) tarefas adiadas — executam em condições adequadas (WorkManager, BGTaskScheduler); (3) tarefas periódicas — repetem em intervalo definido. Escolher o nível correto determina se a tarefa será concluída a tempo e se levará à rejeição do aplicativo na loja.

Em ambas as plataformas, Google/Apple recomendam fortemente usar APIs declarativas em vez de gerenciar threads diretamente em segundo plano. WorkManager no Android e BGTaskScheduler no iOS permitem que o sistema distribua otimamente o trabalho em segundo plano entre aplicativos, agrupando tarefas para economizar energia. Na IT Sectr, sempre começamos o design da arquitetura em segundo plano analisando os requisitos de frequência e urgência das atualizações.

Tarefas em segundo plano no iOS (Background Fetch, BGTaskScheduler)

O iOS fornece vários mecanismos para trabalho em segundo plano. Background Fetch — atualização periódica de conteúdo com intervalo determinado pelo sistema (não pelo desenvolvedor). O aplicativo obtém uma janela de ~30 segundos para baixar novos dados. Background Fetch é ativado via Capabilities → Background Modes → Background Fetch e implementado no AppDelegate: application(_:performFetchWithCompletionHandler:).

BGTaskScheduler é a API moderna para iOS 13+, substituindo Background Fetch. O desenvolvedor registra uma tarefa com um identificador, e o sistema a executa quando as condições são adequadas. BGAppRefreshTask — para atualizações curtas de conteúdo; BGProcessingTask — para tarefas longas (limpeza de cache, sincronização de banco de dados). As tarefas são registradas na inicialização do aplicativo, e o sistema agenda sua execução considerando estado da bateria, rede e atividade do usuário.

Background Modes — uma lista de modos que permitem trabalho em segundo plano para cenários específicos: Audio (reprodução em segundo plano), Location (GPS), VoIP (chamadas via PushKit), BLE (conexão a dispositivos Bluetooth), Processing (tarefas longas via BGTaskScheduler). Cada modo requer justificativa durante a revisão da App Store. Usar modos sem necessidade real é uma causa comum de rejeição do aplicativo.

Significant Location Change — um mecanismo para aplicativos que não precisam de geolocalização constante, mas precisam saber sobre movimentos significativos do usuário (mais de 500 metros). O sistema acorda o aplicativo quando a torre de celular muda. Este mecanismo economiza bateria significativamente em comparação com GPS constante.

Tarefas em segundo plano no Android (WorkManager, JobScheduler, Foreground Service)

O Android oferece o conjunto mais rico de APIs para tarefas em segundo plano, mas desde a versão 8.0 (API 26), as regras se tornaram mais rigorosas. WorkManager é a solução recomendada pelo Google para todos os tipos de tarefas em segundo plano. WorkManager garante a execução da tarefa mesmo após reinicialização do dispositivo (via BootReceiver) e suporta cadeias de tarefas, LiveData/Flow observáveis e compatibilidade retroativa até API 14.

WorkManager usa Worker — uma classe base com o método doWork(). Constraints define as condições de execução: NetworkType.CONNECTED, BatteryNotLow, StorageNotLow. PeriodicWorkRequest — para tarefas periódicas com intervalo mínimo de 15 minutos. WorkManager se adapta automaticamente ao Doze Mode e App Standby, agrupando tarefas em janelas de manutenção. Exemplo de um Worker simples:

class SyncWorker(
    context: Context,
    params: WorkerParameters
) : CoroutineWorker(context, params) {

    override suspend fun doWork(): Result {
        return try {
            val repository =
                Injection.provideRepository(applicationContext)
            repository.syncData()
            Result.success()
        } catch (e: Exception) {
            Result.retry()
        }
    }
}

// Запланировать задачу
val constraints = Constraints.Builder()
    .setRequiredNetworkType(NetworkType.CONNECTED)
    .build()

val syncRequest = OneTimeWorkRequestBuilder<SyncWorker>()
    .setConstraints(constraints)
    .build()

WorkManager.getInstance(context)
    .enqueue(syncRequest)

JobScheduler — uma API mais antiga (Android 5+, API 21). Agenda tarefas com condições especificadas (rede, carregamento, inatividade). Limitação: não suporta reinicialização do dispositivo (precisa de BootReceiver) e não tem estado observável. JobScheduler é adequado para tarefas simples em projetos legados; para novos projetos, use WorkManager.

Foreground Service — um serviço que o usuário vê através de uma notificação persistente (ongoing notification). Usado para: reprodução de música, rastreamento GPS, download de arquivos grandes. Foreground Service tem alta prioridade — o sistema não o matará quando faltar memória. A partir do Android 13, é necessária a permissão FOREGROUND_SERVICE_SPECIAL_USE para alguns tipos. Uma alternativa é WorkManager com ForegroundServiceOption (tarefas longas).

AlarmManager — para tarefas que devem ser executadas em horário exato (alarme, lembrete). AlarmManager pode acordar o dispositivo do Doze Mode (setAlarmClock). Não é recomendado para sincronização regular devido ao alto consumo de energia. Para tarefas periódicas, use WorkManager, e AlarmManager apenas quando o horário exato for crítico.

Doze Mode e App Standby

Doze Mode é um modo de economia de energia no Android que afeta a execução de tarefas em segundo plano. Introduzido no Android 6.0 (API 23). Quando o dispositivo não está carregando, a tela está desligada e o dispositivo está parado, o Doze Mode bloqueia solicitações de rede, adia JobScheduler e WakeLock. Periodicamente, o Doze abre janelas de manutenção — intervalos curtos em que os aplicativos podem executar tarefas adiadas. Desde o Android 7.0 (API 24), o Doze é ativado quando a tela está desligada, não apenas quando completamente parado.

App Standby — um modo em que aplicativos não utilizados são colocados em espera. Se um aplicativo não tem notificação ativa e não foi aberto por vários dias, ele é colocado em um Standby Bucket: ativo (active), working, frequent, rare. Quanto menos o aplicativo é usado, mais rigorosas são as restrições: solicitações de rede são adiadas, sincronização é bloqueada, JobScheduler não executa.

WakeLock — um mecanismo que mantém o dispositivo ativo (impede que durma). Usado para concluir operações importantes. WakeLock deve ser liberado após a conclusão da tarefa, caso contrário a bateria se esgotará em algumas horas. WakeLock não funciona no Doze Mode — o sistema o ignora. Trabalhar com WakeLock no Android 8+ requer a permissão WAKE_LOCK e gerenciamento adequado do ciclo de vida.

Na IT Sectr, consideramos o Doze Mode e o App Standby na fase de design. WorkManager lida automaticamente com esses modos, mas para Foreground Service é necessário planejar o tratamento correto das transições para Doze. Recomenda-se testar o trabalho em segundo plano em dispositivos reais com o modo de economia de energia ativado e após períodos prolongados de inatividade.

Dicas práticas

Ao projetar tarefas em segundo plano, siga estas dicas. 1. Sempre use WorkManager para novos projetos Android. Ele resolve problemas de compatibilidade, Doze Mode e reinicialização do dispositivo. 2. No iOS, prefira BGTaskScheduler em vez de Background Fetch para iOS 13+. 3. Use Foreground Service apenas quando a tarefa realmente exigir uma notificação visível. 4. Não abuse do WakeLock — isso esgota a bateria e pode levar à rejeição do aplicativo. 5. Teste tarefas em segundo plano no Doze Mode: adb shell dumpsys deviceidle force-idle. 6. Sempre verifique a conclusão da tarefa através de registro e análises. 7. Lembre-se dos limites: iOS dá ~30 segundos para Background Fetch e ~alguns minutos para BGProcessingTask. Android WorkManager não garante tempo exato de execução.