Warum gibt eine starke Referenz auf den übergeordneten UIViewController in performBatchUpdates eine Aktivität aus?

Question

Ich habe gerade ein sehr ekliges UIViewController Leck, debuggen, so dass der UIViewController nicht freigegeben wurde auch nach dem Aufruf dismissViewControllerAnimated.

verfolgen ich das Problem mit dem folgenden Code-Block nach unten:

self.dataSource.doNotAllowUpdates = YES; 

    [self.collectionView performBatchUpdates:^{ 
     [self.collectionView reloadItemsAtIndexPaths:@[indexPath]]; 
    } completion:^(BOOL finished) { 
     self.dataSource.doNotAllowUpdates = NO; 
    }]; 

Grundsätzlich, wenn ich einen Anruf zu performBatchUpdates mache und dann sofort dismissViewControllerAnimated rufe, werden die UIViewController durchgesickert und die dealloc Methode dieser UIViewController nie wird angerufen. Der UIViewController bleibt für immer hängen.

Kann jemand dieses Verhalten erklären? Ich nehme an, performBatchUpdates läuft über ein Zeitintervall, sagen wir, 500 ms, so würde ich davon ausgehen, dass nach diesem Intervall, würde diese Methoden aufrufen und dann die Dealloc auslösen.

Das Update scheint dies zu sein:

self.dataSource.doNotAllowUpdates = YES; 

    __weak __typeof(self)weakSelf = self; 

    [self.collectionView performBatchUpdates:^{ 
     __strong __typeof(weakSelf)strongSelf = weakSelf; 

     if (strongSelf) { 
      [strongSelf.collectionView reloadItemsAtIndexPaths:@[indexPath]]; 
     } 
    } completion:^(BOOL finished) { 
     __strong __typeof(weakSelf)strongSelf = weakSelf; 

     if (strongSelf) { 
      strongSelf.dataSource.doNotAllowUpdates = NO; 
     } 
    }]; 

Beachten Sie, dass die BOOL Membervariable, doNotAllowUpdates, ist eine Variable, fügte ich hinzu, dass verhindert jede Art von Datasource/Collection Updates, während ein Anruf zu performBatchUpdates läuft.

Ich suchte online nach Diskussionen darüber, ob wir das weakSelf/strongSelf-Muster in performBatchUpdates verwenden sollten, aber haben nichts speziell zu dieser Frage gefunden.

Ich bin froh, dass ich diesem Bug auf den Grund gehen konnte, aber ich würde einen intelligenteren iOS-Entwickler lieben, der mir dieses Verhalten erklärt, das ich sehe.

Answer 1

Wie Sie herausgefunden haben, wenn weak nicht verwendet wird, wird ein Retain-Zyklus erstellt.

Der Zyklus beibehalten wird durch self verursacht collectionView eine starke Referenz aufweist und collectionView hat jetzt einen starken Bezug auf self.

Man muss immer davon ausgehen, dass self freigegeben sein könnte, bevor ein asynchroner Block ausgeführt wird. Um damit umzugehen sicher zwei Dinge getan werden muss:

1. immer einen schwachen Verweis auf self (oder die Ivar selbst)
2. bestätigen immer weakSelf existiert, bevor es als nunnull param

vorbei UPDATE:

Putting ein wenig Protokollierung performBatchUpdates bestätigt eine Menge:

- (void)logPerformBatchUpdates { 
    [self.collectionView performBatchUpdates:^{ 
     NSLog(@"starting reload"); 
     [self.collectionView reloadItemsAtIndexPaths:[self.collectionView indexPathsForVisibleItems]]; 
     NSLog(@"finishing reload"); 
    } completion:^(BOOL finished) { 
     NSLog(@"completed"); 
    }]; 

    NSLog(@"exiting"); 
} 

Drucke:

starting reload 
finishing reload 
exiting 
completed 

Dies zeigt, dass der Abschluss Block nach dem Verlassen des aktuellen Bereichs abgefeuert wird, das heißt, sie asynchron zurück zu dem Haupt-Thread abgesendet wird.

Sie erwähnen, dass Sie den View-Controller nach dem Batch-Update sofort schließen. Ich denke, das ist die Wurzel Ihres Problems:

Nach ein paar Tests war die einzige Möglichkeit, die Speicherleck neu erstellen konnte, indem Sie die Arbeit vor der Kündigung geschickt. Es ist ein langer Schuss, aber nicht Ihr Code wie folgt aussehen zufällig ?:

- (void)breakIt { 
    // dispatch causes the view controller to get dismissed before the enclosed block is executed 
    dispatch_async(dispatch_get_main_queue(), ^{ 
     [self.collectionView performBatchUpdates:^{ 
      [self.collectionView reloadItemsAtIndexPaths:[self.collectionView indexPathsForVisibleItems]]; 
     } completion:^(BOOL finished) { 
      NSLog(@"completed: %@", self); 
     }]; 
    }); 
    [self.presentationController.presentingViewController dismissViewControllerAnimated:NO completion:nil]; 
} 

Der obige Code führt zu dealloc nicht auf dem View-Controller aufgerufen wird.

Wenn Sie Ihren bestehenden Code und einfach versenden (oder performSelector: nach :) dismissViewController Anruf Sie werden wahrscheinlich das Problem auch beheben.

Answer 2

Dies scheint wie ein Fehler mit UICollectionView. API-Benutzer sollten nicht davon ausgehen, dass einzelne Ausführungsparameter über die Ausführung der Task hinaus beibehalten werden. Daher sollte die Vermeidung von Referenzzyklen kein Problem darstellen.

UICollectionView sollte alle Verweise auf Blöcke aufräumen, nachdem der Stapelaktualisierungsprozess beendet wurde oder wenn der Stapelaktualisierungsprozess unterbrochen wurde (z. B. indem die Sammlungsansicht vom Bildschirm entfernt wurde).

Sie haben selbst gesehen, dass der Completion-Block aufgerufen wird, auch wenn die Sammlungsansicht während des Aktualisierungsvorgangs außerhalb des Bildschirms angezeigt wird. Daher sollte die Sammlungsansicht alle Referenzen auf diesen Komplettierungsblock anzeigen wird nie wieder aufgerufen, unabhängig vom aktuellen Status der Sammlungsansicht.