2009-08-25 13 views
6

alt textOpis narzędzia do sprawdzania nieszczelności pamięci - iPhone

Powyższe zdjęcia to nieszczelności aplikacji.

Tutaj chcę zrozumieć, że w rozszerzonej szczegółowości - można zobaczyć różne kolory, takie jak jasnozielony, jasnoróżowy, jasnobrązowy, jasny fiolet.

Co oznacza każdy kolor?

Teraz inne zamieszanie to "Jak zlokalizować kod, który powoduje wyciek pamięci?"

Do jakiego limitu przecieku pamięci - rzeczywisty iPhone może dalej działać. (załóżmy 10 bajtów nie ma problemu, 20 bajtów bez problemowe & 200 bajtów problem)

  • Co każdy kolor oznacza?
  • Który kolor oznacza nasz kod/Z którego szczegółu możemy dostać się do kodu, w którym przyznaliśmy obiekt & zapomnieliśmy o zwolnieniu go?

(Na przykład - po kliknięciu na UIKit drugą komórkę w szczegółach - nie możemy dostać się do kodu)

  • Dlaczego musimy rozwiązać wszelkie przecieki? - nawet jeden wyciek może zablokować iPhone'a?
  • Dlaczego iPhone pozwala, aby wycieki pozostały w pamięci?/dlaczego wyrzucanie śmieci nie odbywa się automatycznie po zakończeniu aplikacji?
  • Jeśli próbuję dealloc obiektów, które powinny być dealokowane zgodnie z instrumentów, Moje zgłoszenie kończy się nienormalnie. Jeśli nie dealall, Moja aplikacja działa idealnie, jak?
  • Dlaczego sugeruje się, aby czekać w widoku do 10 lub więcej sekund, jeśli wystąpił wyciek, wyciek zostanie wykryty przez Instruments?

Odpowiedz

14

Ignoruj ​​kolory, w tym jeden w [Kokpit viewDidLoad] jest źródłem przecieku, coś jak to inicjowanie URLConnection (ewentualnie nie zrobił wolny, że gdy połączenie zostało zakończone?)

Teraz odpowiedz na pozostałe pytania:

  • Dlaczego musimy rozwiązać wszystkie nieszczelności? - nawet jeden wyciek może zablokować telefon iPhone ?

Tak. Jednym z powodów jest nie tylko to, że po prostu zabraknie pamięci, ale ponieważ jest tylko tyle pamięci do obejrzenia dla całego telefonu, aplikacja monitorująca stale monitoruje twoją aplikację i wyłączy ją wcześniej, jeśli zobaczy pamięć. tylko ciągle rośnie ...

  • Dlaczego iPhone pozwala na pozostanie nieszczelności w pamięci?/dlaczego wywóz śmieci nie odbywa się automatycznie po wypowiedzeniu wniosku?

Cała pamięć aplikacji zostaje zwolniona po zamknięciu aplikacji.

  • Gdy próbuję dealloc obiektów, które powinny być zwalniane według instrumentów, Moja aplikacja kończy nieprawidłowo.Jeśli nie mam dealloc, moja aplikacja działa idealnie, jak?

Tutaj nie mogę pomóc, czego naprawdę potrzebujesz, aby przeczytać więcej na zachowania/zwalniania pamięci cyklu ... jeśli zwolnić obiekt, który ma liczbę zatrzymania 0, awarii aplikacji, ponieważ obiekt jest zniknął .

  • Dlaczego zaleca, aby poczekać na rzutem do 10 lub więcej sekund, jeśli jest wyciek, wyciek będzie wykryty przez instrumenty?

Ponieważ instrumenty działają poprzez pobieranie próbek pamięci co jakiś czas, więc może trochę potrwać, zanim instrumenty przejdą do czytania pamięci po akcji.

+2

+1 Doskonała odpowiedź Kendall. @Sagar, powinieneś zauważyć, że na pytanie 3 powinieneś * nigdy * wywołać dealloc bezpośrednio, tylko zachować lub wydać (tylko wyjątek to [super dealok]). Uważam, że twoim rozwiązaniem jest zaimplementowanie autoreasady, ponieważ wygląda na to, że przyczyną awarii jest wczesne zwolnienie obiektów. np. [[[NSArray alloc] init] autorelease]; – h4xxr

3

Kolory reprezentują różne biblioteki, przez które przechodzi stos wywołań.

Przeciek jest spowodowany przez ramkę kodu, która dokonała alokacji, nawet jeśli faktyczna alokacja odbywa się głęboko w bibliotece systemu operacyjnego. Instruments pokazuje Ci dokładnie, gdzie została przydzielona przeciekła pamięć. Będziesz musiał dowiedzieć się, która linia w twoim kodzie spowodowała przeciekany przydział, który będzie jedną z klatek w stosie po prawej.

Rzeczywiste urządzenie iPhone nie ma dużo dostępnej pamięci RAM dla aplikacji. Staram się ostrożnie oszacować około 25 MB pamięci RAM, aby moja aplikacja mogła pracować. Jakikolwiek wyciek, bez względu na to, jak mały, może zatopić przysłowiowy statek, jeśli kod jest wystarczająco używany.

5

Przede wszystkim rzeczy w stosie są zabarwione przez bibliotekę, z której pochodzą, więc nie zawierają zbyt wielu informacji.

Po drugie, zamiast martwić się o to, ile iPhone może przeciekać, skupiłbym się na tym, by nie wyciekł.

Aby znaleźć przecieki, istnieje kilka możliwości:

  • Użyj CLANG static analyzer budując projekt
  • Poszukaj nieszczelności ręcznie. Musisz zawsze przestrzegać zasad zarządzania pamięcią: jeśli alloc, retain lub copy obiekt (w tym przy użyciu @property (retain) lub (copy)), to koniecznościąrelease lub autorelease go.
1

Wyszukaj nazwę aplikacji w widoku rozszerzonym stosu. Alokacja pamięci jest zwykle pokazywana na końcu, więc wiesz dokładnie, która biblioteka jest odpowiedzialna za przydzielanie pamięci. Powinieneś więc śledzić od linii, w której twój kod pojawia się w dół, aż do końca. Kolory po prostu ułatwiają śledzenie linii kodu, które są powiązane z tymi samymi bibliotekami. Te same wywołania biblioteki będą miały ten sam kolor.

Jeśli chodzi o śledzenie wycieku. Najpierw przejdź do wywołania aplikacji, klikając dwukrotnie wiersz w rozszerzonym widoku i spróbuj zrozumieć, co dokładnie wycieka. Czasami możesz zastąpić nieszczelny telefon zastępcą, który nie wycieknie. Na przykład użyłem połączenia imageNamed, aby pobrać obrazy z pakietu, aplikacja stale się zawiesza z powodu braku pamięci. Po prostu wylogowałem się z programu ImageNamed wycieki i znalazłem bardzo przydatny artykuł na temat tego, jak zaimplementować gotówkę obrazową w mojej aplikacji. Rzeczywiście wycieki imageNamed API. Istnieją API, które wycieka w iPhone SDK.

Spróbuj także sprawdzić, jak pracujesz z funkcją alloc/retain/release i tak dalej, niezależnie od tego, czy zwolnisz, czy zwolnisz przydzieloną pamięć.

Powodzenia w pracy detektywa.

+0

@Nava Carmon - Jeśli masz link do tego wycieku API. Czy mógłbyś podać to w swojej odpowiedzi? Dzięki. –

0

Ja też mam problemy z przeciekami w instrumentach. Uruchomiłem swoją aplikację dzisiaj po raz pierwszy przy użyciu przecieków i znalazłem kilka wycieków. Wycieki, które nie powinny być przecieki, ponieważ nie ma możliwości ich wycieku, chyba że jakiś magiczny kod wykona i podniesie liczbę moich obiektów. Rozumiem wytyczne dotyczące zarządzania pamięcią, wiem, jak korzystać z puli autoreasserów itp. Ale nawet aplikacja oparta na widoku zawierała nieszczelności, jeśli umieściłem na niej kilka elementów sterujących. I klikaj około 2-3 razy. Śmiało i spróbuj tego. Nie mam pojęcia, jakie instrumenty informacyjne starają się zapewnić. Czy te "przecieki" naprawdę przeciekają, czy tylko rzeczy, które są podejrzane do aplikacji na instrumenty? Czy w przypadku pustej aplikacji bez kodu użytkownika, tylko kilka elementów sterujących umieszcza pustą pamięć widoku?

+0

Nie wierzę, że to "rzeczy", które są podejrzane. Narzędzie Leak sprawdza, czy istnieje odwołanie do bloku pamięci w zapisywalnej pamięci aplikacji, rejestrach i stosie. Jeśli ich nie ma, a blok pamięci nadal istnieje, instrument traktuje bufor jako wyciek. – hmak

+0

Czy jest to na symulatorze lub na urządzeniu? Zauważyłem, że "wycieki" wykryte na symulatorze nie pojawiają się podczas pracy na rzeczywistym urządzeniu, więc nie zawracam sobie głowy profilowaniem przecieków na symulatorze. – daver

+0

Wycieki były inne na urządzeniu, w ogóle było ich mniej. Przestałem się rozwijać dla iPhone'a. –