UITableView endUpdates nimmt sehr lange Zeit in Anspruch, wenn CoreData aktualisiert wird
Ich habe eine Core Data App, die eine große Anzahl von Instanzen in UITableView anzeigt.
Wir haben eine mainQueueContext im Hauptthread und eine privateQueueContext in einem Hintergrundthread.
Wir laden die Daten in UITableView ohne Probleme, aber wenn wir eine aktualisierte Version von der API laden, speichern wir sie in privateQueueContext und verschmelzen sie in mainQueueContext
Es dauert ein paar Sekunden, um den Anruf zu
auszulösen %Vor%Was löst den Aufruf aus:
%Vor%Dann hängt die App und die CPU geht zu 100% und der Speicher beginnt unendlich zu steigen, bis der Speicher aufgebraucht ist. (siehe Bild unten)
Bei weniger als 1000 Elementen tritt dieses Problem nicht auf. Ich habe mich gefragt, ob jemand von euch so etwas gesehen hat.
Bearbeiten
Hier sind einige Daten von Instrumenten
3 Antworten
Eine Verbesserung, die Sie tun können, ist fetchBatchSize .
Von Apple Doc "
Wenn der Abruf ausgeführt wird, wird die gesamte Anfrage ausgewertet und die Identitäten aller übereinstimmenden Objekte aufgezeichnet, aber nicht mehr als Die Daten von batchSize-Objekten werden aus dem persistenten Speicher bei a abgerufen Zeit. Das von der Ausführung der Anfrage zurückgegebene Array ist ein Proxy Objekt, das Chargen auf Anforderung transparent ausfüllt. (In der Datenbank Dies ist ein In-Memory-Cursor.)
Sie können auch fetchLimit und fetchOffset verwenden, um die Paginierung zu implementieren.
Prost, Alessandro
Ich habe dieses Problem auch erlebt. Am Ende sammelte ich alle updated in Array auf% Co_de% Aufnahme Index Pfad, NSFetchedResultsChangeType und Objekt selbst. On controller: didChangeObject: Ich habe gesucht, ob die Anzahl größer als X ist, wenn es dann nur ganze Tabelle neu laden (es ist viel effizienter) und wenn es nicht dann alle Änderungen normal anwenden, als ob es in controllerDidChangeContent: Methode passiert. Es macht einfach keinen Sinn, so viele Zellen einzufügen / löschen / zu verschieben, da der Benutzer die meisten dieser Änderungen sowieso nicht sehen wird.
Ich hoffe, dieser Ansatz wird Ihnen helfen!
Ich hatte ein ähnliches Problem. In meinem Fall bestand die Lösung darin, die Einstellung explizit rowHeight der tableView auf UITableViewAutomaticDimension :
Ich habe stattdessen den Delegierten tableView(_:heightForRowAt:) verwendet
Obwohl die Dokumentation von rowHeight das Gegenteil zu sagen scheint:
Es gibt Leistungseinbußen bei der Verwendung von tableView (: heightForRowAt :) anstelle von rowHeight. Jedes Mal, wenn eine Tabellenansicht angezeigt wird, ruft sie tabletView (: heightForRowAt :) auf dem Delegaten für jede Zeile auf, was zu einem erheblichen Leistungsproblem bei Tabellenansichten mit einer großen Anzahl von Zeilen (ungefähr 1000 oder mehr).
Tags und Links objective-c uitableview ios core-data