Вообще говоря, вы не должны вызывать GC явно с System.gc ().Есть даже лекция IO (http://www.youtube.com/watch?v=_CruQY55HOk)), в которой они объясняют, что означает журнал пауз GC и в котором они также утверждают, что никогда не вызывают System.gc (), потому что Dalvik знает лучше, чем вы, когда это делать.
С другой стороны, как уже упоминалось выше, ответы на GC-процессы в Android (как и все остальное) уже иногда содержат ошибки. Это означает, что алгоритмы Dalvik GC не совпадают с JVM Hotspot или JRockit и могут иногда ошибаться.в таких случаях это происходит при выделении растровых объектов. Это сложный вопрос, поскольку он использует память Heap и Non Heap, а также потому, что одного свободного экземпляра растрового объекта на устройстве с ограниченным объемом памяти достаточно, чтобы создать исключение OutOfMemory.Мне больше не нужен этот растровый образ, как правило, многие разработчики рекомендуют его, а некоторые даже считают его хорошей практикой.
Лучшей практикой является использование .recycle () для растрового изображения, поскольку именно для этого и создан этот метод,поскольку он отмечает собственную память растрового изображения как безопасную дляудалять.Имейте в виду, что это очень зависит от версии, то есть обычно требуется в старых версиях Android (я думаю, до версии 3.0), но не требуется в более поздних.Также это не повредит, если использовать его в более новых версиях эфира (только не делайте это в цикле или что-то в этом роде).Новая среда выполнения ART сильно изменилась, потому что она ввела специальный «раздел» Heap для больших объектов, но я думаю, что это не помешает сделать это с помощью эфира ART.
Также одно очень важное замечание о System.gc (),Этот метод не является командой, на которую Dalvik (или JVM) обязаны отвечать.Считайте, что это больше похоже на высказывание виртуальной машине: «Не могли бы вы собрать мусор, если это не хлопотно».