È perfettamente possibile, è sufficiente serializzare l'accesso a SQLite nel thread in background.
La mia risposta su this recent question dovrebbe indicare la direzione giusta.
Come accennato altrove, SQLite va bene per letture contemporanee, ma si blocca a livello di database per le scritture. Ciò significa che se stai leggendo e scrivendo in thread diversi, riceverai errori SQLITE_BUSY e SQLITE_LOCKED.
Il modo più semplice per evitare questo è di puntate tutti accesso DB (letture e scritture) o in una coda spedizione o un NSOperationQueue che ha una concorrenza di 1. Poiché questo accesso non sta avvenendo sul thread principale , l'interfaccia utente non sarà interessata.
Questo ovviamente interromperà le letture e le scritture che si sovrappongono, ma fermerà anche le letture simultanee. Non è chiaro se si tratti di un successo nelle prestazioni che puoi prendere o meno.
per inizializzare una coda come descritto in precedenza:
NSOperationQueue *backgroundQueue = [[NSOperationQueue alloc] init];
[backgroundQueue setMaxConcurrentOperationCount:1];
Poi si può semplicemente aggiungere operazioni alla coda, come si vede in forma.
Hai provato a sintonizzare le query che usi e guardando i piani di query per vedere se sono necessari degli indici? –
Stai usando le transazioni quando fai più scritture? Dovresti - fa un'enorme differenza. –
Frederick Cheung: sto usando più di una scrittura e un recupero. Cercherò di vedere se l'indicizzazione sarà d'aiuto, ma ci sono molti record da inserire quindi non credo che l'indicizzazione possa essere d'aiuto. Hot Licks: non sto effettuando transazioni quando si utilizzano più scritture. Dovrei farlo per ogni scrittura nel database usando lo stesso lock? – VTS12