Lavoro in background mobile che sopravvive ai limiti OS
· 7 min di lettura
La sync in background non è un daemon eterno. Progettate il lavoro mobile intorno a budget OS, task differibili e outcome visibili che si completano anche quando l'app è congelata.
L'OS possiede l'orologio, non il vostro processo
Le piattaforme mobile moderne sospendono aggressivamente le app per proteggere batteria e privacy. Assumere che un processo background long-lived finisca upload, sync CRM o job IA funziona nel debugger e fallisce sul campo. L'unità durevole di lavoro è un job in coda con vincoli—non la speranza che il processo resti sveglio.
Trattate l'esecuzione in background come un budget scarso concesso sotto condizioni: carica, rete non a consumo, dispositivo idle o wakeup push con finestra breve. Le feature che richiedono certezza—conferma pagamento, consegna messaggio critica—hanno bisogno di un percorso che non dipenda solo dalla sync opportunistica.
Accodare in locale, riconciliare da remoto
Persistete le mutazioni intese sul dispositivo con chiavi di idempotenza prima del round-trip di rete. Quando l'OS sveglia l'app, svuotate la coda sotto i vincoli dichiarati e riconciliate con la verità server. I conflitti appartengono al design di prodotto: last-write-wins è una scelta, non un default che deve sorprendere gli utenti.
Separate il lavoro urgente iniziato dall'utente dalla manutenzione differibile. Una foto appena scattata può meritare un tentativo di upload immediato con progresso visibile. Il refresh notturno di embedding per un indice di ricerca on-device può aspettare Wi-Fi e carica. Mischiare queste priorità brucia batteria e fiducia.
- Usare gli scheduler di piattaforma (WorkManager, BGTaskScheduler) invece di loop forever custom
- Memorizzare payload dei job e metadati di retry in storage locale durevole
- Limitare i retry con jitter; non girare su hard failure
- Mostrare lo stato di sync in UI quando gli outcome utente ne dipendono
Push e brevi wakeup sono feature, non trucchi
Push silenziosi o data possono aprire una breve finestra di esecuzione per sync ad alto valore, ma le piattaforme limitano l'abuso e gli utenti revocano il permesso di notifica. Progettate l'happy path senza push, poi usate il push come accelerazione. Documentate cosa succede se il wakeup non arriva mai.
Per feature mobile assistite da IA—trascrizione, summarization, retrieval—preferite lavoro incrementale on-device con inizio utente esplicito per chiamate cloud costose. L'IA in background che sorprende il contatore batteria diventa una recensione a una stella più in fretta di una cache offline mancante.
Misurate il completamento, non solo l'enqueue
Strumentate età dei job, tasso di successo per set di vincoli, attribuzione batteria dove disponibile e staleness visibile. Una coda che cresce mentre l'app è in background è un allarme precoce che i vincoli sono troppo stretti o i payload troppo grandi.
L'architettura mobile staff accetta i limiti OS come requisiti di prodotto. I sistemi vincenti completano il lavoro che conta per gli utenti entro quei limiti, falliscono rumorosamente quando non possono e non fingono mai che un processo sospeso stia ancora servendo il cliente.
Pubblicato il 6 settembre 2026 da Berktug Berke Ates.