Единицы измерения в iOS и Android
Разработать и оптимизировать отображение сайта на мобильных устройствах — обязательное условие процесса создания сайта в наше время. Мир изменился, новое поколение уже не представляет интернет без мобильных устройств. И вновь очень важно учитывать скорость загрузки контента. Да, широкополосные 100 мбит ушли коту под хвост, вновь сайты в идеале весят 150 кб (конечно, только мобильные! }: ). Проект начинается с UX (проектирование), иногда с участием бизнес-аналитика. И они должны решить, как продукт будет смотреться на всех устройствах.
Раз уж всё должно масштабироваться под множество различных устройств, то важно понимать возможности масштабирования контента. Начнём с единиц измерения:
Pixel — самый незамысловатый вариант, и теперь уже довольно непрактичный, так как на экране 320×240 кнопка размером 8×8 px станет непростительно маленькой, едва заметной и совершенно не похожей на кнопку.
In/pt — эти единицы измерения не дадут кнопке масштабироваться, и она может попросту не влезть в экран. Технически эта единица измерения очень привязана к плотности пикселей на мобильных устройствах. Pt это точка, а не пиксель, при разрешении «1x» (или @ 1x) 1pt = 1px. При разрешении «2x» (@ 2x) 1pt = 4px, потому что разрешение удваивается по осям X и Y, делая его шириной 2px и высотой 2px. При разрешении «3x» (@ 3x) 1pt = 9px (3px x 3px) и так далее.
Dip – а вот это уже наш клиент. Абстрактные пиксели, не зависящие от плотности экрана. Количество пикселей в физической области экрана, как правило, называют DPI (точки на дюйм). Dp — размеры экранного элемента, sp — размер шрифта. На экране с плотностью размещения пикселей 160 dpi (mdpi) 1px=1dp. Это соотношение изменяется при изменении плотности пикселей на разных устройствах, но соотношение пропорций остается одинаковым.
Описать dpi можно и по другому. Это коэффициент, показывающий сколько пикселей уложится в один сантиметр (дюйм) отпечатка или экрана. Разрешение измеряется в количестве пикселей на 1 дюйм — ppi (pixels per inch)
Попробуем дать более толковое определение независимой точке (DP). Эти единицы помогут ваши макеты сделать независимыми от плотности пикселей на экране. Одна DP точка равна пикселю на 160 dpi (является средней плотностью экрана). Когда приложение запущено, система обрабатывает изменения в масштабе экрана исходя из плотности используемого экрана, и меняет параметры по формуле: 1 пиксель = DP * (DPI/ 160). Экран 240 dpi: 1 dp = 1,5 физических пикселя.
Адаптивная вёрстка.
Целью адаптивного веб-дизайна является возможность просматривать одну и туже веб-страницу со всего многообразия мобильных устройств без серьёзных косяков в отображении сайта. Я просто обозначу основной плюс: адаптивный сайт распознаёт ширину браузера и подстраивается под неё, тогда как мобильные сайты должны распознать устройство, а устройств появляются всё больше и больше, и приходится скрипт определения устройства постоянно обновлять. Для адаптивной вёрстки, надо просто продумать три типа страниц для экранов с шириной 1024х (компьютер), 768х (iPad в вертикальной ориентации) и 320х (iPhone в вертикальной ориентации). Многие приложения имеют двойную ориентацию: горизонтальную и вертикальную. iPhone 4 имеет новый дисплей «retina», который удваивает количество пикселей в пределах одного экрана вплоть до 2048×1536. Нужно делать дизайн изначально для Retina, а затем сжимать до обычного экрана (-50%). Это означает, что вам также необходимо создать 2 набора иконок для ваших макетов. Первоначально иконки будут в 163 ppi, но вам нужно включить иконки с 326 ppi для iPhone 4. Для настройки под различную плотность экрана устройства, мы должны следовать соотношению масштабирования 3:4:6:8, соответственно четырем размерам плотности (для iPhone это легко: соотношение 2:1 между 4 и iPhone 3GS). Иконки традиционно отмечаются @2x в конце названия их файлов, например «home@2x.png».
Сайты дизайнер должен рисовать под следующие размеры:
320 px — Мобильные устройства в портретной ориентации
568 px — IPhone 5
640 px — Небольшие планшеты
768 px — Планшеты в портретной ориентации
1024 px — Планшеты в альбомной ориетации, мониторы в гос. конторах
1280 px и более — настольные компьютеры
Навигация.
Поговорим о кнопках. Теперь данные вводятся не с клавиатуры, и кликнуть мышкой нельзя. Поэтому большие кнопочки лучше маленьких, т.к. в них проще попасть пальцем. Нужно добиться, чтобы движения были естественны для человека, и всегда была видна реакция и изменения. И да, хорошо, если ссылки это кнопки, а не куча синих подчёркнутых строчек, и не надо скупиться на размер шрифта. Но насколько кнопки должны быть большие? 44х44 пикселя для iPhone, 48dp для Android, 36×36 для Windows Phone, Nokia же рекомендует делать кнопку не менее 1 см. Это информация из официальных гайдлайнов, в которых даже единицы измерения разнятся. Придётся поделиться выводом из собственного опыта: кнопка хорошо нажимается, если её размеры 45-75 dp в зависимости от задачи. Минимальная сенсорная область это 7×7 мм, средняя ширина пальца 25 мм. Но рекомендации из гайдлайнов не стоит игнорировать, и если вы понимаете, что не можете сделать исходя из своего опыта, делайте по гайдлайнам (и вы всё ещё помните, что реальный размер зависит от плотности пикселей конкретного устройства : ).
Как вы понимаете, большие кнопки в интерфейсе — меньше кнопок влезет на экран, и это хорошо для мобильных приложений.После эпического нажатия по удобной кнопке, пользователь переходит на какую то страницу. Это важный момент, т.к. человек должен чётко осознавать, где он, откуда он, почему? зачем? кому? что? как вернуться? В айфонах и айпадах используется очень правильный, кинематографичный приём переход справа налево и обратно, что оставляет визуальную связь в структуре окон интерфейса.
Цифры маководам:
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.
For iPhone 6:
750 x 1334 (@2x) for portrait
1334 x 750 (@2x) for landscape
For iPhone 6 Plus:
1242 x 2208 (@3x) for portrait
2208 x 1242 (@3x) for landscape
Default@2x 640-960
Default-568h@2x 640-1136
Default-667h@2x 750-1334
Default-736h@3x 1242-2208
В итоге фоны должны быть 640×960, 640×1136, 750×1334, 1080×1920;
Иконки делаем следующих размеров: 512×512 (iTunesArtwork), 57×57 (Icon.png), 114×114 (Icon@2x.png), 72×72 (Icon-72.png), 29×29 (Icon-Small.png), 50×50 (Icon-Small-50.png), 58×58 (Icon-Small@2x.png) и 144×144.
В строке меню на MacOS нужно рисовать набор белых/черных и ретиновых/неритиновых файлов в формате ICNS.
Заодно, отвечу на регулярно встречающийся вопрос про модульные сетки: 44, 88, 176 — хорошие значения для проектирования модульных сеток. Разместите кнопки и контент по этой сетке, и всё будет не плохо.
Но не одними айфонами живо мобильное интернет-пространство. Сейчас на рынок выходит все больше и больше мобильных устройств, количество сенсорных экранов увеличивается. Несмотря на то, что мы говорили о дизайне iOS приложении, дизайнерам стоит учитывать и прочие устройства. Чтобы не перерисовывать под каждое устройство сайт, в исходниках необходимо всё в shape layers или vector smart objects, тогда не возникнет серьезных проблем с масштабированием.
Теперь уделим немного внимания Android. Чем отличается iOS и Android? У одного вкладки сверху, у другого — снизу. А ещё всё весьма запутанно с единицами измерения. Для android существует четыре основные плотности экрана: LDPI (низкий), MDPI (средний), HDPI (высокий), и XHDPI (дополнительный высокий, начиная с Android 2.2), они означают, сколько пикселей может поместиться на один дюйм. Как минимум, дизайнер на выходе должен предоставить вам MDPI и HDPI наборы графики для любого смартфон-приложения (я обычно ограничиваюсь MDPI, HDPI и XHDPI).
Постараюсь не вдаваться в подробности, а сразу привести нужные цифры. У android имеются следующие плотности экрана:
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
Как показал опыт, имеется два наиболее популярных соотношения сторон:
а) 1.77 (480×854, 960×540, 1280×720 )
б) 1.6 (480×800, 1280х800)
А вот размеры шрифтов зачастую бывают весьма непривлекательными
17sp:
ldpi — 12.75px
mdpi — 17px
hdpi — 25.5px
xhdpi — 34px
23sp:
ldpi — 17.25px
mdpi — 23px
hdpi — 34.5px
xhdpi — 46px
SP это scaled points, привязаны к физическим единицам. Шрифт должен быть одинакового размера и на вашем телефоне, и на стареньком телефоне с маленьким экраном, и на хорошем дорогом планшете. Размер шрифта диктуется не размером экрана — это классическая ошибка.
Ниже приведу рекомендации Google. Именно эти значения помогут вам избегать дробных чисел при ресайзах.
- mdpi – 24
- hdpi – 36
- xhdpi – 48
- xxhdpi – 72
- xxxhdpi – 96
При нарезке важна только плотность: dp = 1px в mdpi. Со шрифтами ситуация аналогична, но единицы измерения sp. Ритм 48 dp. А такие размеры использую я. Вам решать, какие размеры использовать для вашего мобильного проекта.
- mdpi – 36
- hdpi – 54
- xhdpi – 72
- xxhdpi – 108
- xxxhdpi – 144
Как это ресайзить? Вот пример:
24 × 24 для экранов низкой плотности (т.е. × 0,75) это ldpi;
32 × 32 для экранов средней плотности (наш базовый 1 × 1 ) это mdpi;
48 × 48 для экранов с высокой плотностью (× 1,5) это hdpi;
64 × 64 для экранов очень высокой плотности (× 2,0) это xhdpi;
И для прочей информации:
low-density (ldpi) экран (~120dpi)
medium-density (mdpi) экран (~160dpi) – базовое.
high-density (hdpi) экран (~240dpi).
extra high-density (xhdpi) экран (~320dpi).
А когда даем нарезанной графике какие то имена, то придерживаемся правил: нижний регистр, без пробелов, без дефисов, найн-патч с «.9» перед расширением. Подчёркивания использовать можно.
На данный момент актуально создавать и xxhdpi-нарезку, начиная с 2014 года я не отдаю проектов без такой плотности экрана.
Соответственно, формулы для получения размеров: 160 это mdpi.
ldpi
Vertical = 426 * 120 / 160 = 319.5px
Horizontal = 320 * 120 / 160 = 240px
xhdpi
Vertical = 960 * 320/160 = 1920px
Horizontal = 720 * 320/160 = 1440px
Как вы поняли, формула px = dp*dpi/160.
Надеюсь, эта информация ответит на все ваши вопросы, если вы не новичок, конечно. Ещё есть всякие Java ME (слабенькие, маленькие, неказистые), Windows Phone (крутой API, C#, в России мало распространён), Symbain (Java, Qt, не поддерживается), но основные гиганты, андроид и iOs, требуют к себе больше всего внимания.
Ну и ссылочки по теме:
10 комментариев
katerina.polishuk
Я бы хотела узнать, что делать со сложными формами в андроиде? Резать кучу размеров? или лучше заставлять разработчиков реализовать сложную форму?
your-scorpion
Зависит от навыков разработчиков. Любую форму можно реализовать, ведь в конечном счете это не более, чем описание контура формулами.
Проблема в том, что может просесть скорость работы устройства. Поэтому иногда рациональнее пожалеть мобилки и ограничиться стандартными формами. Иногда.
В Android легко нарисовать следующие формы:
— одноцветный круг;
— одноцветная окружность;
— одноцветный заполненный прямоугольник;
— одноцветный прямоугольник;
— одноцветный заполненный прямоугольник с закругленными углами.
— одноцветный прямоугольник с закругленными углами.
Любые другие варианты придется делать либо как композицию из перечисленных фигур, либо рисовать что-то полностью свое.
studio_malina
Какие размеры экранов вы на данный момент считаете актуальными?
И какие размеры иконки для типа файлов в iOS?
your-scorpion
На данный момент для Android: 480 × 800, 480 × 854, 540 × 960, 720 × 1280, 1080 × 1920
IPhone в последние годы также подвергся фрагментации: 640 × 960, 640 × 1136, 750 × 1334, 1242 × 2208.
Размеры иконки типа файла для iOS
iPad: 64 x 64 pixels, 320 x 320 pixels
iPhone и iPod touch: 22 x 29 pixels, 44 x 58 pixels
Souuz2000
Здравствуйте! Вот вы пишите,. что 100 мбит ушли коту под хвост, вновь сайты в идеале весят 150 кб. Но современные сайты весят и по мегабайту, и даже больше. Не говоря уже о крупных порталах с огромной историей. Что делать таким сайтам то, умирать что ли?))
your-scorpion
Здравствуйте.
Ну зачем же умирать то, можно все оптимизировать. Во первых, нужно разрабатывать адаптивную версию сайта, это смертельно важно для любого бизнеса.
Во вторых, недавно в веб-стандартах появилась аббревиатура AMP (спасибо Google). Расшифровывается она как Accelerated Mobile Pages. Эта технология помогает преодолеть недостаток скорости мобильного интернета за счет оптимизации страницы. По факту, эта технология дает новую, альтернативную презентацию контента с десктопного сайта. Страница AMP существуют параллельно с тяжелой десктопной версией, эти страницы связаны специальным тегом в заголовке.
Работает по следующему принципу: тяжелый сайт с кучей кода отслеживания, гифками с покадровым interframe, видео, баннерами и прочими тяжелыми вещами будет преобразован в легкую, быстрозагружаемую версию. Сначала будет идти контент, потом видео, и лишь затем реклама, так что доходы рекламодателей могут начать снижаться.
Если на вашем сайте нет лишнего кода и при разработке вы опирались исключительно на передовой опыт, то эта технология не сильно увеличит скорость загрузки страницы.
В третьих, почти наверняка сайт много весит из за картинок. Существует HTML-элемент Picture, у него есть дескрипторы ширины (400w, 800w, 1200w) и еще много полезного, они помогут сильно оптимизировать объем загружаемых картинок на мобильные девайсы.
Belozyorcev
Есть ли способы оптимизировать загрузку сайта без AMP и уменьшения веса графики? Это слишком очевидные способы, которые несут потери.
Цветков Максим
А что для вас является оптимизацией загрузки сайта, когда с вашей точки зрения сайт загружен? Если появился один символ, то сайт уже грузится, но он все еще не полезный.
Это было лирическое отступеление, а теперь по делу. У консоли разработчика Chrome есть раздел Performance, в котором можно посмотреть как грузятся ресурсы и как ваш сайт выглядит на всех этапах загрузки, и симулировать троттлинг процессора и интернет-соединения. Смотрите, как грузится ваш сайт и оптимизируете. Далее можно применить lazy loading.
Помимо картинок, еще можно оптимизировать подгрузку шрифтов из интернета. Сейчас есть свойства
link rel="preload"
,as="font"
, это позволяет загрузить шрифт в тот момент, когда он нужен. Можно использовать и для видео,as="video"
.Если у вас все плохо и первые секунды загрузки сайт белый, с одной картинкой и нет текста, то это решается это новым свойством
font-display: swap;
. Оно показывает текст тем шрифтом, который найдет на устройстве пользователя. И чтобы в момент подгрузки шрифта весь текст не прыгал, используйтеfont-display: fallback;
, это свойство говорит браузеру загрузить, если длительность загрузки не более 100мс. Если же нет, то использовать шрифт с устройства пользователяИ разработчики должны посматривать в сторону HTTP/2 Server Push, парсинга js, уменьшения размера бандла, рендеринга страниц на сервере и все мерить с помощью Google Lighthouse, Navigation Timing API.
Vladimir Vlasov
Добрый день. Подскажите по производительности, как примерно можно сформировать в ТЗ описание по производительности к приложению?
Цветков Максим
Метрика для скорости работы это FPS. Можете указать vertical line = 16ms (for 60 FPS), и минимальное значение в 30 FPS как минимум для ощущения плавности работы.
Подсчитать свои значения не трудно:
1 секунда = 1000ms -> 1000/30 = ~33.3ms.
Описанное выше можно трактовать так: для 30FPS требуется вычислить, анимировать, отрендерить кадр менее чем за 33,3 миллисекунды, и повторить это 30 раз. Для 60FPS: 1000/60 = ~16.6ms.
Узнайте, можете ли вы использовать GPU вместо CPU. GPU быстрее работает с математическими операциями, может парралельно делать много операций с плавающей точкой, но требует больше памяти. CPU работает надежнее, но медленнее. Также, GPU может багами рендерить картинку, но это сильно зависит от версии API (16 минимум).
Можно пойти и от обратного и считать время задержки от последнего отрисованного кадра. Или запускать таймер и замерять, исполнился ли он за заданный промежуток времени.
Для более системного подхода есть набор метрик RUM — Real User Monitoring. Замер идет на реальных пользователях в продакшене.