Ldpi mdpi hdpi xhdpi android size

Навигация.
Поговорим о кнопочках. Данные теперь вводятся не с клавиатуры, и кликнуть мышкой нельзя, всё делается пальчиками, как в каменном веке. Поэтому большие кнопочки лучше маленьких, т.к. в них проще попасть пальцем. Нужно добиться, чтобы движения были естественны для человека, и всегда была видна реакция и изменения. И да, хорошо, если ссылки это кнопки, а не куча синих подчёркнутых строчек, и не надо скупиться на размер шрифта. Но насколько кнопки должны быть большие? 44х44 пикселя для iPhone, 36×36 для Windows Phone, Nokia же рекомендует делать кнопку не менее 1 см. Это информация из официальных гайдлайнов, в которых даже единицы измерения разнятся. Придётся поделиться выводом из собственного опыта: кнопка хорошо нажимается, если её размеры 45-75 dp в зависимости от задачи. Но рекомендации из гайдлайнов не стоит игнорировать, и если вы понимаете, что не можете сделать исходя из своего опыта, делайте по гайдлайнам (и вы всё ещё помните, что реальный размер зависит от плотности пикселей конкретного устройства : ).

Как вы понимаете, большие кнопки в интерфейсе — меньше кнопок влезет на экран, и это хорошо для мобильных приложений.

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

iPad : 768 x 1024 pixels , 1024 x 768 pixels , разрешение экрана: 72 ppi, формат файлов: PNG-24. Ipad позволяет запускать любые приложения, разработанные под Iphone. Но в этом случае они просто масштабируются под большие размеры экрана. Размер иконки: 72×72px и радиус скругления 12px.

Other iPhone and iPod touch devices : 320 x 480 pixels , разрешение экрана: 72 ppi , размер иконки: 57 x 57 px , радиус скругления 10px, формат файлов: PNG-24.

Графика для AppStore: иконки 512 x 512 px (.tif, .jpg or .png, 72dpi, RGB, важно отразить основную идею), скриншоты для iPhone: 320 x 480 px или 640 x 960 px (.tif, .jpg or .png, 72dpi, RGB), скриншоты для iPad: 1024 x 768 px (.tif, .jpg or .png, 72dpi, RGB).

Иконках для поиска: размер 29×29px, радиус скругления углов – 5px.

44, 88, 176 — хорошие значения для проектирования модульных сеток.

Но не одними айфонами живо мобильное интернет-пространство. Сейчас на рынок выходят все больше и больше мобильных устройств, количество сенсорных экранов увеличивается. И все они с разными размерами. Несмотря на то, что мы говорили о дизайне iOS приложении, дизайнерам стоит учитывать и прочие устройства. Чтобы не перерисовывать под каждое устройство сайт, в исходниках дизайнер должен рисовать всё в shape layers или vector smart objects, тогда не возникнет проблем с масштабированием.

Чем отличается iOS и Android, спросите вы? Ну, у одного вкладки сверху, у другого — снизу. А ещё тут всё весьма запутанно с единицами измерения. Для android существует четыре основные плотности экрана: LDPI (низкий), MDPI (средний), HDPI (высокий), и XHDPI (дополнительный высокий, начиная с Android 2.2), они означают, сколько пикселей может поместиться на один дюйм. Как минимум, дизайнер на выходе должен предоставить вам MDPI и HDPI наборы графики для любого смартфон-приложения (я обычно ограничиваюсь LDPI, MDPI и HDPI).

Постараюсь рассказать просто о сложном. У android имеются следующие плотности экрана:
24 × 24 для экранов низкой плотности (т.е. × 0,75);
32 × 32 для экранов средней плотности (наш базовый 1 × 1 );
48 × 48 для экранов с высокой плотностью (× 1,5);
64 × 64 для экранов очень высокой плотности (× 2,0).

240х320 (в пикселях)
320х480 (в пикселях)
480х800 (в пикселях)
640×960 (в пикселях)

xlarge screens are at least 960dp x 720dp
large screens are at least 640dp x 480dp
normal screens are at least 470dp x 320dp
small screens are at least 426dp x 320dp

Если обобщить, то
low-density (ldpi) экран (

120dpi)
medium-density (mdpi) экран (

160dpi) – базовое.
high-density (hdpi) экран (

(base en dp) 426×320 480×320 640×480 960×720

Источник

Как Android преобразует размеры ресурсов

Размер APK файла можно уменьшить, выкинув «ненужные» LDPI ресурсы, Android все равно умеет генерировать их на лету из MDPI. Но что будет если убрать еще и MDPI каталог? И как именно будет произведена свертка: усреднением или более дешевым выбрасыванием пикселей? Перескочит ли Android через один шаг чтобы произвести потенциально более простое преобразование HDPI → LDPI? Как именно происходит уменьшение картинок в разных случаях? Чтобы ответить на эти вопросы я провел небольшой тест.

Теория

33.(3) или 50%, то есть MDPI ресурс должен быть примерно в 1.33 раза больше LDPI, а HDPI — уже в 2 раза больше. При преобразованиях 2 → 1 и 4 → 1 теоретически возможны «дешевые» отбрасыванием каждого второго пикселя, при переходе 1.5 → 1 теоретически возможна оптимизация с отбрасыванием одного пикселя из трех, а при переходе 1.33 → 1 — одного из четырех, осталось проверить какие оптимизации и алгоритмы использует Android в действительности.

Методика тестирования

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

и размещены со смещением 0, 1 и 2 пикселя от границы (паттерны однонаправленные, так как вертикальная и горизонтальные свертки очевидно должны использовать одинаковый алгоритм).
Помещаем картинку (одну и ту же) в каталоги LDPI, MDPI и т.д под разными именами и на каждой копии рисуем «водяной знак» обозначающий каталог, в котором она находится, чтобы знать, откуда Android взял исходник для преобразования. Отображаем картинки изо всех (MDPI-XXXDPI) каталогов на разрешениях от LDPI до XXHDPI. Смотрим под лупой, что же получилось, и отвечаем на вопросы.

Одинаков ли алгоритм свертки для переходов 1.5 → 1 и 1.33 → 1 ?

Очевидно нет, можно сравнить, как выглядит паттерн из каталога HDPI на MDPI экране и паттерн MDPI на LDPI

при этом результаты сверток x → h и m → l совпадают, что подтверждает теорию.

Отбрасывает ли Android «лишний» пиксель при свертке 1.5 → 1 ?

Судя по всему, да! Для этого сделаем другой паттерн (также со смещением 0, 1 и 2 пикселя)
▣ ▣ ▣ ▣ ▣ ▣ и смасштабируем его из HDPI в MDPI

на итоговом паттерне поочередно выпадают то красный, то синий, то зеленый цвета, значит при калькуляции 2 пикселей из 3, один не принимается в расчёт. Итоговые цвета не чистые, значит, оставшиеся два пикселя не берутся как есть, а смешиваются в разной пропорции.

Как происходит свертка 2 → 1 ?

Простым замешиванием соседних пикселей парами в равных пропорциях. Тут результаты переходов h → l, xh → m, xxh → h идентичны.

Артефактов отбрасывания пикселей не замечено.

Как происходит свертка 4 → 1 ?

А вот тут Android все-таки выбрасывает часть пикселей. Судя по всему, берутся четверки пикселей, два крайних удаляются, а центральные замешиваются в равной пропорции. Примерно так:

Именно этот алгоритм является причиной интересного артефакта — полного пропадания синего и красного цветов из паттернов ▣ ▣ ▣ ▣ и ▣ ▣ ▣ ▣ , которые отличаются только смещением.

Какой ресурс выбирает Android если вариантов несколько?

При свертке до MDPI ресурса, который имеется в HDPI и XHPI каталогах можно было бы применить потенциально более простой алгоритм 2 → 1 вместо 1.5 → 1, пропустив одну ступень, но Android всегда выбирает ближайший ресурс. Вероятно, еще и потому, что свертка 2 → 1 использует более ресурсоемкое замешивание, а не отбрасывание (как мы видели выше), и сэкономить на ней сильно не получится.

Какой из этого всего можно сделать вывод?

Ну во-первых, надо не забывать напоминать своему дизайнеру, что рисовать нужно по сетке и что 1dp != 1px: любая однопиксельная линия на всех разрешениях от MDPI и выше может превратиться в непредсказуемую размазню или вовсе пропасть. Во-вторых, SVG/XML все-таки более надежный способ экономии на графике, если характер картинки позволяет. В-третьих, если итоговая картинка на экрана должна иметь четкие грани, все разрешения должны присутствовать в проекте. Ну и наконец, Android, действительно применяет интересные оптимизации, чтобы сэкономить процессорные ресурсы, и этим можно пользоваться, если делать это с умом.

Пример работы тестового приложения на разных разрешениях (на каждой картинке написано из какого каталога, она взята, рядом с ней — в каких каталогах она присутствовала):

Источник

NativeScript Image Builder

The NativeScript Image Builder helps you re-size your Android and iOS image assets for using with your NativeScript apps. Upload your maximum resolution image in PNG format, and you’ll get back a .ZIP file with the image assets re-sized.

Upload an Image

To get started, specify your image type, select your image, and press Upload!.

Be sure to upload your highest resolution static image (xxxhpdi or @3x).

Upload an Icon

Select your app icon file, and press Upload!.

For app icons, upload a square image with minimum dimensions of 1024 x 1024.

Get Back a Zip

Android apps should provide 6 image sizes: ldpi (0.75x), mdpi (1.0x), hdpi (1.5x), xhdpi (2.0x), xxhdpi (3.0x), and xxxhdpi (4.0x).

iOS apps should provide 3 image sizes: @1x (iPad 2 and iPad mini), @2x (iPhone 4s, iPhone 5, iPhone 6, iPad [retina]), and @3x (iPhone 6 Plus).

App icons can be even move confusing: Android apps should provide 6 icon sizes, ranging from 36 x 36 pixels to 192 x 192 pixels, plus a Google Play Store app icon of 512 x 512 pixels. iOS apps must include 12 app icons, with varying sizes and pixel densities from 29 x 29 @1x to 60 x 60 @3x (180 pixels), plus several random sizes like the 83.5 x 83.5 @2x to support the iPad Pro.

Upload your image at the highest resolution (xxxhpdi or @3x), and we’ll down-size and rename accordingly.

Читайте также: Тайм шифт для андроид

The Details

Many developers don’t have the time or patience to resize images for their mobile apps, let alone create 8 different versions of an image for a cross-platform app for Android and iOS. Why not out-source it?

Upload a high-dpi version of your static app .PNG images (xxhdpi for Android and @3x for iOS), and we do the heavy lifting. You’ll receive a .ZIP file containing the images down-sampled to the right dimensions for each of the 8 platforms. We’ll also name them correctly for you. Just because we’re nice.

Android Images

When developing Android apps, you should provide 6 different image sizes: ldpi (0.75x), mdpi (1.0x), hdpi (1.5x), xhdpi (2.0x), xxhdpi (3.0x), and xxxhdpi (4.0x). Mdpi images are typically referred to as the «baseline» image, and the other image sizes should be based off of this image’s intent; however, up-sampling from mdpi to xxxhdpi (which is 4x the size) isn’t practical and can lead to pixelated images. So, we ask you to upload your xxxhdpi (4x) image, and we’ll down-sample the image to the other sizes.

In the .ZIP file we’ll send back, we’ll create a directory for each down-sampled image, ready to be copied into your App_Resources\Android folder. Folders are named accordingly: drawable-ldpi, drawable-mdpi, drawable-hdpi, drawable-xhdpi, drawable-xxhdi, drawable-xxxhdpi.

For more details on Android-specific images, check out this article on the Android developer center.

iOS Images

iOS apps require you to to provide 3 sizes of images: @1x (iPad 2 and iPad mini), @2x (iPhone 4s, iPhone 5, iPhone 6, iPad [retina]), and @3x (iPhone 6 Plus). @1x images are typically considered the baseline image size, with @2x and @3x being twice and three times the size, respectively. We won’t up-sample from @1x, so you’ll have to provide the @3x image, and we’ll down-sample for you.

Your .ZIP file will include the three images, ready to be copied into the App_Resources\iOS folder of your NativeScript app. The files will also be named according to their size.

To find out more on iOS images and the requirements of the iOS platform, check out the Apple Developer Center.

App Icons

Creating the «right» app icons (and in the «right» sizes) can be challenging for new developers. There are many great resources online outlining what you need for both Android and iOS platforms.

For Android app icons, we’ll create the 6 different required icon, named icon.png, and place them into their respective drawable folders. We will also create the Google Play Store icon, which is a 512 x 512 pixel icon. This will be placed in the root of the ZIP file Android folder and named playstore-icon.png.

iOS app icons are even more challenging to understand. Apple’s Developer Center outlines exactly what you need, but we still find it hard to understand. We’ll do the heavy lifting and create the various icons, with the proper names, with the standard icon-@?x.png format, and supply an updated Contents.json file. We’ll also create the iTunes store icons, named iTunesArtwork.png and iTunesArtwork@2x.png, which are 512 x 512 and 1024 x 1024 pixel images.

Meh. Down-sampling

Yeah. Down-sampling can lead to loss of quality in an image. If this is a concern, this is not the tool for you. You should manually adjust your images, adding and removing detail as you see fit for each of the platforms and image sizes.

Other Image Types

So, there’s also app icons, splash screen images, and a load of other images required by each platform. Support for those is coming.

About NativeScript

NativeScript is an open-source library for building professional cross-platform mobile apps for Android and iOS using JavaScript.

For a more complete reference for using images within your NativeScript app, check out the NativeScript docs.

Other Resources

Check out some of the community support around NativeScript app icons and images.

iOS image and launch images: Robert Hafner built a Python script to resize iOS images and launch images.

Источник

Ldpi mdpi hdpi xhdpi android size

Основы