Pull to refresh

Comments 26

Для меня это очень болезненная тема (работа с Bitmap) в Android! В своем приложении я давно с ней борюсь. Сейчас я полностью отказался от «bmp.recycle()» и хранения жестких ссылок на Bitmap, только WeakReference.
Хотелось бы узнать Вы пробовали данный метод на «боевых» приложениях в маркете?
Да.
Cool Reader — 1.7млн загрузок, 800000 активных инсталляций.

спасибо за статью и за приложение :-)
Скажите пожалуйста, как это сказывается на производительности системы? Как затрагивает другие приложения? Будет ли высвобождена эта память?
Интересный момент, как эта память высвободится при закрытии приложения: штатном, аварийном?
Интересный момент, как приложение будет вести себя под различными версиями android.
По крайней мере, работает на Android с 1.5 по 4.0
Проблем не замечено
Хак работает на всех версиях, кроме 3.0 и выше, протестировал. На 3.0 битмапы внесли в память программы, наверное из-за этого.
Спасибо, не знал.

Надо что-то придумать и для 3.0+
10Mb это ну очень мало…
Для 4+, с 3+ работает нормально.
Если бы нормально работало, с хаком должно 48Мб взять.
Хак не работает. Просто, видимо, прошивка для симулятора собрана с бОльшим размером хипа на приложение.
на девайсе 4.0.3
normally: 38 MB allocated
with hack: 38 MB allocated

на эмуляторе 4.0.3
normally: 10 MB allocated
with hack: 10 MB allocated

на эмуляторе 3.0
normally: 41 MB allocated
with hack: 41 MB allocated

на эмуляторе 2.3.3
normally: 9 MB allocated
with hack: 48 MB allocated
Начиная с 3.0 ,bitmaps выделяются в одном и том же хипе с стандартными объектами
до этого был отдельный.

Хак не должен работать чисто технически
При закрытии приложения память освободится автоматически — вместе с закрытием виртуальной машины.
Полностью эквивалентно тому, что память заняла JNI-библиотека.
Если съесть слишком много памяти, могут быть затронуты другие работающие приложения.
Например, будут закрыты те фоновые приложения, которые в другом случае остались бы висеть в фоне.
Я так понимаю, что данные нароботки использованы в CoolReader?
Если да, то можно сказать, что технология работает отлично, потому что падений CoolReader я не замечал.
Правда были проблемы с отображением страниц (черный цвет) в Nook Touch, так что интересно узнать.
Да, только так удалось заставить CoolReader работать на некоторых устройствах с большим экраном.
Для решения аналогичной проблемы разместил большие картинки в assets/img и работаю с ними напрямую через BitmapFactory.decodeStream().
Далее проверяю и сравниваю размеры изображения и размеры экрана. Если первые больше вторых, уменьшаю картинку:
Bitmap.createScaledBitmap()

Такой подход избавляет от зоопарка картинок для разных размеров экранов и не забивает память. По окончанию использования, высвобождаю память.
Спасибо за способ — тоже очень актуальна эта проблема, обязательно попробую у себя.

Кстати, через JNI можно без каких-либо последствий для системы занять примерно 13% от всей памяти устройства — после достижения этого предела начинают убиваться фоновые процессы.
Словил похожие грабли при попытке создать полноэкранную анимацию из нескольких десятков фреймов (размером ~640*480). Падало с нехваткой памяти на 11-м кадре.
В итоге, решил проблему загрузив картинки в качестве текстур в OpenGL, теперь 40 кадров поместилось в память отлично.
Можете по подробнее расписать ваше решение?
Как загружать, как использовать?
Это тема для целой статьи, если в двух словах, то:
В OpenGL окружении создается полигон с текстурой, в память OpenGl грузим все фреймы анимации в виде текстур (256*256 или 512*512, размер должен быть обязательно кратный степени 2) соотношение стороно задается не размерами текстуры а размерами полигона, далее в зависимости от необходимой скорости анимации, переключаем текстуры на полигоне через заданные промежутки времени.
Перед выходом со страницы или смены анимации на другую, очищаем GL память от прошлого набора текстур.
Спасибо! А где можно об этом почитать или посмотреть примеры?
Sign up to leave a comment.

Articles