Android ручное освобождение объекта - PullRequest
Новая
       12

Android ручное освобождение объекта

3 голосов
/ 24 августа 2011

Я прочитал Руководство разработчика Android по проектированию для повышения производительности.

Мне просто интересно, что если у меня есть большой объект, который я не могу избежать (что дорого), кажется логичным, что я хочунемедленно освободите его, когда я узнаю, что с этим покончено.

Кажется, что это невозможно.

Некоторые предлагают установить его в ноль, чтобы система немедленно установила GC,это будет действительно "немедленно"?Потому что, если система (Dalvik VM) имеет возможность НЕ освобождать большой объект, который я только что установил в null, то установка его в null вовсе не является решением.

Правильно ли говорить, что его установкаобнулит ли ENCOURAGE и SPEED up GC?

Является ли этот подход "достаточно хорошим" способом оптимизации производительности приложений?Или стоит пройти лишнюю милю (если это вообще возможно), чтобы заставить GC, когда это применимо, выжать лучшую производительность из любого устройства Android?

Ответы [ 2 ]

4 голосов
/ 24 августа 2011

Я не думаю, что вам следует беспокоиться о детализации при выполнении GC, так как мы не можем контролировать, когда вызывается gc.Даже вызов gc () не гарантирует коллекцию.Согласно документации от System.gc ()

Указывает виртуальной машине, что сейчас самое время запустить сборщик мусора.Обратите внимание, что это только подсказка.Нет никаких гарантий, что сборщик мусора действительно будет запущен.

При разработке приложения с выделением больших объектов вместо этого я бы беспокоился о следующем:

  1. При выделении большого объекта и впоследствии после выхода из области его жизненного цикла.объект, могу ли я увидеть, что он будет восстановлен GC в последующих действиях?Это можно легко проверить, запустив dumpsys meminfo с оболочкой adb.После освобождения вы, в основном, проверяете, правильно ли организована сборка мусора, обычно это происходит с большим всплеском и затем сбрасывается
  2. Проверьте, имеет ли этот большой объект свободный путь к GC.Вы можете сделать это, проверив ссылочный путь к этому объекту, выгрузив hprof и проверив его в Memory Analyzer.Если это произойдет, вы в безопасности, поскольку GC будет достаточно умен, чтобы собирать.
  3. После того, как я выделю этот большой объект, достаточно ли в моей куче отступов для выполнения последующих действий?Если объект слишком большой, есть вероятность, что сборщик мусора не будет достаточно быстрым, чтобы собрать его (это на самом деле связано с вашей точкой зрения), и потребление памяти при последующей деятельности в сочетании с остатком от предыдущих может фактически вызватьошибка памятиУстановка нулевого значения с четким путем к GC поможет гарантировать, что этот объект получит GC'ы соответствующим образом.Я признаю, что это проблема, но, на мой взгляд, если это станет проблемой, нам, возможно, придется пересмотреть вопрос о том, как устроен этот конкретный раздел, и посмотреть, можно ли оптимизировать его.
  4. Выполнить очисткупри необходимости выполняйте действие через onDestroy и убедитесь, что другие не ссылаются на действие, чтобы он мог правильно собирать мусор.Например: мы часто передаем контекст активности, забывая, что он будет содержать свою ссылку.Такие вещи, как вызов recycle () для растрового изображения, также должны помочь.Запоминание этих пунктов должно помочь подготовить больше места в случае, если # 3 произойдет
2 голосов
/ 24 августа 2011

Большую часть времени Android хорошо справляется со сборкой мусора.Я не буду беспокоиться об этом, если вы не начнете получать OutOfMemoryError.

Но если вы действительно беспокоитесь об этом, установка объекта в null и последующий вызов System.gc (), скорее всего, вызовут его сбор.

...