Guia completo de notificações push em iOS e Android: FCM, APNs, segmentação, deep links e métricas de entrega
Seu app drena a bateria e as avaliações despencam? Você não está só. Este guia prático e atualizado para 2026 mostra como reduzir o consumo de bateria em apps móveis usando profiling de energia, otimizações de rede e tarefas em segundo plano em Android e iOS. Você vai entender o porquê dos picos de consumo, como medi-los com precisão e quais mudanças aplicam ganhos rápidos e sustentáveis, sem comprometer a experiência do usuário.
Consumo de energia em mobile raramente tem um único vilão. É uma soma de pequenas decisões que acendem antenas, mantêm CPUs acordadas e acordam processos sem necessidade. Pense como luzes de uma casa: uma lâmpada esquecida quase não pesa, mas várias acesas a noite inteira fazem a conta explodir. Em apps, o equivalente são requisições de rede frequentes e dispersas, wakeups fora de hora e listeners de sensores que nunca descansam.
O erro clássico é otimizar “no escuro”. Desativar animações ou trocar bibliotecas aleatoriamente raramente resolve. O caminho certo começa pelo profiling de energia, identificando exatamente o que consome, quando consome e em qual contexto (Wi‑Fi vs. celular, tela ligada vs. bloqueada, foreground vs. background).
No Android, o Energy Profiler (Android Studio) é seu painel principal. Rode cenários reais de uso e observe CPU, rede e sensores. Aplique cargas controladas: login, feed, notificações, upload e background. Se picos de rádio aparecem com rajadas de conexões curtas, você tem um padrão de “ping constante” que custa caro em 4G/5G.
Use o Battery Historian com um bugreport para correlacionar wakelocks, jobs, alarms e estado de Doze/App Standby Buckets. Ele revela alarmes exatos disparando de madrugada, work requests sem restrições e foreground services segurando o aparelho acordado. Limitação real: ele exige leitura cuidadosa e cenário bem delimitado; um teste genérico dá ruído e leva a conclusões erradas.
Observe também o Network Profiler para detectar chatty clients: múltiplos GETs para o mesmo recurso, handshakes TLS repetidos, transferências miúdas que impedem o rádio de entrar em estado de repouso.
No iOS, comece pelo Instruments com o Energy Log. Ele indica impacto de CPU, rede, localização e ocioso. Reproduza jornadas reais com a tela bloqueada e rede celular. Integre MetricKit para receber relatórios agregados de energia e eventos de background em produção. Use os diagnósticos de background task da própria plataforma para ver quando o sistema encurta janelas por uso ineficiente.
Limitação prática: o simulador não é referência de energia. Teste em dispositivos reais, com bateria em níveis diferentes e alternando entre Wi‑Fi e celular. Tenha dados antes de mudar o código.
Dica de ouro: registre um trace id por jornada e marque eventos de rede e jobs com esse id. Correlacionar traces no log com o profiler transforma suposição em evidência. Sem correlação, otimização vira loteria.
Rede é o maior ladrão de bateria porque desperta rádios, realiza handshakes e impede estados de economia. O objetivo é reduzir ativações e transferir mais por “lote” quando o rádio já está ativo, aproveitando janelas favoráveis.
Agrupe eventos e envie em janelas temporais (por exemplo, a cada 30–90 segundos) ou por limiar de tamanho (ex.: 50 eventos). Em Android, dispare com WorkManager usando restrições de conectividade não medida quando possível. Em iOS, use BGAppRefreshTask para sincronizações leves e BGProcessingTask para cargas mais pesadas, respeitando as janelas do sistema.
Cuidado: janelas longas demais degradam frescor de dados. Ajuste por tipo de evento. Mensagens de chat não podem esperar; analytics pode.
Habilite ETag e If-None-Match para evitar baixar recursos idênticos. Respeite Cache-Control e aplique camadas locais coerentes: imagens, configurações e catálogos mudam pouco e são perfeitos para cache. Isso reduz bytes e, principal, round-trips.
Erro comum: invalidar todo o cache após login ou troca de idioma sem necessidade. Prefira invalidação granular, por chave e versão de recurso.
Implementar exponential backoff com jitter freia tempestades de tentativas em rede ruim. Detete tipo de rede e economize em celular: adie sincronizações pesadas para Wi‑Fi ou quando em carga. Lembre-se: em redes celulares, o rádio entra e sai de estados de alta potência; várias requisições pequenas espaçadas desperdiçam energia. Batches curtos e coordenados são mais baratos do que “gota a gota”.
Background é onde boas intenções viram vazamentos de energia. O segredo é deixar o sistema orquestrar e declarar intenções de forma honesta. Quando você tenta “forçar” execução contínua, as plataformas reagem com limites e penalidades.
Use WorkManager para trabalho confiável, com constraints claras: conectividade, carregando, ocioso. Agende trabalhos únicos e periódicos com backoff. Evite Foreground Service para tarefas que não são perceptíveis ao usuário; além de aumentar consumo, a plataforma impõe restrições e exige notificações persistentes.
Respeite Doze e App Standby Buckets. Se o usuário raramente abre o app, o sistema corta suas janelas. Planeje fluxos que degradem graciosamente. Alarms exatos devem ser raros; a menos que seu caso de uso seja crítico em tempo, prefira inexact e flex windows para permitir coalescência com outros apps.
Limitação real: forçar wakelocks manuais geralmente piora o consumo e a confiabilidade, porque você concorre com políticas do sistema. Se precisar, segure-os pelo menor tempo possível e sempre com cancelamento garantido.
No iOS, use BackgroundTasks com BGAppRefreshTask para atualizações rápidas e BGProcessingTask quando precisar mais tempo e acesso a recursos como rede e CPU. Declare tarefas, agende-as com bom senso e reporte progresso para ganhar confiança do sistema.
Para uploads/downloads resilientes, prefira URLSession em modo background. O sistema gerencia transferência, retoma e energiza o rádio de forma otimizada. Use notificações com content-available com critério; silenciosas em excesso viram ruído e são limitadas pelo iOS. Se o conteúdo não é urgente, adie para a próxima janela de refresh.
Importante: o iOS ajusta agressivamente o agendamento com base em comportamento passado. Tarefas que frequentemente excedem tempo ou acordam o aparelho sem necessidade tendem a perder prioridade.
Localização em alta precisão contínua é uma das maiores causas de drenagem. Prefira significant-change ou regiões geográficas, e só ative modos precisos no momento de uso. Em Android, Fused Location com intervalos e prioridades corretos evita leituras supérfluas. Em iOS, combine visit monitoring e atualizações adiadas quando possível.
Regra prática: peça o mínimo necessário e por tempo limitado. Explique ao usuário e ofereça controles no app; escolhas conscientes reduzem energia e aumentam confiança.
