Xcode: lazy loading von Bildern von den image-Daten in core data
HINWEIS: ich bin mit der ARC
Habe ich eine lazy image loading-Technik, die hervorragend funktioniert, wenn das laden von Bildern von einer web-url. Aber ich habe Probleme beim laden von Bildern, die von core data. Hier ist die Methode, die ich benutze:
Ich zum ersten alloc init meinen mutable arrays, laden meine Daten aus dem core data und dann speichern Sie in einem array. Dann habe ich diesen code:
NSOperationQueue *queue = [NSOperationQueue new];
NSInvocationOperation *operation = [[NSInvocationOperation alloc]
initWithTarget:self
selector:@selector(loadImage)
object:nil];
[queue addOperation:operation];
Und dann...
- (void)loadImage {
for (int i = 0; i < [myArrayFromCoreData count]; i++) {
AnObject *myObject = [myArrayFromCoreData objectAtIndex:i];
UIImage* image;
if ([myObject.image length] == 0) {
image = [UIImage imageNamed:@"default.png"];
}
else {
image = [[UIImage alloc] initWithData:myObject.image];
}
[self performSelectorOnMainThread:@selector(displayImage:) withObject:[NSArray arrayWithObjects:image,myObject.myObjectId, nil] waitUntilDone:NO];
}
}
- (void)displayImage:(NSArray*)array {
[loadedImages setObject:[array objectAtIndex:0] forKey:[array objectAtIndex:1]];
[self.myTable reloadData];
}
Hier gibt es keine Verzögerung und ein NSLog zeigt, dass alle meine Bilder sind Hinzugefügt, um die myObjectLoadedImages array.
Das problem, das ich habe ist, dass es eine Verzögerung beim scrollen der Tabelle angezeigt und es manchmal zu einem Absturz führen. Hier ist der code, den ich benutze, um die Anzeige der geladenen Bilder:
UIImage* image = [loadedImages objectForKey:myObject.myObjectId];
if (image != NULL) {
myImageView.image = image;
}
else {
myImageView.image = [UIImage imageNamed:@"default.png"];
}
Dies ist in der cellForRowAtIndexPath
Methode so es wird jedesmal aufgerufen, wenn die Zelle angezeigt wird. Gibt es etwas, was ich falsch mache hier mein code, der angepasst ist, von einer Klasse, die ist in Ordnung, das laden von Bildern von einer web-url.
Tolle Ratschläge, verwenden Sie ein NSMutableDictionary! Machte es 50% besser. Nun einmal die Bilder einmal geladen, ist es glatt. Aber es ist immer noch langsam, die ersten Bilder sind geladen in der tableviewcell
InformationsquelleAutor Patrick | 2012-08-07
Du musst angemeldet sein, um einen Kommentar abzugeben.
Erster Gedanke - du bist nicht Zwischenspeichern Ihrer UIImages, also sind Sie nicht aus dem Speicher geladen.
Haben Sie versucht,https://github.com/nicklockwood/AsyncImageView/ ?
Meiner Meinung nach ist es die beste Bibliothek für das laden von asynchronen Bilder zu einer Ansicht entweder aus Dokumenten und web. Es unterstützt cache, Fortschritte, Ausblicke und viele, viele Dinge, die einfach den code im Controller.
Haben Sie versucht, Daten aus CoreData als NSData und setzen Sie ihn einfach in UIImage mit AsyncImageView? Ich denke, es ist der einfachste Weg.
Ich bin nicht sicher, wie. Ich habe versucht, diese
AsyncImageView *imageView = (AsyncImageView *)[cell viewWithTag:4]; imageView.image = [UIImage imageWithData:myObject.image];
aber es ist abgestürztInformationsquelleAutor Sebastian Łuczak
so wie ich das verstehe haben Sie die Pfade zu den Bildern in core data und die Bilder anzeigen möchten, die in einer UITableView, richtig ?
Lazy loading-Teil soll voraussichtlich in der
cellForRowAtIndexPath
Methode.Schau mal hier: das laden von Bildern von einem hintergrund-thread mit Blöcken helfen könnte
Grundsätzlich sollten Sie eine
NSFetchedResultsController
ge die Pfade out-of-core-Daten. Er tut alles, caching etc für Sie. Sobald Sie die Pfade, faul laden Sie die Bilder wie gesagt in dem link obennun, Sie wahrscheinlich nicht wollen, um Bilder zu speichern, die größer als -sagen wir - icon-Größe direkt in coreData (oder jede SQLite-Datenbank). Sie könnte erwägen, das schreiben der Bilder auf die disc und lagern Sie nur die Pfade zu den Bildern in core data. Sie sollten bessere Leistung erhalten werden, dadurch, dass
gutes tutorial auf NSFetchedResultsController: raywenderlich.com/999/...
InformationsquelleAutor HeikoG