Análise de séries históricas em app mobile: como processar dados no celular

Boa parte dos aplicativos que mostram estatística faz a conta no lugar errado. Ou processa
tudo no celular e trava, ou pede tudo ao servidor a cada toque e fica lento. Este texto é
sobre como resolver esse equilíbrio.

O contexto é um app que analisa séries históricas de resultados e apresenta frequências,
tendências e distribuições ao longo do tempo. O problema técnico é genérico e se aplica a
qualquer domínio: finanças, clima, produção agrícola, indicadores de negócio.

O problema

Três requisitos que puxam para lados opostos:

1. A base histórica cresce continuamente e não pode ser reprocessada a cada abertura do app.
2. O usuário quer resposta imediata ao trocar de filtro ou período.
3. O celular médio do público-alvo tem pouca memória e conexão instável.

Fazer o processamento pesado no dispositivo resolve o item 2 e quebra o 3. Fazer tudo no
servidor resolve o 3 e quebra o 2.

A arquitetura que funcionou

Camada 1 — coleta e normalização no servidor

Um serviço em Python coleta os dados brutos, valida e grava em formato normalizado. Aqui
acontece o trabalho sujo: tratamento de formato inconsistente, preenchimento de lacunas,
identificação de duplicidade.

Decisão importante: guardar sempre o dado bruto original, além do tratado. Quando a regra
de normalização muda — e ela muda — dá para reprocessar tudo sem ter perdido nada.

Camada 2 — pré-agregação

Aqui está o ganho de desempenho. Em vez de deixar o app somar milhares de registros, o
servidor mantém tabelas agregadas por período: dia, semana, mês, ano.

A consulta que levaria segundos varrendo a base inteira vira leitura direta de uma linha
pronta. É o mesmo princípio de uma materialized view: troca-se espaço em disco, que é
barato, por tempo de processamento, que é caro.

A pré-agregação roda em job agendado, não em tempo de requisição.

Camada 3 — API enxuta

A API entrega apenas o recorte pedido, já agregado, em JSON compacto. Duas decisões que
importaram:

• Paginação obrigatória. Nenhum endpoint devolve conjunto ilimitado.
• Cache com validade curta. Dados históricos não mudam; só a ponta mais recente muda. Isso
  permite cache agressivo na maior parte da série.

Camada 4 — cache local no dispositivo

O app guarda localmente o que já baixou, em SQLite. Na abertura seguinte, mostra o dado em
cache imediatamente e busca só o incremento em segundo plano.

O usuário vê conteúdo em menos de um segundo, mesmo com conexão ruim. A atualização acontece
sem tela de carregamento.

Camada 5 — cálculo leve no dispositivo

No celular ficam só operações de custo baixo: filtro sobre dados já agregados, ordenação,
cálculo de percentual. Nada de varrer série completa.

A regra prática que adotei: se a operação demora mais de 16 milissegundos, ela não pertence
ao dispositivo — esse é o orçamento de tempo de um quadro a 60 fps, e passar disso gera
travamento visível.

O que aprendi no caminho

Pré-agregar cedo compensa. Foi a decisão de maior impacto. Custa espaço, mas transforma a
experiência.

Cache local não é otimização, é requisito. Em conexão ruim, é a diferença entre app usável
e app abandonado.

Guarde sempre o dado bruto. Você vai querer recalcular com regra diferente. Quem descarta
o original fica preso à primeira decisão.

Estatística exige honestidade na apresentação. Frequência passada é descrição do que já
aconteceu — não previsão do que vai acontecer. Sequências históricas não alteram a
probabilidade de eventos independentes, e apresentar dado de um jeito que sugira o contrário é
enganar o usuário. A interface deve deixar claro que está descrevendo o passado.

Onde isso se aplica

A mesma arquitetura serve para qualquer app que precise mostrar histórico:

• indicadores de vendas e faturamento por período;
• séries climáticas e de produtividade agrícola;
• métricas de saúde acompanhadas ao longo do tempo;
• monitoramento de sensores e telemetria.

O padrão é sempre o mesmo: processar pesado longe do usuário, entregar leve para ele.

Trabalho com desenvolvimento de sistemas e com análise e ciência de dados — da coleta ao
painel. Fale comigo se tiver um projeto de dados.