aby drawRect lub nie drawRect (kiedy należy użyć drawRect / Core Graphics vs podviews/images i dlaczego?)

Różnica polega na tym, że UIView i CALayer zasadniczo zajmują się stałymi obrazami. Obrazy te są przesyłane do karty graficznej (jeśli znasz OpenGL, pomyśl o obrazie jako teksturze, a UIView/CALayer jako wielokąt pokazujący taką teksturę). Gdy obraz znajduje się na GPU, można go narysować bardzo szybko, a nawet kilka razy i (z niewielką karą za wydajność) nawet przy różnym poziomie przezroczystości alfa na innych obrazach.

CoreGraphics / Quartz jest API dla generowanie obrazów. Pobiera bufor pikseli (ponownie pomyśl o teksturze OpenGL)i zmienia poszczególne piksele w nim. To wszystko dzieje się w pamięci RAM i na procesorze, a dopiero po wykonaniu kwarcu obraz zostaje" spłukany " z powrotem do GPU. Ta runda pobierania obrazu z GPU, zmiany go, a następnie przesyłanie całego obrazu (lub przynajmniej stosunkowo dużej jego części) z powrotem do GPU jest raczej powolna. Ponadto, rzeczywisty rysunek, który robi Quartz, podczas gdy naprawdę szybki dla tego, co robisz, jest znacznie wolniejszy niż to, co robi GPU.

To oczywiste, biorąc pod uwagę, że GPU porusza się głównie po niezmienionych pikselach w dużych kawałkach. Quartz ma losowy dostęp do pikseli i dzieli procesor z siecią, audio itp. Ponadto, jeśli masz kilka elementów, które rysujesz za pomocą kwarcu w tym samym czasie, musisz ponownie narysować je wszystkie, gdy jeden się zmieni, a następnie przesłać cały fragment, podczas gdy jeśli zmienisz jeden obraz, a następnie pozwolisz UIViews lub CALayers wkleić go na inne obrazy, możesz uciec z przesyłaniem znacznie mniejszych ilości danych do GPU.

Gdy nie zaimplementujesz-drawRect:, większość widoków można po prostu zoptymalizować. Nie zawierają żadnych pikseli, więc nie mogą nic narysować. Inne widoki, takie jak UIImageView, rysują tylko UIImage (który, ponownie, jest zasadniczo odniesieniem do tekstury, która prawdopodobnie została już załadowana na GPU). Więc jeśli narysujesz ten sam UIImage 5 razy za pomocą interfejsu UIImageView, zostanie on przesłany do GPU tylko raz, a następnie narysowany na wyświetlaczu w 5 różne lokalizacje, oszczędzając nam czas i procesor.

Gdy zaimplementujesz -drawRect:, spowoduje to utworzenie nowego obrazu. Następnie rysujesz to na procesorze za pomocą kwarcu. Jeśli narysujesz interfejs użytkownika w aplikacji drawRect, prawdopodobnie pobierze on obraz z procesora graficznego, skopiuje go na obraz, na którym rysujesz, a gdy skończysz, załaduje tę drugą kopię obrazu z powrotem do karty graficznej. Więc używasz dwukrotnie więcej pamięci GPU na urządzeniu.

Więc najszybszym sposobem na losowanie jest zazwyczaj, aby zachować zawartość statyczną oddzieloną od zmieniającej się zawartości (w osobnych podklasach UIView/UIView/CALayers). Załaduj statyczną zawartość jako interfejs i narysuj ją za pomocą interfejsu UIImageView, a następnie umieść zawartość generowaną dynamicznie w czasie wykonywania w interfejsie drawRect. Jeśli masz zawartość, która jest rysowana wielokrotnie, ale sama w sobie nie zmienia się (tj. 3 ikony, które są wyświetlane w tym samym gnieździe, aby wskazać jakiś status), użyj UIImageView również.

Jedno zastrzeżenie: istnieje coś takiego jak posiadanie zbyt wielu przeglądów. Szczególnie przezroczyste obszary mają większy wpływ na procesor graficzny, ponieważ muszą być mieszane z innymi pikselami za nimi, gdy są wyświetlane. Dlatego możesz oznaczyć UIView jako "nieprzezroczysty", aby wskazać GPU, że może on po prostu zatrzeć wszystko za tym obrazem.

Jeśli masz zawartość, która jest generowana dynamicznie w czasie wykonywania, ale pozostaje taka sama przez cały okres życia aplikacji (np. etykietę zawierającą Nazwę użytkownika), może mieć sens po prostu narysować całość raz za pomocą kwarcu, z tekstem, obramowaniem przycisku itp., jako część tła. Ale zazwyczaj jest to optymalizacja, która nie jest potrzebna, chyba że aplikacja Instruments mówi inaczej.

Postaram się zachować podsumowanie tego, co ekstrapoluję na podstawie odpowiedzi innych i zadam pytania wyjaśniające w aktualizacji do pierwotnego pytania.[[2]} ale zachęcam innych do ciągłych odpowiedzi i głosowania na tych, którzy dostarczyli dobrych informacji.

Podejście Ogólne

Jest całkiem jasne, że ogólne podejście, jak wspomniał Ben Sandofsky w swojej odpowiedzi, powinno brzmieć " Kiedy tylko możesz, użyj UIKit. Wykonaj najprostszą implementację, która działa. Profil. Gdy jest zachęta, Optymalizuj."

Dlaczego

W iDevice istnieją dwa główne wąskie gardła, CPU i GPU Procesor jest odpowiedzialny za wstępne rysowanie / renderowanie widoku]}
1. GPU odpowiada za większość animacji (Core Animation), efekty warstw, komponowanie itp.
UIView ma wiele optymalizacji, buforowania itp., wbudowanych do obsługi złożonych hierarchii widoków]}
2. gdy nadpisanie drawRect tracisz wiele korzyści, które zapewnia UIView, i ogólnie jest wolniejszy niż pozwala UIView obsługiwać renderowanie.

Rysowanie zawartości komórek w jednym płaskim UIView może znacznie poprawić liczbę klatek na sekundę na tablicach przewijania.

Jak powiedziałem powyżej, CPU i GPU to dwa możliwe wąskie gardła. Ponieważ zazwyczaj zajmują się różnymi rzeczami, musisz zwrócić uwagę na to, z którym wąskim gardłem masz do czynienia. w przypadku przewijania tabel nie jest to Core Graphics rysuje się szybciej, dlatego może znacznie poprawić liczbę klatek na sekundę.

W rzeczywistości grafika rdzeniowa może być wolniejsza niż zagnieżdżona hierarchia UIView dla początkowego renderowania. Wydaje się jednak, że typowym powodem niestabilnego przewijania jest wąskie gardło GPU, więc musisz się tym zająć.

Dlaczego nadpisanie drawRect (przy użyciu grafiki core) może pomóc w przewijaniu tabeli:

Z tego co rozumiem, GPU nie odpowiada za początkowe renderowanie widoków, ale zamiast tego jest przekazywane tekstury lub bitmapy, czasami z niektórymi właściwościami warstw, po ich wyrenderowaniu. Następnie jest odpowiedzialny za komponowanie bitmap, renderowanie wszystkich tych warstw i większość animacji (Core Animation).

W przypadku komórek widoku tabeli, GPU może być wąskie za pomocą złożonych hierarchii widoków, ponieważ zamiast animować jedną bitmapę, animuje widok nadrzędny i wykonuje obliczenia układu widoku podrzędnego, renderuje efekty warstw i komponowanie wszystkich podwidywań. Zamiast animować jedną bitmapę, jest ona odpowiedzialna za relacje kilku bitmap i sposób ich interakcji dla tego samego obszaru pikseli.

Podsumowując, powodem, dla którego rysowanie komórki w jednym widoku z rdzeniem graficznym może przyspieszyć przewijanie tabeli, nie jest to, że rysuje się szybciej, ale dlatego, że zmniejsza obciążenie GPU, które jest wąskim gardłem, dając problemy w tym konkretnym scenariuszu.

Jestem twórcą gier i zadawałem te same pytania, Kiedy mój przyjaciel powiedział mi, że moja hierarchia widoku oparta na UIImageView spowolni moją grę i sprawi, że będzie straszna. Następnie przystąpiłem do badania wszystkiego, co mogłem znaleźć na temat tego, czy używać UIViews, CoreGraphics, OpenGL lub czegoś innego, takiego jak Cocos2D. spójna odpowiedź, którą otrzymałem od przyjaciół, nauczycieli i inżynierów Apple w WWDC, była taka, że nie będzie dużej różnicy w końcu, ponieważ na pewnym poziomie są wszyscy robią to samo . Opcje wyższego poziomu, takie jak UIViews, opierają się na opcjach niższego poziomu, takich jak CoreGraphics i OpenGL, po prostu są zawinięte w kod, aby ułatwić Ci korzystanie z nich.

Nie używaj CoreGraphics, jeśli zamierzasz po prostu skończyć na ponownym pisaniu UIView. Możesz jednak zyskać trochę szybkości dzięki CoreGraphics, o ile wykonasz wszystkie swoje rysunki w jednym widoku, ale czy naprawdę jest to warte? Odpowiedź, którą znalazłem, to zazwyczaj nie. Kiedy zaczynałem grę, pracował z iPhone 3G. jak moja gra wzrosła w złożoności, zacząłem widzieć pewne opóźnienia, ale z nowszymi urządzeniami było całkowicie niezauważalne. Teraz mam mnóstwo akcji dzieje, a jedynym lag wydaje się być spadek w 1-3 fps podczas gry w najbardziej skomplikowanym poziomie na iPhone 4.

Mimo to postanowiłem użyć instrumentów, aby znaleźć funkcje, które zajmowały najwięcej czasu. Okazało się, że problemy nie były związane z używaniem UIViews . Zamiast tego wielokrotnie wywołanie CGRectMake dla pewnych obliczeń wykrywania kolizji i osobnego ładowania obrazów i plików audio dla pewnych klas, które używają tych samych obrazów, zamiast pobierania ich z jednej centralnej klasy pamięci masowej.

Tak więc w końcu możesz osiągnąć niewielki zysk z używania CoreGraphics, ale zazwyczaj nie będzie to tego warte lub może nie mieć żadnego efektu. Używam CoreGraphics tylko wtedy, gdy rysuję geometryczne kształty, a nie tekst i obrazy.