#android #drawable #scaling #assets
#Android #можно рисовать #масштабирование #активы
Вопрос:
Я хочу создать фоновое изображение для viewgroup в приложении для Android, и я не уверен, что лучше всего делать с этим ресурсом.
Проще ли (читай: выглядит лучше на большинстве телефонов) просто предоставить ресурс в виде 900×570 или там около и позволить Android автоматически масштабировать его вверх и вниз или масштабировать его самостоятельно в Photoshop и предоставлять эти изображения в папках 3 drawable-ldpi , drawable-mdpi , и drawable-hdpi ?
Экономия места будет настолько мала: около 10-20 тыс., что мне кажется более разумным просто позволить Android масштабировать изображения самостоятельно.
Целевой API будет на уровне 2.0 и выше, и планшеты изначально не поддерживаются.
Комментарии:
1. Точно ли известны масштабируемые размеры? Если нет, их все равно нужно будет масштабировать, и наилучшее качество будет получено, если начинать с самого большого оригинала.
2. @MarkRansom Я собирался использовать самые распространенные размеры разрешения для каждого dpi, поэтому hpi я бы придерживался 854, mdpi 320×480. Насколько я могу судить, только два телефона с 2.x имеют экраны ldpi
Ответ №1:
Очевидно, что с точки зрения разработчика проще позволить Android масштабировать изображения для вас, но на большинстве телефонов это выглядит не лучше. По моему опыту, Photoshop имеет лучшие алгоритмы масштабирования, чем Android.
Комментарии:
1. 1 за указание на то, что изображения, масштабируемые Android, могут выглядеть нерезкими или могут быть слишком четкими, в основном иногда это выглядит совсем не хорошо
2. Верно, но я должен добавить: разработчику еще проще создать сценарий генерации этих изображений с учетом специфики плотности из приличного (векторного, если возможно) мастер-файла… Руководство по пользовательскому интерфейсу developer.android.com/guide/practices/ui_guidelines/index.html для меня все ясно (особенно руководство по дизайну иконок, которое можно экстраполировать)
Ответ №2:
если вы укажете только одно изображение копии в любом из drawable, drawable-ldpi, drawable-mdpi и drawable-hdpi, android по умолчанию масштабирует его для вас
однако рекомендуется использовать изображения разного размера по соображениям производительности
Комментарии:
1. Я согласен с Optimus, лучше всего предоставлять чертежи с измененным размером… Более того, просто ничего не нужно делать в скрипте для пакетной регенерации ваших чертежей из источников, если это необходимо (я делаю это сам, чтобы конвертировать pdf master в hdpi, ldpi, mdpi растровые значки, например)… Вы могли бы использовать ImageMagick… Это не вопрос размера, а скорее вопрос производительности и рендеринга.
2. Это то, что я имел в виду: предполагается, что ваш ресурс по умолчанию равен mdpi, но на самом деле имеет высокий dpi, и поэтому масштабирование не размывается / не делится на пиксели
3. Вы можете подумать, что из-за того, что вы уменьшаете масштаб, а не увеличиваете, он всегда будет выглядеть хорошо, но, как ни странно, уменьшение масштаба иногда может привести к визуальным артефактам, и алгоритм, который вы используете, может иметь большое значение.
Ответ №3:
Это проще, но имеет свои издержки с точки зрения производительности.
Если целевая плотность известна, будет лучше записать все необходимые преобразования для ваших значков / заставок / изображений и забыть об этом до следующего изменения ваших мастеров… бесплатно…
Вот пример использования ImageMagick для моих значков и listview eye-candies из pdf masters:
#!/bin/bash
convert -transparent white ic_padlock.pdf ic_padlock.png
convert -scale 36x36 ic_padlock.png ../../res/drawable-ldpi/ic_launcher_padlock.png
convert -scale 48x48 ic_padlock.png ../../res/drawable-mdpi/ic_launcher_padlock.png
convert -scale 72x72 ic_padlock.png ../../res/drawable-hdpi/ic_launcher_padlock.png
convert -scale 24x24 ic_padlock.png ../../res/drawable-ldpi/ic_listview_padlock.png
convert -scale 32x32 ic_padlock.png ../../res/drawable-mdpi/ic_listview_padlock.png
convert -scale 48x48 ic_padlock.png ../../res/drawable-hdpi/ic_listview_padlock.png
convert -transparent white ic_padlock_ok.pdf ic_padlock_ok.png
convert -scale 36x36 ic_padlock_ok.png ../../res/drawable-ldpi/ic_listview_padlock_ok.png
convert -scale 48x48 ic_padlock_ok.png ../../res/drawable-mdpi/ic_listview_padlock_ok.png
convert -scale 72x72 ic_padlock_ok.png ../../res/drawable-hdpi/ic_listview_padlock_ok.png
Вы можете использовать преобразование с параметром плотности для наилучшего рендеринга:
convert -density targetdensityxtargetdensity -transparent white splash.pdf ../../res/drawable/splash.png
Комментарии:
1. Я ориентируюсь на устройства 2.1 и исходя из этой статистики: developer.android.com/resources/dashboard/screens.html похоже, мне следует беспокоиться о проблемах с экранами с более низким разрешением, когда они появляются. Изображение также является фоном для действия, а не значками, подобно тому, как запомнить молоко
2. developer.android.com/guide/topics/resources /… и developer.android.com/guide/practices/screens_support.html может быть полезным. Вы можете использовать convert или другую программу с учетом плотности / масштаба. Вам просто нужно позаботиться о тонкости dp / dpi. Согласно документации, «маленькие экраны имеют не менее 426dp x 320dp».