2013-01-13 15 views
7

Od czasu konwersji starej aplikacji na system iOS 6, zacząłem otrzymywać następujący komunikat w konsoli.Powolny czas ładowania UIViewController (wolne ostrzeżenie ClientState)

WARNING: Slow defaults access for key ClientState took 0.023656 seconds, tolerance is 0.020000

Poza aktualizacją mój kod z iOS 5 do iOS 6, ja też przełączony do automatycznego układu. Uruchomiłem Instruments/Time Profiler i rootViewController w mojej appDelegate jest problem. Za każdym razem, gdy przełączam kontrolery widoku, zasysam ogromną część czasu (niezależnie od tego, czy mam utworzyć instancję kontrolera widoku, czy też ponownie użyć tego, który już istnieje).

window.rootViewController = myViewController; 

wiem jaka metoda nie powierzchownie, ale nie jestem pewien, co się dzieje pod kołdrą ... co spowodowałoby, że jest powolny teraz i co mogę zrobić, aby ją przyspieszyć?

EDIT: Próbowałem biorąc moją storyboard wyłączyć auto-układ i problem znika (oczywiście mój układ UI jest w ruinie). Więc oczywistym wnioskiem jest to, że jest to coś z auto-układu. Mam prawdopodobnie niewiele mniej niż 70 wyświetleń połączonych na ekranie i różne ograniczenia potrzebne do ich ułożenia. Trudno mi uwierzyć, że auto-layout jest znacznie wolniejszy (od -80ms z wyłączonym automatycznym układem do ~ 1370ms z włączonym autoodkładaniem).

+0

Dziwne ostrzeżenie nigdy wcześniej tego nie widziało, ale czy używasz Core Data? – Nathan

+0

Nie. Tylko kilka dość skomplikowanych kontrolerów widoku na jednym storyboardzie i niektóre klasy obiektów danych, które serializuję. Ponieważ wszystkie dane (które nie są dużo) musiały pozostać w pamięci przez cały czas, gdy aplikacja działa, dane Core Data wydawały się przesadą. – DBD

+0

możliwy duplikat [Powolny domyślny dostęp dla klucza Ostrzeżenie ClientState na iOS] (http://stackoverflow.com/questions/12873144/slow-defaults-access-for-key-clientstate-warning-on-ios-) –

Odpowiedz

0

Rozważ utworzenie nowego projektu z 2 kontrolerami widoku i przetestuj szybkość przełączania. Każda aplikacja na iOS ma okno, kontroler widoku root i kontroler widoku. Problem prawdopodobnie nie będzie tak wąski i jednoznaczny, jak można mieć nadzieję. Co ładuje każdy kontroler widoku? Czy sprawdziłeś kod źródłowy? Czy delegat aplikacji robi cokolwiek podczas inicjowania lub zmiany kontrolera widoku root?

+0

Kiedy mówisz "sprawdź kod źródłowy", czy możesz wyjaśnić dokładnie, jaki jest podstawowy kod? Chociaż znam niektóre z oczywistych bitów usuwających starą strukturę widoku z okna, dodając nową, uruchamiając różne metody dla tych ... żadna z tych metod nie zajmuje dużo czasu. Aby zwolnić kod, wywoływana metoda nie wykonuje niczego poza utworzeniem kontrolera widoku, jeśli nie istnieje i ustawia "rootViewController". – DBD

3

Mając 70 odsłon na ekranie brzmi jak dużo! Moja propozycja jest uprościć w jakiś sposób:

  • Czy naprawdę potrzebujemy wszystkich 70 widoków w tym samym czasie?

  • Sprawdź, czy wszystkie poglądy muszą autoLayout, usuń ją tam, gdzie to możliwe-

  • Czy niektóre poglądy zostać zastąpione grafiką? Użyłem widoków np. dla cieni, mogły to być obrazy

Czy możesz podzielić tablicę na kilka mniejszych np. jeden dla logowania, szczegółów, trybu edycji itp. Część powolności może pochodzić z systemu, który musi sobie radzić z (zbyt) dużymi piętrami.

+0

70 wyświetleń nie jest trywialne, ale nie jest też ogromne. Rozważ komórkę tabeli. Masz widok tła, widok treści, widok obrazu, widok etykiety, widok ujawnienia (możliwe więcej) i to tylko domyślna komórka. Przy standardowej wysokości komórki równej 10 renderom w tym samym czasie + widok stołowy, pasek nawigacji, tytuł i przycisk. Masz ponad 60 wyświetleń wykraczających poza zwykły interfejs użytkownika. Auto layout jest również oparty na scenorysie. Nie mogę usunąć automatycznego układu na widok i bardzo chciałbym go użyć, ponieważ znacznie uprościł mój kod (musiał zostać usunięty przy partii kodu 'setFrame'). – DBD

Powiązane problemy