Curadoria tech de julho para devs: 5 lições com código

O Manual do Usuário fechou julho de 2026 com uma curadoria que, vista de perto, diz muito sobre onde o ecossistema tech está tropeçando e onde está acertando. Acompanho a casa há anos — é uma das raras referências brasileiras que ainda trata tecnologia como crítica, não como release note. Dessa vez, cinco pautas chamaram minha atenção o suficiente para merecer análise técnica, não só leitura passiva.

Vou destrinchar cada uma delas com o olhar de quem programa para viver, apontando o que o texto original deixou de fora e o que cada tema implica para quem constrói software no dia a dia.

1. “A recusa que virou vitrine” — quando dizer não vira produto

O texto da Cíntia Vitorino, conforme destacado pelo Manual do Usuário, viralizou nos comentários. O motivo é simples: trata-se de uma história em que uma recusa comercial virou argumento de venda. Em produto digital, isso tem nome — chama-se constraint marketing. Funciona porque remove ambiguidade: o cliente sabe exatamente o que está comprando e, mais importante, o que não está.

Na minha experiência construindo SaaS, percebo que times de produto costumam ter pavor de restringir o escopo por medo de perder lead. É o contrário. Uma feature que você se recusa a fazer vira filtro qualitativo — quem entra no funil é porque realmente precisa do resto. O preço da recusa é menor do que o custo cognitivo de manter doze personas diferentes no roadmap e um suporte que sangra.

2. Boox Go 10.3 (gen II) Lumi — E-Ink como ferramenta de trabalho para dev

Esse foi o post que mais me interessou tecnicamente. Um tablet Android com tela E-Ink de 10,3 polegadas, caneta integrada e Android “de verdade” (não a versão capada de outros e-readers). Já testei duas gerações anteriores da Boox como dispositivo de leitura e anotação de documentação. O salto para a linha Lumi, segundo o review original, foi principalmente em contraste e tempo de refresh — dois pontos que matavam a experiência nas gerações antigas.

Para devs, três pontos importam mais que o resto:

• Leitura longa de documentação e PRs extensos: E-Ink cansa muito menos a vista que OLED em sessões de quatro horas ou mais. Aquele diff de 800 linhas no GitHub? Melhor no Boox do que no celular, sem dúvida.
• Android nativo significa sideload de verdade: dá para instalar Termux, Readwise, Notion, Kindle e até apps de remote desktop. Já vi gente usando Boox como segundo monitor via spacedesk.
• Caneta + latência: se a Boox resolveu o ghosting da geração anterior, vira caderno legítimo de arquitetura de software — diagramas C4, fluxos de autenticação, anotações sobre RFCs.

Comparação direta com concorrentes: reMarkable 2 tem a melhor experiência de escrita da categoria, mas trava no ecossistema proprietário e não roda Android. Supernote é mais aberto e tem comunidade ativa, mas hardware mais fraco e refresh pior. iPad com tela nano-texture é caro demais (cinco mil reais fácil) e a sensação de “tinta” não chega perto. Para programador, o Boox Go 10.3 Lumi parece o melhor trade-off atual — se você aguenta o Android da Onyx, que não é exatamente polido e tem bloatware asiático irritante.

3. WhatsApp e a bateria — o que a investigação do Manual está prestes a revelar

Esse é o tipo de pauta que dev sênior lê com lupa. WhatsApp roda foreground service quase permanente em dispositivos Android modernos — webhooks push, mensagens efêmeras, replicação criptografada ponta a ponta, previews de mídia, indexação de busca local. Tudo isso cobra.

Mas a conta de bateria que aparece no sistema operacional raramente explica onde foi o gasto. Quando abro o painel do celular, vejo “WhatsApp: 18%”. Isso é CPU? Rede? Wake locks? Jobs do WorkManager? Serviços em background? O post do Manual promete uma investigação que vai dissecar isso. Espero que usem ADB e dumpsys, porque só assim se separa sinal de ruído.

O problema de fundo é arquitetural: mensageria moderna é um pacote que toca quase todo subsistema do Android ao mesmo tempo. Não existe outro tipo de app com superfície de ataque tão ampla contra a bateria — por design, não por bug.

4. Meta “vandalizada” em Londres — e por que isso interessa a quem desenvolve

O post original faz uma ressalva bem-humorada (“talvez ‘vandalizada’ não tenha sido o termo correto”). O episódio — pichações em anúncios de óculos inteligentes da Meta — é interessante pelo que revela sobre a fricção entre AR/computer vision e espaço público.

Para quem trabalha com visão computacional, há uma lição aqui que costuma passar batido: dispositivos de captura contínua (óculos, câmeras always-on, wearables) serão cada vez mais comuns, e o backlash público não é só moral — é arquitetural. Reguladores europeus já exigem LED físico de gravação. A Meta optou por não colocar. Resultado: picharam o outdoor.

Se você está construindo qualquer produto com câmera persistente, planeje o indicador de gravação antes do lançamento, não depois. Não é detalhe. É o que vai decidir se seu hardware vira mobiliário urbano aceito ou vira alvo de tinta spray na primeira esquina.

5. “Aqui não tem propaganda de bets” — saneamento editorial que devs deveriam copiar

O Manual do Usuário publicou um manifesto curto: não vai exibir anúncios de casas de aposta. Em 2026, isso é posicionamento, não modismo. Bets no Brasil explodiram, contaminaram portais de notícia, drenaram atenção de devs em horário de trabalho (sim, eu sei).

O equivalente técnico disso é o arquivo ads.txt: o arquivo que declara quem tem legitimidade para vender seu inventário publicitário. Publishers sérios revogam domínios fraudulentos, recusam bidders suspeitas, auditam o stack. Quem não faz aceita qualquer lixo programático e depois se pergunta por que o site virou lentidão pura e o Lighthouse caiu quarenta pontos.

Recomendo o mesmo exercício que o Manual fez, traduzido para o lado técnico: liste as redes de ads que você aceita, audite o ads.txt, e corte o que não deveria estar lá. Performance, ética e sinal de marca andam juntos — sempre.

Na Prática: investigando o consumo do WhatsApp com ADB

Enquanto o post do Manual não sai com a investigação completa, dá para começar a própria pesquisa por conta própria. O Android expõe estatísticas detalhadas via dumpsys batterystats — e o segredo está em gerar um relatório HTML interpretável.

Passo a passo no celular conectado via USB com depuração ativada:

1. Resete as estatísticas para começar do zero: adb shell dumpsys batterystats --reset.
2. Use o celular por um dia inteiro, com WhatsApp rodando normalmente, sem mexer nas configurações.
3. Capture o relatório bruto: adb shell dumpsys batterystats > battery.txt.
4. Gere o bugreport para visualizar graficamente: adb bugreport battery.zip e abra o battery.html no navegador.
5. Para cruzar consumo por UID, automatize a leitura com o script abaixo.

import subprocess
import re
from collections import defaultdict

def get_battery_stats():
    result = subprocess.run(
        ['adb', 'shell', 'dumpsys', 'batterystats'],
        capture_output=True, text=True, timeout=30
    )
    return result.stdout

def parse_app_usage(output):
    # Captura UIDs de apps e percentual estimado de consumo
    pattern = re.compile(
        r'u0_a(\d+).*?Estimated.*?(\d+\.?\d*)\s*mAh',
        re.DOTALL
    )
    usage = defaultdict(float)
    for uid, mah in pattern.findall(output):
        usage[f'app_uid_{uid}'] = float(mah)
    return dict(sorted(usage.items(), key=lambda x: -x[1])[:10])

if __name__ == '__main__':
    raw = get_battery_stats()
    top = parse_app_usage(raw)
    for app, mah in top.items():
        print(f'{app}: {mah:.1f} mAh')

O snippet é propositalmente simples para servir de ponto de partida. O ganho real está em rodar a coleta por 24 horas, repetir três dias seguidos, e comparar antes e depois de desativar previews, backups automáticos ou notificações de grupos grandes. Você vai descobrir que o vilão raramente é o app em si — é uma combinação mal-configurada de WorkManager jobs, sockets persistentes e wake locks órfãos.

Erros Comuns que devs cometem ao investigar bateria

• Confiar no gráfico do sistema: o SO arredonda e agrupa por app sem detalhar wake locks. Você precisa de dumpsys, não da UI bonitinha.
• Resetar estatísticas no meio do teste: perde a linha de base. Reset apenas no início, e anote a hora exata.
• Rodar teste só em Wi-Fi: o comportamento muda drasticamente em dados móveis, especialmente em redes 4G/5G instáveis. Documente as condições de rede.
• Ignorar doze horas de standby: bateria em idle é onde apps mal-comportados mais se denunciam — wake locks fantasmas que mantêm o processador acordado sem você perceber.
• Não cruzar com versão do app: se o WhatsApp atualizou no meio do teste, sua amostra está contaminada. Anote versão no início e no fim, sempre.
• Confundir otimização com medição: o erro clássico é desativar cinco features ao mesmo tempo, ver “melhora” de 15%, e não saber qual feature ajudou. Mude uma variável por vez.

FAQ — O que devs perguntam sobre bateria, E-Ink e ads

E-Ink vale a pena para programar ou só para ler documentação?

Para ler documentação, revisar PRs extensos e desenhar diagramas, sim, vale muito. Para editar código, não — a latência de refresh torna a experiência frustrante em qualquer linguagem com indentação relevante. Use E-Ink como segundo dispositivo, não substituto do monitor principal.

Vale a pena desativar o backup do WhatsApp para economizar bateria?

O backup em si consome pouco. O que consome é a constante sincronização com Google Drive em background. Desativar reduz tráfego de rede e wake locks, mas o ganho raramente passa de 3% a 4% ao dia. Meça antes de otimizar — e meça com o script acima, não com achismo.

Por que apps de mensagem drenam mais bateria que outros?

Foreground service persistente + push socket mantido + descriptografia contínua + previews de mídia + notificações em tempo real. É o pacote completo. Nenhum outro tipo de app toca tantos subsistemas do Android ao mesmo tempo, por design de produto. Mensageria é o canário na mina de bateria.

Óculos com câmera sempre ligada são viáveis em 2026?

Do ponto de vista técnico, sim — hardware, bateria e pipeline de CV já comportam. Do ponto de vista regulatório e social, ainda não. Quem desenvolve para esse nicho precisa tratar privacidade como feature central, não como afterthought. O episódio da Meta em Londres é prova disso.

Como bloquear propagandas de bets em sites que visito?

uBlock Origin com listas atualizadas somado a um DNS filtrante (NextDNS, AdGuard Home ou Pi-hole). Mas o problema maior está no ecossistema: enquanto publishers não fizerem a curadoria que o Manual do Usuário fez, parte do lixo passa. Apoie veículos que tratam inventário publicitário como responsabilidade, não só como receita.

📰 Ler a curadoria completa no Manual do Usuário

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto — bateria de Android, E-Ink para devs ou saneamento de stack de ads, escolhe o tema.