Pull to refresh

Comments 10

UFO just landed and posted this here
UFO just landed and posted this here
Замечание про Handler. Eсли нет необходимости обрабатывать свои Messages, и надо что-то сделать в UI потоке, то предпочтительней использовать runOnUiThread() или сделать синглтон на базе MainLooper для отвязки от контекста. Если наплодить много Handler-ов и Looper-ов, то можно словить ANR из-за глобального synchronize в методе обработки очереди сообщений. Этой проблеме уже много-много лет.
хорошо, спасибо за замечание
VectorDrawable не даст экономии памяти по сравнению с обычным ImageView, т.к. после рендеринга векторной графики в растровую картинку результат помещается в кэш и при отрисовке виджета картинка берётся из кэша.

VectorDrawable имеет смысл применять только для экономии конечного размера APK-файла для больших картинок (если не использовать Bundle), и сокращения времени работы дизайнера, которому не нужно будет рендерить пять размеров каждой иконки.

При всех возможных плюсах у векторной графики есть существенный недостаток — сложно сделать pixel-prefect картинку, особенно маленького размера, которая будет нормально отображаться на всех разрешениях. Особенно страдает hdpi-плотность с 1.5 пикселем относительно базового mdpi.

во многом согласен с вами, но как вы тогда объясните скриншоты из профайлера с показателями занятой памяти?

Разница возможно в том, что для растра в памяти сидит bitmap, который система держит про запас (особенно, начиная с 8.0), и кеш для ImageView, в который bitmap отрисовался. А для вектора нет bitmap`а, а есть только кеш для ImageView.

Если вручную отрисовать битмап, например, на Canvas, а потом тут же освободить через recycle, то возможно сборщик мусора его тут же и приберёт.

И есть такая фича в новых версиях андроида, — если выделили вам разом 10Мб, то после освобождения отбирать их сразу не будут.

Спасибо за объяснение) По всей видимости, вектор занимает меньше места из-за каких-то багов/недоработок студии, но почему бы это не использовать? Потому и включил векторную графику в свой список

В конечном итоге все картинки, что из пиксельных файлов, что из векторных попадают на экран в виде OpenGL-текстур. Для скорости перерисовки виджетов в onDraw() картинки хранятся в виде битмапов, которые создаются в Native-коде, для которого у вас показываются одинаковые значения 2.8 Мбайт. Куда уходят мегабайты в Java-объектах надо смотреть в профилировщике более подробно.

Попробуйте провести эксперимент: отображать не одну картинку, а сразу штук сто в одном ScrollView/LinearLayout, загружая их все из разных файлов, чтобы они гарантированно брались каждая из своего кэша и все отображались на экране при скролле. Для чистоты эксперимента можно использовать одни и те же лейауты, меняя только src в ImageView. Так же стоит задать одинаковый исходный размер растровой и векторной картинок где-нибудь в 256px и размер ImageView тоже в 256px, чтобы битмапы не масштабировались. Одна картинка 256x256x4 будет занимать 256к, разница потребления памяти между одной такой картинкой и сотней будет явно заметна.

Заодно сравните скорость распаковки растровых картинок из PNG-файла и рендеринга компилированных векторных картинок, особенно, если они достаточно сложные.
Sign up to leave a comment.

Articles