Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 10
Замечание про Handler. Eсли нет необходимости обрабатывать свои Messages, и надо что-то сделать в UI потоке, то предпочтительней использовать runOnUiThread() или сделать синглтон на базе MainLooper для отвязки от контекста. Если наплодить много Handler-ов и Looper-ов, то можно словить ANR из-за глобального synchronize в методе обработки очереди сообщений. Этой проблеме уже много-много лет.
VectorDrawable не даст экономии памяти по сравнению с обычным ImageView, т.к. после рендеринга векторной графики в растровую картинку результат помещается в кэш и при отрисовке виджета картинка берётся из кэша.
VectorDrawable имеет смысл применять только для экономии конечного размера APK-файла для больших картинок (если не использовать Bundle), и сокращения времени работы дизайнера, которому не нужно будет рендерить пять размеров каждой иконки.
При всех возможных плюсах у векторной графики есть существенный недостаток — сложно сделать pixel-prefect картинку, особенно маленького размера, которая будет нормально отображаться на всех разрешениях. Особенно страдает hdpi-плотность с 1.5 пикселем относительно базового mdpi.
VectorDrawable имеет смысл применять только для экономии конечного размера APK-файла для больших картинок (если не использовать Bundle), и сокращения времени работы дизайнера, которому не нужно будет рендерить пять размеров каждой иконки.
При всех возможных плюсах у векторной графики есть существенный недостаток — сложно сделать pixel-prefect картинку, особенно маленького размера, которая будет нормально отображаться на всех разрешениях. Особенно страдает hdpi-плотность с 1.5 пикселем относительно базового mdpi.
во многом согласен с вами, но как вы тогда объясните скриншоты из профайлера с показателями занятой памяти?
Разница возможно в том, что для растра в памяти сидит bitmap, который система держит про запас (особенно, начиная с 8.0), и кеш для ImageView, в который bitmap отрисовался. А для вектора нет bitmap`а, а есть только кеш для ImageView.
Если вручную отрисовать битмап, например, на Canvas, а потом тут же освободить через recycle, то возможно сборщик мусора его тут же и приберёт.
И есть такая фича в новых версиях андроида, — если выделили вам разом 10Мб, то после освобождения отбирать их сразу не будут.
Если вручную отрисовать битмап, например, на Canvas, а потом тут же освободить через recycle, то возможно сборщик мусора его тут же и приберёт.
И есть такая фича в новых версиях андроида, — если выделили вам разом 10Мб, то после освобождения отбирать их сразу не будут.
В конечном итоге все картинки, что из пиксельных файлов, что из векторных попадают на экран в виде OpenGL-текстур. Для скорости перерисовки виджетов в onDraw() картинки хранятся в виде битмапов, которые создаются в Native-коде, для которого у вас показываются одинаковые значения 2.8 Мбайт. Куда уходят мегабайты в Java-объектах надо смотреть в профилировщике более подробно.
Попробуйте провести эксперимент: отображать не одну картинку, а сразу штук сто в одном ScrollView/LinearLayout, загружая их все из разных файлов, чтобы они гарантированно брались каждая из своего кэша и все отображались на экране при скролле. Для чистоты эксперимента можно использовать одни и те же лейауты, меняя только src в ImageView. Так же стоит задать одинаковый исходный размер растровой и векторной картинок где-нибудь в 256px и размер ImageView тоже в 256px, чтобы битмапы не масштабировались. Одна картинка 256x256x4 будет занимать 256к, разница потребления памяти между одной такой картинкой и сотней будет явно заметна.
Заодно сравните скорость распаковки растровых картинок из PNG-файла и рендеринга компилированных векторных картинок, особенно, если они достаточно сложные.
Попробуйте провести эксперимент: отображать не одну картинку, а сразу штук сто в одном ScrollView/LinearLayout, загружая их все из разных файлов, чтобы они гарантированно брались каждая из своего кэша и все отображались на экране при скролле. Для чистоты эксперимента можно использовать одни и те же лейауты, меняя только src в ImageView. Так же стоит задать одинаковый исходный размер растровой и векторной картинок где-нибудь в 256px и размер ImageView тоже в 256px, чтобы битмапы не масштабировались. Одна картинка 256x256x4 будет занимать 256к, разница потребления памяти между одной такой картинкой и сотней будет явно заметна.
Заодно сравните скорость распаковки растровых картинок из PNG-файла и рендеринга компилированных векторных картинок, особенно, если они достаточно сложные.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
OutOfMemory и использование векторных изображений в Android Studio