Na Cocoa Touch/UIKit, jak wykrywać zmiany w interfejsie użytkownika z wątku tła?

Question

W przypadku Cocoa Touch, jeśli zaktualizujemy elementy interfejsu użytkownika z wątku w tle, wystąpią złe rzeczy.

Problem polega na tym, że nie zdarza się to przez cały czas, więc niektóre łagodne interakcje w interfejsie użytkownika mogą pozostać niezauważone przez pewien czas, dopóki nie rozwinie się ono w zębach.

Czy istnieje sposób, aby UIKit działał w trybie pedantycznym, tak aby jak tylko ktoś zaktualizował element z wątku tła, ulegał awarii lub logował coś do konsoli?

Answer 1

Możesz sprawdzić, czy robisz coś w głównym wątku, czy nie, przed wykonaniem aktualizacji interfejsu użytkownika. Pisałem sobie następujące makra:

/// Stick this in code you want to assert if run on the main UI thread. 
#define DONT_BLOCK_UI() \ 
    NSAssert(![NSThread isMainThread], @"Don't block the UI thread please!") 

/// Stick this in code you want to assert if run on a background thread. 
#define BLOCK_UI() \ 
    NSAssert([NSThread isMainThread], @"You aren't running in the UI thread!") 

bywam grupie mojego kodu w metodach, gdzie metoda A wykonuje pewne przetwarzanie, a następnie wywołuje metodę B, który robi aktualizacje interfejsu użytkownika. Na początku metody B przyklejam makro BLOCK_UI(), które będzie twierdzić, jeśli nie jest uruchamiane w interfejsie użytkownika. Ponadto w przypadku długich zadań używam innego makra. Umieściłem te makra i bardziej losowe rzeczy na https://github.com/gradha/ELHASO-iOS-snippets, które mogą okazać się przydatne.

Te makra wymagają niestety dyscypliny w ich używaniu. Bardziej uciążliwym sposobem radzenia sobie z takimi sytuacjami może być owinięcie wszystkich obiektów interfejsu SDK za pośrednictwem serwera proxy (może podczas uruchamiania?), Które zapewniało, że nie były używane w głównym wątku. Te proxy/swizzling miałyby miejsce tylko w kompilacjach debugowania lub środowisku symulatora, aby uniknąć gwałtownych zmian. Rozważałem zrobienie tego ... ale wygląda na to, że ból jest właściwy.