Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 26
Для меня это очень болезненная тема (работа с Bitmap) в Android! В своем приложении я давно с ней борюсь. Сейчас я полностью отказался от «bmp.recycle()» и хранения жестких ссылок на Bitmap, только WeakReference.
Хотелось бы узнать Вы пробовали данный метод на «боевых» приложениях в маркете?
Хотелось бы узнать Вы пробовали данный метод на «боевых» приложениях в маркете?
Скажите пожалуйста, как это сказывается на производительности системы? Как затрагивает другие приложения? Будет ли высвобождена эта память?
Интересный момент, как эта память высвободится при закрытии приложения: штатном, аварийном?
Интересный момент, как приложение будет вести себя под различными версиями android.
По крайней мере, работает на Android с 1.5 по 4.0
Проблем не замечено
Проблем не замечено
Хак работает на всех версиях, кроме 3.0 и выше, протестировал. На 3.0 битмапы внесли в память программы, наверное из-за этого.
на девайсе 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
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 я не замечал.
Правда были проблемы с отображением страниц (черный цвет) в Nook Touch, так что интересно узнать.
Для решения аналогичной проблемы разместил большие картинки в assets/img и работаю с ними напрямую через BitmapFactory.decodeStream().
Далее проверяю и сравниваю размеры изображения и размеры экрана. Если первые больше вторых, уменьшаю картинку:
Bitmap.createScaledBitmap()
Такой подход избавляет от зоопарка картинок для разных размеров экранов и не забивает память. По окончанию использования, высвобождаю память.
Далее проверяю и сравниваю размеры изображения и размеры экрана. Если первые больше вторых, уменьшаю картинку:
Bitmap.createScaledBitmap()
Такой подход избавляет от зоопарка картинок для разных размеров экранов и не забивает память. По окончанию использования, высвобождаю память.
Архив с исходным кодом примера можно скачать здесь
Спасибо за способ — тоже очень актуальна эта проблема, обязательно попробую у себя.
Кстати, через JNI можно без каких-либо последствий для системы занять примерно 13% от всей памяти устройства — после достижения этого предела начинают убиваться фоновые процессы.
Кстати, через JNI можно без каких-либо последствий для системы занять примерно 13% от всей памяти устройства — после достижения этого предела начинают убиваться фоновые процессы.
Спасибо, очень полезная статья.
Словил похожие грабли при попытке создать полноэкранную анимацию из нескольких десятков фреймов (размером ~640*480). Падало с нехваткой памяти на 11-м кадре.
В итоге, решил проблему загрузив картинки в качестве текстур в OpenGL, теперь 40 кадров поместилось в память отлично.
В итоге, решил проблему загрузив картинки в качестве текстур в OpenGL, теперь 40 кадров поместилось в память отлично.
Можете по подробнее расписать ваше решение?
Как загружать, как использовать?
Как загружать, как использовать?
Это тема для целой статьи, если в двух словах, то:
В OpenGL окружении создается полигон с текстурой, в память OpenGl грузим все фреймы анимации в виде текстур (256*256 или 512*512, размер должен быть обязательно кратный степени 2) соотношение стороно задается не размерами текстуры а размерами полигона, далее в зависимости от необходимой скорости анимации, переключаем текстуры на полигоне через заданные промежутки времени.
Перед выходом со страницы или смены анимации на другую, очищаем GL память от прошлого набора текстур.
В OpenGL окружении создается полигон с текстурой, в память OpenGl грузим все фреймы анимации в виде текстур (256*256 или 512*512, размер должен быть обязательно кратный степени 2) соотношение стороно задается не размерами текстуры а размерами полигона, далее в зависимости от необходимой скорости анимации, переключаем текстуры на полигоне через заданные промежутки времени.
Перед выходом со страницы или смены анимации на другую, очищаем GL память от прошлого набора текстур.
Спасибо! А где можно об этом почитать или посмотреть примеры?
4 лучших урока с азами по OpenGl для Android из тех что я видел
www.jayway.com/2009/12/03/opengl-es-tutorial-for-android-part-i/
www.jayway.com/2009/12/03/opengl-es-tutorial-for-android-part-i/
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Android SDK: боремся с ограничением размера памяти для картинок