2012-07-18 10 views
15

Stworzyłem projekt na GitHub, aby nauczyć się optymalizować pracę w sieci dla moich aplikacji na iOS. Użyłem mocno bloków i GCD, a po obejrzeniu wideo i filmów z WWDC 2012 z minionych lat dowiedziałem się, że być może będę mógł zrobić więcej z NSOperationQueue. W szczególności mogę kontrolować liczbę równoczesnych operacji (połączeń sieciowych), a także zapewniać anulowanie operacji. Eksperymentuję z dopuszczeniem 1, 2, 4, 8 i 16 równoczesnych operacji i widzę interesujące wyniki, których zupełnie nie oczekiwałem. Zmierzam wyniki, ale zastanawiam się, czy jest coś, co powinienem mierzyć.Jak mogę lepiej optymalizować pracę w sieci w systemie iOS?

można znaleźć przykładowy projekt tutaj:

https://github.com/brennanMKE/OptimizedNetworking

Ponieważ używam API asynchronicznej z NSURLConnection istnieje wiele korzyści posiadania wielu równoczesnych połączeń, ponieważ API spędza sporo czasu oczekiwania na Pakiety HTTP. Poprzednio mój kod zaczynał się od tablicy elementów do pobrania i żądania wszystkich kolejno, co zapobiega korzyściom z współbieżności. Używam również powiadomień, aby anulować połączenia sieciowe. Teraz mogę to zrobić w tym projekcie za pomocą operacji i skonfigurowałem je tak, aby używały wartości dla priorytetu i kategorii, dzięki czemu mogę ustalać priorytety i sortować pliki do pobrania oraz anulować kategorię operacji. Mogę wybrać kategorię dla każdego widoku, a gdy użytkownik opuści widok, wszystkie operacje dla tego widoku zostaną anulowane przy użyciu kategorii. Spowoduje to zwolnienie zasobów dla aktywnego widoku.

Jedną z obaw związanych z używaniem większej liczby współbieżnych operacji jest użycie procesora, a także operacje we/wy, ale nie jestem świadomy sposobu mierzenia tych wartości za pomocą iOS. Odpowiednikiem może być ekwiwalent polecenia "w" w systemie iOS w celu pokazania użycia procesora. Jestem mniej zaniepokojony operacjami wejścia/wyjścia, ale pomiar byłby bardziej wszechstronny.

Moim głównym problemem związanym z tym, jak pracowałem w sieci, był responsywny interfejs użytkownika. Zauważyłem, że to, co robiłem, sprawiło, że interfejs użytkownika jest powolny. To nowe podejście może bardzo pomóc, ale tylko wtedy, gdy ograniczę liczbę równoległych operacji. Optymalna liczba operacji może się różnić w zależności od rodzaju połączenia (3G, WiFi, itp.), Więc sprawdzenie typu połączenia może prowadzić do pewnych optymalizacji.

Jeśli są Państwo zainteresowani lepszymi sposobami na przyspieszenie komunikacji sieciowej w swojej aplikacji, wypróbuj ten przykładowy projekt i zasugeruj inne sposoby mierzenia wydajności i oferowania sposobów dalszej optymalizacji komunikacji. (Zwróć także uwagę na przykładowy projekt Apple MVCNetworking oraz projekt ASIHTTPRequest:

Co mogę zrobić, to zsumować ilość pobranych danych i zachować dziennik o tej wartości wraz z łącznym czasem zakończyć pobieranie.

plik README powinien pomóc wyjaśnić projekt i jak to działa.

+1

+1, wysiłek i interesujące jako dobrze. – CodaFi

+1

Jeśli spojrzysz na mój projekt na github, NSOperation-WebFetches-MadeEasy, istnieje klasa pomocnicza, która zarządza operacjami dla ciebie. Używam tego dokładnego kodu w dwóch aplikacjach w sklepie z wielkim sukcesem i często dodajem do tej kolejki ponad 100 operacji. Pamiętaj, że iOS ściśle współpracuje z NSOperationsQueue, aby zarządzać obciążeniem. Nigdy nie widzę żadnego wpływu na główny wątek z powodu. –

+0

CodeFi Dzięki. @DavidH Rozwinąłem twój projekt i przejrzę go, aby zobaczyć, czego mogę się od niego nauczyć. Dzięki. – Brennan

Odpowiedz

3

Jeśli to pomaga Mugunth Kumar faktycznie sprawdza typ połączenia przy użyciu klasy osiągalności przed ustawieniem rozmiaru połączenia NSOperationQueue max w MKNetworkKit

+0

Według Quinn "Eskimo" nie powinieneś oprzeć swojej sieci na typie połączenia (WiFi, 3G, Edge, itp.), Ale raczej zmierzyć szybkość pobierania, aby zdecydować. Interesują mnie również dane dotyczące iPoda, iPhone'a i iPada dotyczące liczby jednoczesnych operacji. Sprawdzę MKNetworkKit. – Brennan

+0

Chociaż mam tendencję do wyrażania zgody, widzę zaletę polegającą na tym, że wiem z góry, że jesteśmy w sieci EDGE, a maksymalna prędkość pobierania będzie prawdopodobnie wynosić maksymalnie 1-2 kolejki operacji netto. Pomiar prędkości d/l może zwiększyć tę pierwszą kontrolę prawdopodobnie. Jeśli jakieś założenie było nieprawidłowe, możemy dokonać korekt na podstawie bieżącej przepustowości. – IanStallings

+1

W mojej przykładowej aplikacji planuję śledzić wydajność, aby wyświetlać statystyki dla różnych scenariuszy. Najprawdopodobniej zgromadzę coś z Core Data, aby utrzymać bieżącą listę wyników, aby umożliwić podsumowanie całej historii. To może ujawnić sposoby dalszej optymalizacji. – Brennan