Svg или png android

SVG, Iconfonts vs PNG

Статья по мотивам Изображения в верстке. Хватит это терпеть. Скорее даже по мотивам комментариев к этой статье и в общем реакции хабра на призыв использования векторной графики везде, где можно и действительно нужно.

Признаться, я был немного удивлен реакцией на такие мысли в 2014-м то году. По этому случаю рассмотрим более детально существующие техники работы с иконками.

На текущий момент все более-менее просто. Мы можем верстать иконки с помощью SVG, создавать иконочные шрифты, ну и никуда не делась старая добрая техника с применением растра, в частности PNG. Правда добавились некоторые нюансы с появлением кучи HDPI устройств с совершенно разной плотностью пикселей.

Самую бурную реакцию вызвало именно применение SVG. Сначала юзер franzose заметил что:

Только вот вес у сложного вектора гораздо больше. И шансов подвесить браузер тоже

Так как в статье речь шла преимущественно о иконках — такой коммент для меня совершенно непонятен. Да, я сам несколько раз получал от дизайнера ужасные иконки, которые представляли собой нагромождение примитивов, налепленных друг на друга. Но ничего не мешает подойти к дизайнеру и сказать, — “что за херня, мужик?!”, ну или самому зафиксить это дело в том же иллюстраторе, объединив в какой-нибудь общий shape (ну это конкретно мой случай, других “сложных векторов” я не видел пока). Еще для этих целей можно использовать SVGO. Кажется объединение в общий shape — это единственная его часть, которая действительно драматически влияет на производительность.

На самом деле даже если забыть про все эти вещи с иконками — я не могу представить какого-нибудь хоть минимально часто встречающегося кейса про “сложный вектор”. Да все равно вектор, применительно к задачам сегодняшнего веба будет меньше растра (это про вес).

Все мы понимаем что есть задачи, где это все же случается, но в таких случаях разработчики думают несколько другими категориями. Нужно например отобразить какую-нибудь огромную, сложную схему на небольшой площади, ну и будет подход вроде “что-то SVG-ха под мегабайт у нас выходит, коллега, давайте ка мы ее на сервере растрируем”. Тайлы те же на картах.

Потом пришла куча юзеров и крайне негативно высказалась по части производительности SVG как такового. Дескать все катастрофически хреново, десктопный браузер на 3-х с половиной SVG безбожно тормозит на скролле, мобильные устройства взрываются в руках.

На самом деле я считал что абсолютно во всех браузерах SVG, прилепленный через background-image кэшируется по самое нехочу. Мы ведь именно об этом случае говорим? На практике все оказалось немного сложнее.

Я пообщался с парой людей, которые занимаются SVG частью в Chrome и Firefox и показал им вот это демо, которое Adrian Osmond делал еще год назад для, в принципе, таких же целей. Но тогда все было на порядки хуже. Почему, можно почитать в его статье и багтрекере вебкита.

Chrome

FPS проседает примерно раза в полтора, два. Печально конечно, но не 10x все же. Так что же происходит под капотом Хрома в этот момент?
Я немного почитал исходники на chromium.org, нашел кое-какой кэширующий код для SVG, и это меня запутало еще сильнее. Тут я решил спросить у знающих людей.

Philip Rogers из Google, который в общем то и пишет большую часть всяких дел с SVG в хромиуме, сказал что различия отрисовки SVG и PNG несколько сложнее. Во-первых PNG декодируется в отдельном потоке, а SVG в главном, а во-вторых помимо производительности есть еще такие вещи, как например, память. В общем они решили отказаться от хранения кэша для svg чтобы сэкономить памяти. Как по мне — так это какой-то сомнительный план. Не совсем понимаю почему бы не кэшировать все это дело. Bitmap, которым заканчивается рендер не будет каких-то неприличных размеров, с сегодняшними то объемами памяти, даже на мобильных устройствах. Ну и грядет же вектор, тема перспективная. Но видимо поэтому в Google работают они, а не я.

Так что да, в хроме SVG отсчитывается заново каждый фрейм. Правда Philip сказал что они там что-то придумали, что “should bring it much closer to png performance”. Будет в следующей Canary. Посмотрим. Тем не менее производительность на уровне чуть меньшем чем 60 FPS (а у меня в общем средний такой конфиг) на огромной куче иконок одновременно находящихся на экране — это вполне себе адекватная производительность.

Firefox

Я не знаю чем померить FPS в FF (видел какую-то софтину, но процесс инсталляции был не совсем тривиален и я не стал возиться), но на глаз производительность PNG и SVG одинаковая. Так же думает и Robert Longson, контрибьютор SVG в Firefox. По словам Роберта, в Firefox есть кэш для всех изображений и разница между SVG и PNG может заключаться разве что в том, что SVG немного дольше “декодируется” при первой отрисовке, что вполне закономерно.

Таким образом в FF мы вообще имеем идентичную производительность, если не производим каких-либо манипуляций инвалидирующих SVG кэш. Естественно, скролл ничего не инвалидирует. Возможно есть еще какие-то моменты, но драматически производительность они ухудшить не могут.

Новые IE часто бывают очень хороши во всяких неочевидных местах, например WebGL. Тут такая же ситуация. В IE демо работает намного лучше чем в 2-х предыдущих браузерах, показывает одинаковый framerate для SVG и PNG. Но делает это по каким-то магическим причинам не сразу.

К сожалению я не знаю кто занимается разработкой SVG в IE, а в багтрекер писать сомнительно как-то такие вещи, поэтому эта часть останется без комментариев с другой стороны.

По части вещей вроде SVGO — я отношусь к ним довольно скептически. Не знаю на какую долю процента ускорится рендер при немного более быстром парсинге, но на мой взгляд — это штука сомнительная. Т.е. конечно да, какой-то профит есть, но минимальный.

С практиками верстки SVG все более-менее понятно. Я предпочитаю рисовать SVG спрайты. Техника такая же как и для растровых спрайтов. Проблемы решаемые ими в принципе такие же. Естественно есть куча разных плагинов для этих целей, например вот.
Еще можно делать это с помощью data url. Тут я рекомендую вот такую штуку и их же софтину вот тут, для тех, в чей процесс Grunt по каким-то причинам не входит. Ну еще можно прям файлами на background-image, но не нужно.

Единственный современный браузер где я видел проблемы с рендерингом SVG — это IE на Windows Phone. Но там эта проблема решаема.

Iconfonts

Если в SVG мы в принципе можем нарисовать все что душе угодно, то с помощью шрифтов ограничены монохромными иконками (если не брать во внимание извращения вроде stackicons), что в рамках текущих веяний в дизайне не представляется таким уж недостатком. Зато перед нами открывается куча возможностей начиная от банальной смены цвета и размера, заканчивая пачкой CSS манипуляций с шрифтами, вроде тенюшек и т.д.

Техника с иконочными шрифтами сложнее чем те же SVG. Тут нужно обладать некоторым объемом знаний в областях, где не каждый дизайнер ориентируется. Казалось бы, делов то, запихай свои SVG-хи в один из кучи онлайн-упакавщиков типа того же Icomoon-а или настрой какой-нибудь Grunt\Gulp плагин, и будет тебе счастье.

В комментариях к статье главным обвинением относительно шрифтов было что-то вроде

рендеринг ужасный в мелких размерах (явные лесенки) (с) designiac

А что вы хотели, ребят? Нарисовать огромную иконку приблизительно кегля так 48-го, проработать мелкие детали, потом воткнуть ее кеглем так 12-м и вместо удивления о каком-то плохом рендере этих ужасных вебшрифтов, наслаждаться идеальными чистыми иконками?

Хинтинг!

Вот основная вещь, которую нужно знать про iconfonts. Вот он, святой грааль иконок в вебе! Я считаю что если вы точно знаете что скажем, цвет иконок или их размер не изменятся (вероятно бывает и такое), нужно брать SVG и не морочить голову. Использовать шрифты без необходимости — какой-то не очень критичный конечно, но все равно overhead.

Чтобы собрать годный шрифт нам понадобятся:

1. иконки в векторе
2. аналог icomoon-а
3. профессиональная штуковина для работы со шрифтами. Я использую FontLab Studio

Чтобы было понятно зачем нам это вообще нужно — вот такой пример: берем модный Font Awesome и одним хинтом делаем из вот такой иконки pinterest:

Лучше всего видно на мелком кегле, естественно.

С наступлением эры HDPI устройств заморачиваться с этими вещами фронтэндеру возможно скоро не придется вообще, потому что хинтировать глиф в такой ситуации:

немного сложнее чем в такой:

Я не тот человек, который может авторитетно написать о хинтинге, поэтому делать этого не буду. Буду рад если придет серьезный шрифтовик и напишет детальную статью. Нужно просто брать во внимание то, что он (хинтинг) существует. И это не шрифты криво рендерятся, это некоторые разработчики не хинтируют их совсем, или лепят автохинты (которые, надо сказать, неплохо спасают временами).

Субпиксельное сглаживание

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

Недостатки растровой графики с такой необходимостью учитывать HDPI устройства, какая есть сейчас — очевидны. Возможно, если бы плотность ограничивалась 2 вариантами ретина\не ретина — это было бы достойным вариантом, и мало кому в голову пришло бы заморачиваться со всеми неоднозначностями вектора, существующими сейчас в вебе. Но у нас есть 1.5x, 2x, 3x устройства. И собирать спрайты под каждое из них уже не кажется достаточно изящным вариантом.

С другой стороны у растра без потерь есть достоинство, которое, лично для меня, перекрывает все недостатки в обслуживании — он стабилен. Можно быть точно уверенным в том, что как ты иконку нарисуешь — так она и будет выглядеть в итоге. Пиксель в пиксель. Вопрос лишь в том, нужна ли такая точность в каждом конкретном случае.

Я работаю над системой мониторинга и управления всяким серьезным оборудованием, вроде электрических подстанций или котельных. У нас есть солидная пачка иконок, обозначающих те или иные неисправности на объектах. Причем иконки эти встречаются в разных местах, разного размера и разного цвета. И мы на самом деле убили бы кучу времени, если бы делали все это в PNG, еще и под HDPI.

В общем я не совсем понимаю зачем в текущих условиях однозначно отказываться от таких вкусных техник как шрифты, да и вектор в целом. Есть моменты конечно, вроде того же решения в хроме отказаться от кэша, но в целом с производительностью и качеством рендера все в порядке. А если перестать теоретизировать и глянуть на стандартные задачи, так вообще выйдет пара кейсов, где стоит посмотреть в сторону растра.

Так вот, зачем я все это написал? Я предлагаю юзерам, негативно отозвавшимся о производительности и рендере векторных иконок, в том посте, с которого все началось, или сочувствующих им и их точке зрения, пари.

Вы предоставляете мне верстку или какой-то конкретный сайт (что лучше), иконки на котором сейчас заверстаны в PNG и под ретину и под простые дисплеи, исходники иконок которого у вас есть в векторе, который при любых эффектах выдает 60FPS на средней машине. Сразу оговоримся что объективно это должен быть обычный сайт. Не онлайн софтина по работе с иконками и не пример из этой статьи.
Я заменяю растр на вектор и оптимизирую какими хочу способами.

В итоге должна получиться страница, на которой FPS проседает не больше, скажем, 30%. О дальнейших условиях договоримся в процессе. Как вам? Докажем ущербность SVG?

Источник

Используем векторные изображения SVG в приложениях Android, или как убить фрагментацию экранов и не потерять в качестве (плюсы, минусы, особенности)

Достаточно долгое время мы занимаемся разработкой детских приложений под Android, постепенно постигая множество нюансов этой платформы. Есть одни грабли, которые подстерегают нас в каждом приложении, – это фрагментация экранов. Если делать одно изображение только под телефон маленького размера, то на планшете оно выглядит мягко говоря “не очень”. А если делать изображение высокого разрешения для планшетов и пытаться использовать его на телефонах, то с очень большой вероятность приложение вывалится с OutOfMemory.

Приходится готовить несколько экземляров одного и того же изображения под разные экраны. Еще сильнее облака сгущает новый монстр Galaxy Nexus 10 с безумным разрешением 2560х1600.

В общем, неплохо бы что-то изменить, решили мы. А что если использовать в приложениях не растровые изображения, а векторные? Такие изображения легко масштабируются под разные разрешения экранов, при этом не теряя в качестве. Можно использовать всего одно изображение под разные разрешения и размеры.

Сказано — сделано. Итак, под катом история внедрения векторных изображений в одно из наших приложений. В статье мы поделимся опытом и особенностями использования векторных изображений в формате SVG в приложениях Android.

Немного погуглив, выяснили, что векторные изображения для web и приложений обычно используются в формате SVG. С данным форматом работают векторные редакторы Adobe Illustrator и Inkscape. Вооружившись Inkscape, нарезали пробных картинок и принялись искать способы их загрузки и отображения в приложении Android.
Разбираться с устройством формата SVG и писать свой парсер не хотелось — наверняка же люди сталкивались с этим и до нас! Что ж, гуглим «android svg».
В итоге есть:

• 2 проекта на гуглокоде:
  code.google.com/p/svg-android
  code.google.com/p/svg-android-2
• подробная статья с использование NDK:
  horribileru.blogspot.ru/2011/10/android-imageview-svg.html
• и несколько ссылок на мертвые проекты на разных форумах.

Берем самый популярный — SVG-Android (он, кстати, переехал на Github, но новых коммитов там нет). Подключаем библиотеку, векторное изображение помещаем в res/raw, загружаем её и устанавливаем ее во вьюшку:

Загружаем тестовый проект с изображениями — всё отлично! Подключаем наши изображения — пусто. Как оказалось, данная библиотека поддерживает только формат SVG basic 1.1, который не поддерживается Inkspace, а рождается только в Adobe Illustrator.

Пробуем вторую библиотеку SVG-Android-2, которая является форком первого проекта и ушла чуть-чуть дальше.
Она уже понимает Inkscape, а также поддерживает другие фишки этого формата, о чем можно почитать тут. Здесь всё пошло проще, картинки загрузились и выглядели шикарно и на телефоне, и на планшете. На нем мы и остановились.

Пример SVG-изображения и неадаптированного по размеру под планшет PNG-изображения на планшете.
(просмотреть изображение в оригинальном размере 1280х800)

Первое — SVG (10 Кб), второе — PNG (22 Кб). Второе изображение имеет размытый контур и ступенчатый градиент

Масштабирование изображений

Изображения масштабируются только с сохранением пропорций. Поэтому использовать их в качестве фона, который может немного менять пропорции на разных разрешениях, не получится. В этом случае мы обычно делаем какое-то абстрактное изображение в PNG, которое довольно легко меняет свои пропорции для разных экранов.

Не забываем для SVG устанавливать свойство аdjustViewBounds в значение true, иначе изображение может рассчитывать свои границы не так, как вы задумали.

Размер изображений с тенями и подсветками

Некоторые элементы в нашем приложении изначально были отрисованы с небольшими тенями и подстветками — например, этот смайлик имеет серую подсветку сзади. Но это приводит к колоссальному увеличению размера файла SVG. 118 Кб против 1 Кб без этой подсветки. Чем больше размер файла — тем больше времени надо на его загрузку в программе, поэтому мы решили отказаться от этого эффекта.

Изорбражения с тенью и без: 118 Кб vs 1 Кб

Подсветку можно отключить или в графическом редакторе, или же прямым редактированием SVG-файла — удаляем тэг с огромным содержимым.

Отображение градиентов

На некоторых изображениях вдруг обнаружились черные пятна вместо фона. Оказалось, что градиент не поддерживается!
Проблема с градиентами решилась удалением лишних тэгов из svg (описано далее в статье). Но в принципе, и с этим можно было бы жить и в наших простых изображениях заменить градиент однородной заливкой, если бы не другой нюанс — значительное время загрузки изображений.

Вот как это выглядело на экране: слева — черное небо в виде градиента, справа — корректная картинка.

Время загрузки изображений

В приложении нужно было по 6 изображений на одной странице ViewPager, а поскольку они подгружаются в процессе прокрутки (если не кэшировать), интерфейс заметно дергался при скроллинге. Этого очень не хотелось, и было решено загружать все изображения при старте приложения. Получили время инициализации порядка 8 секунд, что было слишком долго.

В проблеме решили разобраться. Выкачали исходники проекта SVG-Android-2 и стали искать, что именно так тормозит. Оказалось, что в классе SVGParser XML-файл изображения парсится дважды: первый раз он собирает информацию о дополнительных атрибутах, которые используются при втором проходе. И, что самое интересное, — анализируется лишь атрибут xlink:href, который является некоторым подобием гиперссылок внутри самого документа. В наших проблемных изображениях как раз были такие ссылки, и вели они никуда. После того, как мы избавились от данных ссылок, отредактировав код SVG в некоторых изображениях, градиент стал корректно отображаться. Более того, убрав этот предварительный проход и немного оптимизирорав процесс загрузки, мы смогли уменьшить скорость загрузки с 8 секунд до 1,8-2. Следует заметить, что это соизмеримо с PNG среднего размера — загрузка этих же изображений в память заняла 1,7 секунд.

Ниже приведено сравнение загрузки 35 файлов в формате SVG и PNG.

SVG	PNG( 500×500)
Размер, КБ	327	943
Время загрузки, с	1,9	1,7

Прозрачность и цветовые фильтры

Часто в играх мы используем полупрозрачные картинки для неактивных элементов. В этом проекте помимо прозрачности нужны были цветовые фильтры для генерации элементов в играх, то есть чтобы один элемент можно было использовать один раз, но, раскрашивая его по-разному, мы получали бы разные элементы.

Оказалось, что ни alpha, ни colorFilter мы применить не сможем, т.к. библиотека загружает не типичные bitmapDrawable, а pictureDrawable, и в исходниках Android мы видим пустые методы для этого класса:

До этого с классом pictureDrawable никогда не сталкивались, и это было большой неожиданностью.

Опять покопавшись в исходниках библиотеки, мы нашли в классе SVGHandler поле fillPaint типа Paint, которым рисуются все компоненты. Если до загрузки элемента ему установить colorFilter, то он будет работать как положено. Нас это вполне устраивало, поэтому мы чуть-чуть изменили метод загрузки SVG, добавив возможность передавать туда цвет фильтра, который при необходимости устанавливается перед загрузкой изображения. Теперь изображения загружались так:

А в самом SVGHandler появился такой метод:

В итоге мы смогли получать из одной картинки сколько угодно изображений разных оттенков.

Также можно установить и Alpha для fillPaint, но в играх это свойство требуется в динамической форме (нажали на элемент — сделался полупрозрачным), и подгружать каждый раз новое изображение неудобно. Поэтому этот эффект заменили масштабированием (нажали — элемент уменьшился).

Нюанс с принудительной обработкой GPU

После запуска приложения к нам стали такие поступать ошибки:

Оказалось, что если на устройстве включена настройка “Принудительная обработка GPU” (Developer options — Force GPU Rendering), то наше приложение валится, т.к. метод drawPicture() у Canvas не поддерживает аппаратное ускорение. Об этом можно почитать на android developer.
Причем простое указание в манифесте android:hardwareAccelerated=«false» проблему не решает — пользовательская галочка в настройках имеет более высокий приоритет.

Было найдено довольно простое решение: для всех view, которые работают с нашими pictureDrawable, полученными из SVG, отключить аппаратное ускорение.
Так как функция аппаратного ускорения появилась в Аndroid 3.0 (api 11), то для работы с этим функционалом пришлось изменить target sdk нашего проекта с 8 на 11. И, конечно же, надо помнить про обратную совместимость — на более ранних платформах этих методов нет.

Выводы

Давайте подведем краткий итог работы с векторными изображениями в формате SVG в Android.

Плюсы:

• Один огромный плюс, из которого следуют все остальные, — это одна векторная картинка.
• Так как картинка векторная, она отлично отображается на всех размерах экранов.
• Размер SVG-картинок мал.
• Одна картинка используется несколько раз для разных разрешений.
• Сокращается процесс подготовки изображений для приложения.

Минусы:

• Картинки масштабируются только пропорционально.
• Не поддерживается прозрачность.
• Графику нужно упрощать — чем больше векторных элементов, тем больше весит файл.Нежелательно использовать тени и свечения, так как это в разы увеличивает размер SVG-файлов.

В результате экспериментов с SVG родилось приложение для детей “Учим формы и фигуры”. Ознакомится с приложением можно в Google Play:
play.google.com/store/apps/details?id=com.whisperarts.kids.forms
Количество получившихся изображений:

• PNG — 3 (сплэшскрин и 2 фона для меню);
• SVG-элементов — 97;
• Размер приложения 3,5 Мб.

В сравнении с почти похожим по функционалу нашим приложением “Учим цвета” (размер которого 8 Мб) выигрыш более 50% налицо.

Для себя мы приняли решение использовать SVG-изображения в наших приложениях, так как это существенно ускоряет процесс разработки и адаптации картинок под разные разрешения экранов, а также существенно уменьшает вес приложения.

Надеемся, опыт, которым мы поделились в статье, поможет вам также пересмотреть процесс подготовки изображений для приложений и задуматься над использованием формата SVG.

PS: Если вы уже использовали SVG в своих проектах или по другому обходили проблемы, с которыми столкнулись мы при использовании SVG — пишите в комментариях. Будем рады услышать Ваш опыт.

Источник