Hdpi xhdpi android studio

Основы

Существует огромное количество устройств с разными размерами экрана от 2.6 до 6 дюймов (для телефонов) с разрешениями от 240х320 до 1440х2560 пикселей с плотностью от ldpi до xxxhdpi. И дизайнеру нужно уметь создать правильный макет для зоопарка устройств.

На данный момент Android поддерживает следующие параметры: ldpi, mdpi, hdpi, xhdpi, xxhdpi and xxxhdpi.

Базовой является плотность mdpi, когда 1px = 1dp. Остальные являются множителями:

Как уже я сказал, MDPI является базовой точкой отсчёта и соответствует размеру экрана 320х480 пикселей. Для HDPI — 480×720, XHDPI — 640×960.

Размер устройства в DP вычисляется по формуле: разрешение экрана делим на множитель, указанный выше.

Например, устройство с разрешением экрана 240х320px соответствуют 320х426.66dp (240 / 0.75 = 320; 320 / 0.75 = 426.66).

Соответственно, устройство с экраном 1080х1920 (Samsung S5) соответствует типу XXHDPI — 360x640dp (1080 / 3 = 360; 1920 / 3 = 640dp)

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

Что будет, если подготовить одну картинку? Есть два варианта. Допустим, вы приготовили картинку для базового размера во весь экран. На современных телефонах картинка растянется в 3-4 раза и будет размыта. Хорошо, пойдём от обратного и подготовим картинку для самого большого экрана. Тут нас может ожидать другая неприятность — нехватка памяти. Большая картинка может занимать размер от 2Мб и выше. Маленькие экраны физически не смогут показать такое изображение, но будут при этом потреблять в 3-4 раза больше памяти, которой может не хватить для приложения.

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

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

Для фона экрана приложения используются следующие типы ресурсов:

• Color
• Gradient
• 9-patch Drawable
• Повторяющие фрагменты
• Картинка на весь экран

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

У компонента ImageView есть атрибут scaleType с значением CENTER_CROP.

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

Используйте в этом случае scaleType = CENTER_INSIDE.

Если фон однородный и его можно растянуть без ущерба качеству, то воспользуйтесь scaleType = FIT_XY.

Источник

Русские Блоги

Android hdpi ldpi mdpi xhdpi xxhdpi подробная адаптация

1. Понять несколько понятий
(1) Разрешение. Разрешение — это количество пикселей на экране мобильного телефона, которое обычно определяется как «ширина х высота» экрана. Общие разрешения для экранов телефонов Android: 480 × 800, 720 × 1280, 1080 × 1920 и т. Д. 720 × 1280 указывает, что этот экран имеет 720 пикселей в направлении ширины и 1280 пикселей в направлении высоты.
(2) Размер экрана. Размер экрана — это физический размер диагонали телефона, в дюймах. Например, определенный мобильный телефон представляет собой «5-дюймовый мобильный телефон с большим экраном», который относится к диагонали размером 5 дюймов × 2,54 см / дюйм = 12,7 см.

(3) Плотность (точек на дюйм, точек на дюйм; или PPI, пикселей на дюйм). Как следует из названия на английском языке, это количество пикселей на дюйм. Чем выше значение, тем более деликатный дисплей. Если мы знаем, что разрешение мобильного телефона составляет 1080 × 1920, а размер экрана составляет 5 дюймов, можете ли вы рассчитать плотность этого экрана? Ха-ха, теорема Пифагора в средней школе пригодилась! Через ширину 1080 и высоту 1920, согласно теореме Пифагора, мы получили, что число диагональных пикселей составляет приблизительно 2203. Тогда плотность этого экрана делится на 2203 на 5. Результат вычисления — 440. Экран 440 точек на дюйм довольно деликатный. ,

2. Фактическая плотность и плотность системы
В других местах я не нашел слов «фактическая плотность» и «плотность системы». Позвольте мне определить их на данный момент.
«Фактическая плотность» — это плотность, которую мы сами рассчитали. Эта плотность представляет фактическую тонкость экрана. Например, 440 точек на дюйм в приведенном выше примере — это фактическая плотность, указывающая, что этот экран имеет 440 на дюйм. пиксели. Плотность экрана 5 дюймов с разрешением 1080 × 1920 составляет 440, а плотность экрана 4,5 дюйма с тем же разрешением составляет 490. С этой точки зрения, плотность экрана будет много значений, показывая серьезную фрагментацию. А плотность — это основа для экрана Android для увеличения интерфейса, так как же Android адаптируется к такому количеству экранов?
Фактически каждый экран телефона Android имеет начальную фиксированную плотность. Это значения 120, 160, 240, 320 и 480. Мы называем их «системная плотность». Вы нашли, что нет никаких правил? Между значениями разделения существует двоякая связь. Обычно экран 240 × 320 имеет низкую плотность 120 точек на дюйм, то есть ldpi, экран 320 × 480 имеет среднюю плотность 160 точек на дюйм, то есть mdpi, экран 480 × 800 — это плотность 240 точек на дюйм, то есть hdpi, экран 720 × 1280 — супер Высокая плотность 320 точек на дюйм, а именно xhdpi; 1080 × 1920 экран сверхвысокой плотности 480 точек на дюйм, а именно xxhdpi.
Android масштабирует элементы интерфейса на основе плотности системы, а не фактической плотности.

3. Важная единица дп
dp также можно записать как dip, то есть независимый от плотности пиксель. Вы можете себе представить, что dp больше похож на физический размер: например, картинка с шириной и высотой 100dp «выглядит» размером с телефоны 320×480 и 480×800. В действительности их значения пикселей не совпадают. Размер dp как раз такого размера, независимо от плотности экрана, одни и те же элементы размера dp на экране всегда выглядят почти одинаково.
Кроме того, в качестве размера текста используется sp, что является аббревиатурой от независимого от масштаба пикселя. Таким образом, при настройке размера шрифта в системных настройках текст в приложении также будет становиться все больше и меньше.

4, преобразование dp и px
В Android экран мобильного телефона средней плотности с системной плотностью 160 точек на дюйм является базовым экраном, то есть экраном мобильного телефона 320 × 480. На этом экране 1dp = 1px.
100dp — это 100px в 320 × 480 (т / д, 160 т / д). Итак, сколько стоит 100dp на телефоне 480 × 800 (hdpi, 240dpi)? Мы знаем, что 100dp выглядит почти одинаково на обоих телефонах. Согласно соотношению между 160 и 240, мы можем знать, что при 480 × 800 100dp фактически покрывает 150px. Поэтому, если вы предоставите изображение с разрешением 100px для телефона с разрешением MDPI, оно будет растягиваться до 150px на телефоне с разрешением HDMI, но все они имеют разрешение 100 точек на дюйм.
Кажется, что коэффициенты масштабирования средней и высокой плотности можно рассчитать не по 160dpi и 240dpi, а также по 320px и 480px. Однако вычисление коэффициента масштабирования на основе ширины не подходит для сверхвысокой плотности xhdpi и сверхвысокой плотности xxhdpi. То есть, сколько пикселей составляет 1 дп при 720 × 1280? Если вы используете 720/320, вы получите 1dp = 2.25px, что на самом деле неверно. Преобразование между dp и px основано на плотности системы.Плотность системы 720 × 1280 равна 320, а плотность системы 320 × 480 равна 160. 320/160 = 2, затем в 720 × 1280, 1dp = 2px. Аналогично, в 1080 × 1920, 1dp = 3px.
Вы можете запомнить следующее соотношение, преобразование между dp и px очень просто!
ldpi: mdpi: hdpi: xhdpi: xxhdpi = 3: 4: 6: 8: 12, мы обнаружили, что между разделенными числами все еще существует двойная связь. Расчет основан на МДПИ. Например, в 720 × 1280 (xhdpi), сколько пикселей равно 1 dp? Соотношение между mdpi равно 4, а xhdpi равно 8,2 раза, то есть 1dp = 2px. Напротив, расчет важнее: например, если вы используете PhotoShop для создания карты эффекта интерфейса на холсте 720 × 1280, расстояние между двумя элементами составляет 20 пикселей. Сколько dp следует отметить? Удвойте отношения, это 10dp!

Когда размер шрифта системы Android установлен на «нормальный», преобразование размеров между sp и px и dp и px одинаково. Например, если размер текста составляет 24px на холсте с разрешением 720 × 1280 PS, сообщите инженеру, что размер текста составляет 12sp.

5. Рекомендуется отобразить в xdhpi
В телефонах Android так много экранов, какой экран использовать для рисования? Нет необходимости предоставлять набор материалов для мобильных телефонов различной плотности, в большинстве случаев достаточно одного набора.
Теперь более высокое разрешение мобильного телефона составляет 1080 × 1920. Вы можете выбрать этот размер для рисования, но материал изображения увеличит размер установочного пакета приложения. И чем больше размер картинки, тем выше память. Если вы не проектируете ПЗУ, а создаете приложение, я предлагаю вам использовать PS для рисования на холсте 720 × 1280. Этот размер уравновешивает эстетику, экономичность и простоту расчета. Эстетика означает, что приложения, сделанные в этом размере, отлично отображаются в разрешении 720 × 1280 и выглядят более четкими в разрешении 1080 × 1920, а экономичное означает, что изображения, экспортируемые в этом разрешении, имеют умеренный размер и занимают внутреннюю память. Он не будет слишком высоким, размер файла образа будет умеренным, а установочный пакет не будет слишком большим, расчет прост, то есть 1dp = 2px, насколько это хорошо!
Созданное изображение, не забудьте позволить разработчику интерфейса поместить его в папку ресурсов drawable-xhdpi.

6. Разница в ширине и высоте экрана
При рисовании в формате 720 × 1280 необходимо учитывать обратную совместимость с различными экранами. Посредством вычислений мы можем узнать, что ширина экрана 320 × 480 и 480 × 800 равна 320 dp, тогда как ширина экрана 720 × 1280 и 1080 × 1920 составляет 360 dp. Между ними разрыв в 40dp, и это 40dp оказывает большое влияние на дизайн. Как показано ниже, левые и правые поля изображения бабочки с экрана отличаются на экране шириной 320dp и на экране 360dp.

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

Если вы хотите устранить эти различия в пропорциях, вы можете сделать это, добавив файл макета. Обычно файл макета помещается в папку макета. Если вы хотите настроить экран 360dp отдельно, вы можете просто создать файл макета и поместить его в layout-w360dp, если вы хотите настроить конкретное разрешение. , Затем вы можете поместить файл макета в папку с разрешением, например layout-854 × 480.

7, несколько папок ресурсов
Я сделал изображение в разрешении 720 × 1280. Пусть разработчик поместит его в папку ресурсов drawable-xhdpi, чтобы оно могло отображаться правильно. Лично я думаю, что достаточно предоставить только один набор материалов. Вы можете проверить, нормально ли работает приложение на недорогих телефонах. Если оно зависло, вы можете при необходимости предоставить некоторые графические материалы с разрешением mdpi, поскольку изображения в формате xhdpi запускаются на телефонах с разрешением mdpi. Займет больше памяти.
Возьмите значок приложения в качестве примера. Размер значка в xhdpi составляет 96 пикселей. Если вы хотите предоставить значок для mdpi отдельно, то размер значка составляет 48 пикселей и помещается в папку ресурсов drawable-mdpi. Размер изображений в каждой папке ресурсов также соответствует закону ldpi: mdpi: hdpi: xhdpi: xxhdpi = 3: 4: 6: 8: 12.

Что делать, если вы сделали изображение в формате 9.png с материалом с высокой разделительной линией 2px и хотите, чтобы тонкие линии были 2px с различной плотностью без масштабирования Android на основе плотности? Вы можете поместить этот разделенный секущий материал в drawable-nodpi. Изображения в этой папке ресурсов будут отображаться в соответствии с фактическим размером пикселя и не будут масштабироваться Android в зависимости от плотности. То есть тонкая линия в mdpi составляет 2px (2dp), а тонкая линия в xhdpi — 2px (1dp).

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

Источник

Support different pixel densities

Not only do Android devices come in different screen sizes (handsets, tablets, TVs, and so on), but their screens also have different pixel sizes. That is, while one device has 160 pixels per square inch, another device fits 480 pixels in the same space. If you don’t consider these variations in pixel density, the system might scale your images (resulting in blurry images) or the images might appear at the completely wrong size.

This page shows you how you can design your app to support different pixel densities by using resolution-independent units of measurements and providing alternative bitmap resources for each pixel density.

Watch the video below for an overview of these techniques.

For more information about designing the actual icons assets, see the material design icon guidelines.

Use density-independent pixels

The first pitfall you must avoid is using pixels to define distances or sizes. Defining dimensions with pixels is a problem because different screens have different pixel densities, so the same number of pixels may correspond to different physical sizes on different devices.

Figure 1. Two screens of the same size may have a different number of pixels

To preserve the visible size of your UI on screens with different densities, you must design your UI using density-independent pixels (dp) as your unit of measurement. One dp is a virtual pixel unit that’s roughly equal to one pixel on a medium-density screen (160dpi; the «baseline» density). Android translates this value to the appropriate number of real pixels for each other density.

For example, consider the two devices in figure 1. If you were to define a view to be «100px» wide, it will appear much larger on the device on the left. So you must instead use «100dp» to ensure it appears the same size on both screens.

When defining text sizes, however, you should instead use scalable pixels (sp) as your units (but never use sp for layout sizes). The sp unit is the same size as dp, by default, but it resizes based on the user’s preferred text size.

For example, when you specify spacing between two views, use dp :

When specifying text size, always use sp :

Convert dp units to pixel units

In some cases, you will need to express dimensions in dp and then convert them to pixels. The conversion of dp units to screen pixels is simple:

Imagine an app in which a scroll or fling gesture is recognized after the user’s finger has moved by at least 16 pixels. On a baseline screen, a user’s must move by 16 pixels / 160 dpi , which equals 1/10th of an inch (or 2.5 mm) before the gesture is recognized. On a device with a high-density display (240dpi), the user’s must move by 16 pixels / 240 dpi , which equals 1/15th of an inch (or 1.7 mm). The distance is much shorter and the app thus appears more sensitive to the user.

To fix this issue, the gesture threshold must be expressed in code in dp and then converted to actual pixels. For example:

Kotlin

The DisplayMetrics.density field specifies the scale factor you must use to convert dp units to pixels, according to the current pixel density. On a medium-density screen, DisplayMetrics.density equals 1.0; on a high-density screen it equals 1.5; on an extra-high-density screen, it equals 2.0; and on a low-density screen, it equals 0.75. This figure is the factor by which you should multiply the dp units in order to get the actual pixel count for the current screen.

Use pre-scaled configuration values

You can use the ViewConfiguration class to access common distances, speeds, and times used by the Android system. For instance, the distance in pixels used by the framework as the scroll threshold can be obtained with getScaledTouchSlop() :

Kotlin

Methods in ViewConfiguration starting with the getScaled prefix are guaranteed to return a value in pixels that will display properly regardless of the current pixel density.

Provide alternative bitmaps

To provide good graphical qualities on devices with different pixel densities, you should provide multiple versions of each bitmap in your app—one for each density bucket, at a corresponding resolution. Otherwise, Android must scale your bitmap so it occupies the same visible space on each screen, resulting in scaling artifacts such as blurring.

Figure 2. Relative sizes for bitmaps at different density sizes

There are several density buckets available for use in your apps. Table 1 describes the different configuration qualifiers available and what screen types they apply to.

Table 1. Configuration qualifiers for different pixel densities.

Density qualifier	Description
ldpi	Resources for low-density (ldpi) screens ( 120dpi).
mdpi	Resources for medium-density (mdpi) screens ( 160dpi). (This is the baseline density.)
hdpi	Resources for high-density (hdpi) screens ( 240dpi).
xhdpi	Resources for extra-high-density (xhdpi) screens ( 320dpi).
xxhdpi	Resources for extra-extra-high-density (xxhdpi) screens ( 480dpi).
xxxhdpi	Resources for extra-extra-extra-high-density (xxxhdpi) uses ( 640dpi).
nodpi	Resources for all densities. These are density-independent resources. The system does not scale resources tagged with this qualifier, regardless of the current screen’s density.
tvdpi	Resources for screens somewhere between mdpi and hdpi; approximately 213dpi. This is not considered a «primary» density group. It is mostly intended for televisions and most apps shouldn’t need it—providing mdpi and hdpi resources is sufficient for most apps and the system will scale them as appropriate. If you find it necessary to provide tvdpi resources, you should size them at a factor of 1.33*mdpi. For example, a 100px x 100px image for mdpi screens should be 133px x 133px for tvdpi.

To create alternative bitmap drawables for different densities, you should follow the 3:4:6:8:12:16 scaling ratio between the six primary densities. For example, if you have a bitmap drawable that’s 48×48 pixels for medium-density screens, all the different sizes should be:

• 36×36 (0.75x) for low-density (ldpi)
• 48×48 (1.0x baseline) for medium-density (mdpi)
• 72×72 (1.5x) for high-density (hdpi)
• 96×96 (2.0x) for extra-high-density (xhdpi)
• 144×144 (3.0x) for extra-extra-high-density (xxhdpi)
• 192×192 (4.0x) for extra-extra-extra-high-density (xxxhdpi)

Then, place the generated image files in the appropriate subdirectory under res/ and the system will pick the correct one automatically based on the pixel density of the device your app is running on:

Then, any time you reference @drawable/awesomeimage , the system selects the appropriate bitmap based on the screen’s dpi. If you don’t provide a density-specific resource for that density, the system picks the next best match and scales it to fit the screen.

Tip: If you have some drawable resources that the system should never scale (perhaps because you perform some adjustments to the image yourself at runtime), you should place them in a directory with the nodpi configuration qualifier. Resources with this qualifier are considered density-agnostic and the system will not scale them.

For more information about other configuration qualifiers and how Android selects the appropriate resources for the current screen configuration, see Providing Resources.

Put app icons in mipmap directories

Like all other bitmap assets, you need to provide density-specific versions of your app icon. However, some app launchers display your app icon as much as 25% larger than what’s called for by the device’s density bucket.

For example, if a device’s density bucket is xxhdpi and the largest app icon you provide is in drawable-xxhdpi , the launcher app scales up this icon, and that makes it appear less crisp. So you should provide an even higher density launcher icon in the mipmap-xxxhdpi directory. Now the launcher can use the xxxhdpi asset instead.

Because your app icon might be scaled up like this, you should put all your app icons in mipmap directories instead of drawable directories. Unlike the drawable directory, all mipmap directories are retained in the APK even if you build density-specific APKs. This allows launcher apps to pick the best resolution icon to display on the home screen.

For icon design guidelines, see the material guide for icons.

Use vector graphics instead

An alternative to creating multiple density-specific versions of an image is to create just one vector graphic. Vector graphics create an image using XML to define paths and colors, instead of using pixel bitmaps. As such, vector graphics can scale to any size without scaling artifacts, though they’re usually best for illustrations such as icons, not photographs.

Vector graphics are often provided as an SVG (Scalable Vector Graphics) file, but Android does not support this format so you must convert SVGs files to Android’s vector drawable format.

You can easily convert an SVG to a vector drawable from Android Studio using Vector Asset Studio as follows:

1. In the Project window, right-click on the res directory and select New > Vector Asset.
2. Select Local file (SVG, PSD).

Locate the file you want to import and make any adjustments.

Figure 3. Importing an SVG with Android Studio

You might notice some errors appear in the Asset Studio window, indicating some properties of the file that vector drawables do not support. But this will not prevent you from importing—the unsupported properties are simply ignored.

Click Next.

On the next screen, confirm the source set where you want the file in your project and click Finish.

Because one vector drawable can be used on all pixel densities, this file goes in your default drawables directory (you don’t need to use density-specific directories):

For more information about creating vector graphics, read the Vector Drawable documentation.

Advice for uncommon density issues

This section describes more about how Android performs scaling for bitmaps on different pixel densities and how you can further control how bitmaps are drawn on different densities. Unless your app manipulates graphics or you have encountered problems when running on different pixel densities, you can ignore this section.

To better understand how you can support multiple densities when manipulating graphics at runtime, you should understand that the system helps ensure the proper scale for bitmaps in the following ways:

Pre-scaling of resources (such as bitmap drawables)

Based on the density of the current screen, the system uses any density-specific resources from your app. If resources are not available in the correct density, the system loads the default resources and scales them up or down as needed. The system assumes that default resources (those from a directory without configuration qualifiers) are designed for the baseline pixel density (mdpi) and will resize those bitmaps to the appropriate size for the current pixel density.

If you request the dimensions of a pre-scaled resource, the system returns values representing the dimensions after scaling. For example, a bitmap designed at 50×50 pixels for an mdpi screen is scaled to 75×75 pixels on an hdpi screen (if there is no alternative resource for hdpi) and the system reports the size as such.

There are some situations in which you might not want Android to pre-scale a resource. The easiest way to avoid pre-scaling is to put the resource in a resource directory with the nodpi configuration qualifier. For example:

When the system uses the icon.png bitmap from this folder, it does not scale it based on the current device density.

Auto-scaling of pixel dimensions and coordinates

You can disable pre-scaling dimensions and images by setting android:anyDensity to «false» in the manifest or programmatically for a Bitmap by setting inScaled to «false» . In this case, the system auto-scales any absolute pixel coordinates and pixel dimension values at draw time. It does this to ensure that pixel-defined screen elements are still displayed at approximately the same physical size as they would be at the baseline pixel density (mdpi). The system handles this scaling transparently to the app and reports the scaled pixel dimensions to the app, rather than physical pixel dimensions.

For instance, suppose a device has a WVGA high-density screen, which is 480×800 and about the same size as a traditional HVGA screen, but it’s running an app that has disabled pre-scaling. In this case, the system will «lie» to the app when it queries for screen dimensions, and report 320×533 (the approximate mdpi translation for the pixel density). Then, when the app does drawing operations, such as invalidating the rectangle from (10,10) to (100, 100), the system transforms the coordinates by scaling them the appropriate amount, and actually invalidate the region (15,15) to (150, 150). This discrepancy may cause unexpected behavior if your app directly manipulates the scaled bitmap, but this is considered a reasonable trade-off to keep the performance of apps as good as possible. If you encounter this situation, read Converting dp units to pixel units.

Usually, you should not disable pre-scaling. The best way to support multiple screens is to follow the basic techniques described in this document.

If your app manipulates bitmaps or directly interacts with pixels on the screen in some other way, you might need to take additional steps to support different pixel densities. For example, if you respond to touch gestures by counting the number of pixels that a finger crosses, you need to use the appropriate density- independent pixel values, instead of actual pixels, but you can easily convert between dp and px values.

Test on all pixel densities

It’s important to test your app on multiple devices with different pixel densities so you can ensure your UI scales correctly. Testing on a physical device is easy but you can also use the Android Emulator if you don’t have access to physical devices for all the different pixel densities.

If you would rather test on a physical device, but don’t want to buy the devices, you can use Firebase Test Lab to access devices in a Google data center.

Content and code samples on this page are subject to the licenses described in the Content License. Java is a registered trademark of Oracle and/or its affiliates.

Источник