Pisanie czystego, wydajnego kodu dla iPhone'a

Question

Pracuję nad iPhone'em z Objective-C od kilku miesięcy i stosuję najlepsze praktyki wyuczone i dopracowane przy tworzeniu aplikacji z Javą. Należą do nich: projektowanie klas, które mają jedną odpowiedzialność, stosowanie wzorców projektowych w stosownych przypadkach i pisanie short methods, które wykonują tylko jedną rzecz. Dla mnie te praktyki są zarówno korzystne z perspektywy clean-code i są w dużej mierze agnostyczne domeny.

Jestem bardzo zadowolony z wyników. Jednak kilku programistów iPhone'a osobiście mi doradziło, ponieważ mówią, że piszę za dużo klas i za dużo metod. W różnych okresach Zostałem ostrzeżony:

• Stos powalą
• Zbyt wiele klas spowolni iPhone w dół (czyli wyczuwalny przez użytkownika)
• zagnieżdżone wywołania metod zaszkodzi wydajności (czyli wyczuwalny przez użytkownik)

W praktyce nie doświadczyłem tych problemów. Patrząc powierzchownie na jakieś iPhone performance metrics wydaje mi się, że dodatkowe wywołania metod i obciążenie związane z cyklem życia obiektu wymagane do wdrożenia typowych wzorców i krótkich metod raczej nie spowodują zauważalnego opóźnienia użytkownika. Jednak porady innych programistów iPhone'a mnie trochę wystraszyły.

Chciałbym kontynuować naukę i udoskonalić praktyki programowania agnostycznego w dziedzinie domeny, które dobrze mi służyły w przeszłości, ale podczas pracy nad iPhonem nie chcę wyruszyć w trasę, która zakończy się bólem!

Czy w związku z tą platformą należy zrezygnować ze wspólnych najlepszych praktyk i mieć większą świadomość optymalizacji kosztów ogólnych związanych z wezwaniami i obiektami? Czy mam kontynuować po Knuth's rada:

Przedwczesna optymalizacja jest korzeniem całe zło (a przynajmniej większość z nich) w programowania

Answer 1

dla mnie to naprawdę nie sprowadzają się do konserwacji. dzięki dobrej jakości kodowi można znacznie łatwiej utrzymać system.

Mam programistów, którzy pracują ze mną i kiedy proponuję, aby zrobili skróty, aby system działał, gardzą mną i dostarczają projekt późno. i zapłacił za każdym razem na dłuższą metę !!!

jeśli jest to intensywna aplikacja, korzystająca z opebGL, a jaka wtedy wydajność może stać się problemem. jeśli to tylko prosta aplikacja narzędziowa lub danych. polecałbym kontynuowanie najlepszych praktyk kodowania, które znasz, a następnie kontynuowanie nauki, ponieważ są nieocenione. Większość wzorców jest agnostyczna i korzystna dla wszystkich języków programistycznych.

A jeśli rozwalisz stos, to zaryzykuj niektóre z tych metod/klas w pojedyncze połączenia (przynajmniej wiesz, że to może się zdarzyć i zauważą je tak szybko, jak to się stanie) A jeśli tak, to masz niesamowite kod do utrzymania, który jest łatwy do odczytania przez małpę o połowicznym upakowaniu, która musi na nią patrzeć.

Answer 2

Cały problem z spowalnianiem aplikacji OO jest po prostu tym, że obiekt może wymknąć się spod kontroli łatwiej niż ustrukturyzowane style programowania. Dawno, dawno temu, zanim poprawiono optymalizację wywołania metody, mogło to mieć znaczenie, zwłaszcza gdy wykonano połączenia pośrednie (tj. Wirtualne).

Jeśli twoje obiekty są często używane, a masz kilka obiektów niższego poziomu, które często wywołujesz, być może osiągniesz lepsze wyniki z ich używania - ale mówię o milionach połączeń (widziałem jakiś straszny kod w moim czasie, zarówno niestrukturalny, zorganizowany i OO!). Otrzymasz także więcej trafienia wydajnościowego, jeśli przez cały czas alokujesz i usuniesz wiele obiektów (LOTS).

Jedyną odpowiedzią jest, naprawdę, przyjrzenie się. Jeśli masz obiekt, który zostanie przydzielony, usunięty w krótkim odstępie czasu, następnie zoptymalizuj go (nawet jeśli wygląda mniej elegancko), jeśli masz obiekt, który ty nazywasz jego metodami tysiące razy, wtedy zoptymalizuj to również. (ale gdy już dokonasz pomiaru, zmierzysz jego wydajność, a będziesz doskonalić powolne bity!).

Istnieje kompromis pomiędzy "eleganckim" kodem i kodem, który działa prosto i szybko, nie idź do jednej skrajności i powinieneś być w porządku.

Answer 3

Miałem podobne doświadczenie przy opracowywaniu dość skomplikowanej aplikacji Blackberry. Ja też kazano mi unikać częstych przydziałów obiektów, klas wewnętrznych itp. Pierwotną aplikacją, którą mieliśmy, był niepojęty bałagan. Ostatnio przerobiłem aplikację z naciskiem na dobry projekt OO (wzory w razie potrzeby, wiele pojedynczych, często niemodyfikowalnych obiektów itp.). W wielu miejscach naruszyłem zasadę unikania pewnych "kosztownych" konstrukcji i przydzielania obiektów. Uzyskana aplikacja była nie tylko łatwiejsza w utrzymaniu, ale także mniejsza. Jeśli dodatkowe przydziały obiektów stworzyły jakiekolwiek obciążenie, na pewno nie zauważyłem. Myślę, że lekcja tutaj jest dokładnie tym, co powiedział Knuth. Skup się najpierw na dobrym projekcie, a następnie w razie potrzeby zoptymalizuj. Ponadto, te urządzenia mobilne mają obecnie wystarczająco dużo pamięci, aby mieć nadzieję, że ta rada straci na wartości ...

Answer 4

Ogólnie mówiąc: nie martw się o to. Jedyny przypadek, w którym używanie obiektów i komunikatów może być potencjalnym problemem z wydajnością, polega na tym, że wykonujesz setki lub tysiące przydziałów na raz lub wykonujesz tysiące wiadomości wysyłanych co kilka ms. Nie chciałbyś używać obiektów Obj-C do reprezentowania tysięcy wektorów 3D w symulacji fizyki.

Nawet w przypadku, gdy wykonujesz wiele wysyłek wiadomości w pętli, możesz uzyskać lepszą wydajność przez przechowywanie wskaźnika funkcji do odpowiedniej metody przed pętlą.