Kolektor śmieci w systemie Android

Widziałem wiele odpowiedzi na Androida, które sugerowały dzwonienie do garbage collectora w niektórych sytuacjach.

Czy dobrą praktyką jest zażądanie modułu odśmiecania pamięci w systemie Android przed wykonaniem wymagającej pamięci operacji? Jeśli nie, czy mam zadzwonić tylko wtedy, gdy otrzymam OutOfMemorybłąd?

Czy są inne rzeczy, których powinienem użyć przed skorzystaniem z urządzenia odśmiecającego?

Dla wersji starszych niż 3.0 plaster miodu : Tak, zadzwoń System.gc() .

Próbowałem utworzyć mapy bitowe, ale zawsze otrzymywałem komunikat „Błąd pamięci maszyny wirtualnej”. Ale kiedy zadzwoniłem System.gc()pierwszy, było OK.

Podczas tworzenia map bitowych system Android często kończy się niepowodzeniem z powodu braku pamięci i nie próbuje najpierw zbierać elementów bezużytecznych . Dlatego zadzwoń System.gc(), a będziesz mieć wystarczająco dużo pamięci, aby utworzyć mapy bitowe.

W przypadku tworzenia obiektów myślę, że w System.gcrazie potrzeby zostanie wywołany automatycznie, ale nie do tworzenia map bitowych. Po prostu zawodzi.

Dlatego zalecam ręczne wywoływanie System.gc()przed utworzeniem map bitowych.

Ogólnie rzecz biorąc, w obecności garbage collectora ręczne wywoływanie GC nigdy nie jest dobrą praktyką. GC jest zorganizowany wokół algorytmów heurystycznych, które działają najlepiej, gdy są pozostawione samym sobie. Ręczne wywoływanie GC często zmniejsza wydajność.

Czasami , w niektórych stosunkowo rzadkich sytuacjach, może się okazać, że konkretny GC popełnia błąd, a ręczne wywołanie GC może wtedy poprawić sytuację pod względem wydajności. Dzieje się tak, ponieważ nie jest tak naprawdę możliwe zaimplementowanie „doskonałego” GC, który będzie optymalnie zarządzać pamięcią we wszystkich przypadkach. Takie sytuacje są trudne do przewidzenia i zależą od wielu subtelnych szczegółów implementacji. „Dobra praktyka” polega na tym, aby GC działało samodzielnie; ręczne wezwanie do Sądu jest wyjątkiem, który należy przewidzieć dopiero po należytym zaobserwowaniu rzeczywistego problemu z wydajnością.

Brak pamięci w aplikacji na Androida jest bardzo częsty, jeśli nie obsługujemy poprawnie mapy bitowej, rozwiązaniem problemu byłoby

if(imageBitmap != null) {
    imageBitmap.recycle();
    imageBitmap = null;
}
System.gc();
BitmapFactory.Options options = new BitmapFactory.Options();
options.inSampleSize = 3;
imageBitmap = BitmapFactory.decodeFile(URI, options);
Bitmap  scaledBitmap = Bitmap.createScaledBitmap(imageBitmap, 200, 200, true);
imageView.setImageBitmap(scaledBitmap);

W powyższym kodzie Właśnie próbowałem przetworzyć bitmapę, co pozwoli ci zwolnić używaną przestrzeń pamięci, więc brak pamięci może się nie zdarzyć. Próbowałem to zadziałało dla mnie.

Jeśli nadal masz problem, możesz również dodać tę linię

BitmapFactory.Options options = new BitmapFactory.Options();
options.inTempStorage = new byte[16*1024];
options.inPurgeable = true;

więcej informacji znajdziesz pod tym linkiem

https://web.archive.org/web/20140514092802/http://voices.yahoo.com/android-virtual-machine-vm-out-memory-error-7342266.html?cat=59

UWAGA: Ze względu na chwilową "pauzę" spowodowaną wykonaniem gc tak jest nie zaleca się robienia tego przed każdą alokacją bitmapy.

Optymalny projekt to:

1. Zwolnij wszystkie mapy bitowe, które nie są już potrzebne , zgodnie z if / recycle / nullwyświetlonym kodem. (Wymyśl metodę, która pomoże w tym).

2. System.gc();

3. Przydziel nowe mapy bitowe.

Jeśli otrzymasz OutOfMemoryError, zwykle jest za późno, aby zadzwonić do modułu odśmiecania pamięci ...

Oto cytat od programisty Androida:

W większości przypadków odśmiecanie odbywa się z powodu ton małych, krótkotrwałych obiektów, a niektóre odśmiecacze, takie jak generacyjne odśmiecacze, mogą zoptymalizować zbieranie tych obiektów, aby aplikacja nie była zbyt często przerywana. Moduł odśmiecania pamięci dla systemu Android nie jest niestety w stanie wykonać takich optymalizacji, a zatem tworzenie krótkotrwałych obiektów w ścieżkach kodu o krytycznym znaczeniu dla wydajności jest bardzo kosztowne dla aplikacji.

Tak więc, według mojego zrozumienia, nie ma pilnej potrzeby wzywania gc. Lepiej poświęcić więcej wysiłku na unikanie niepotrzebnego tworzenia obiektów (np. Tworzenia obiektów wewnątrz pętli)

Wygląda na System.gc()to, że nie działa na Art Android 6.0.1 Nexus 5x, więc Runtime.getRuntime().gc();zamiast tego używam .

Moja aplikacja zarządza wieloma obrazami i przestała działać z powodu błędu OutOfMemoryError. To mi pomogło. W pliku Manifest.xml Add

<application
....
   android:largeHeap="true"> 

Ogólnie rzecz biorąc, nie powinieneś wywoływać GC jawnie za pomocą System.gc (). Jest nawet wykład IO ( http://www.youtube.com/watch?v=_CruQY55HOk ), w którym wyjaśniają, co oznacza GC pauzy log, iw którym również stwierdzają, że nigdy nie wywołują System.gc (), ponieważ Dalvik wie lepiej niż ty, kiedy to zrobić.

Z drugiej strony, jak wspomniano w powyższych odpowiedziach, już proces GC w systemie Android (jak wszystko inne) jest czasami błędny. Oznacza to, że algorytmy Dalvik GC nie są na równi z JVM Hotspot lub JRockit i mogą czasami powodować błędy. Jedną z takich sytuacji jest przydzielanie obiektów bitmapowych. Jest to trudne, ponieważ używa pamięci Heap i Non Heap oraz ponieważ jedno luźne wystąpienie obiektu bitmapowego na urządzeniu z ograniczoną pamięcią wystarczy, aby uzyskać wyjątek OutOfMemory. Dlatego nazywanie go po tym, jak nie potrzebujesz już tej mapy bitowej, jest ogólnie sugerowane przez wielu programistów, a niektórzy nawet uważają je za dobrą praktykę.

Lepszą praktyką jest użycie .recycle () na mapie bitowej, ponieważ jest to cel tej metody, ponieważ oznacza ona pamięć natywną mapy bitowej jako bezpieczną do usunięcia. Należy pamiętać, że jest to bardzo zależne od wersji, co oznacza, że ​​będzie generalnie wymagane na starszych wersjach Androida (myślę, że Pre 3.0), ale nie będzie wymagane w późniejszych wersjach. Również nie zaszkodzi używanie go na nowszych wersjach ether (po prostu nie rób tego w pętli lub coś w tym stylu). Nowe środowisko wykonawcze ART bardzo się tutaj zmieniło, ponieważ wprowadzono specjalną „partycję” sterty dla dużych obiektów, ale myślę, że nie zaszkodzi to zrobić z ART ether.

Również jedna bardzo ważna uwaga na temat System.gc (). Ta metoda nie jest poleceniem, na które Dalvik (lub maszyny JVM) są zobowiązani odpowiedzieć. Potraktuj to bardziej tak, jakbyś powiedział do maszyny wirtualnej „Czy mógłbyś wykonać czyszczenie pamięci, jeśli nie jest to kłopotliwe”.

Najlepszy sposób na uniknięcie OOM podczas tworzenia mapy bitowej,

http://developer.android.com/training/displaying-bitmaps/index.html

Powiedziałbym nie, ponieważ programista dokumentuje stan użycia pamięci RAM :

...
GC_EXPLICIT

Jawny GC, na przykład gdy wywołujesz gc () (którego powinieneś unikać wywoływania i zamiast zaufać GC, aby uruchomić w razie potrzeby).

...

Pogrubioną czcionką zaznaczyłem odpowiednią część.

Przyjrzeć się serii YouTube Wzory Android Wydajność - pokaże wskazówki dotyczące zarządzania zużycie pamięci o aplikacji (takich jak korzystanie z Androidem ArrayMaps i SparseArrays zamiast HashMaps).

Krótka uwaga dla programistów Xamarin .

Jeśli chcesz dzwonić System.gc()w aplikacjach Xamarin.Android, powinieneś zadzwonićJava.Lang.JavaSystem.Gc()

Nie ma potrzeby wywoływania modułu odśmiecania pamięci po wykonaniu pliku OutOfMemoryError.

To Javadoc wyraźnie stwierdza:

Thrown when the Java Virtual Machine cannot allocate an object because it is out of memory, and no more memory could be made available by the garbage collector.

Zatem moduł odśmiecania już próbował zwolnić pamięć przed wygenerowaniem błędu, ale nie powiodło się.