Утечка памяти BitmapFont

#android #libgdx

#Android #libgdx

Вопрос:

Я использую BitmapFont следующим образом:

 create(){
    font = new BitmapFont(getFileResource("50.fnt"), getFileResource("50.png"),
            false);
}

dispose(){
font.dispose();
 }
 

У меня есть несколько экранов, которые загружают и выгружают шрифты разных размеров. С течением времени память заполняется.

Потратив много времени на поиски утечки памяти, я обнаружил, что этот класс BitmapFont протекает. Я думаю, что это утечка в собственной памяти, потому что утечка не обнаруживается с помощью анализатора памяти.

Я следую процедуре очистки памяти в соответствии с текущей документацией. Но этого недостаточно. Что еще я должен сделать, чтобы гарантировать, что BitmapFont освободит свою память?

Ответ №1:

Это может быть ошибкой. Здесь вы можете увидеть свой конструктор. И вот очень похожий. Разница в том, что 2-й устанавливает ownsTexture флаг. Только если этот флаг установлен, текстура удаляется.

Я создам проблему / PR, чтобы исправить эту проблему или, по крайней мере, заставить ее вести себя так же, или добавить предупреждение JavaDoc.

На данный момент вы можете решить эту проблему bitmapFont.setOwnsTexture(true) самостоятельно.

Комментарии:

1. Я только что заметил, что я был не совсем прав. Один конструктор пересылает другому, и оба устанавливают флаг. Однако затем вызываются два других конструктора, а 4-й возвращает флаг обратно false . Итак, если вы хотите, чтобы шрифт «владел» (и распоряжался) созданной текстурой, вам нужно установить флаг самостоятельно.

2. Нет, я думаю, что я совершенно неправ . Флаг устанавливается true в любом случае, когда вы вручную передаете дескриптор файла. Таким образом, на самом деле не должно быть утечки памяти.

Ответ №2:

Ошибка заключалась в том, что код libgdx выполняется долго, поэтому я не мог дождаться вызова dispose.

Итак, я вызывал dispose для элементов, которые больше не нужны на экране, из потока, отличного от GLThread (на Android)

Libgdx игнорирует функцию dispose(), если она не поступает из GLThread().

Добавление кода очистки при рендеринге таким образом, чтобы он запускался при накоплении устаревших компонентов, устранило проблему.