Как Узнать Размер Экрана Планшета

Поддержка нескольких экранов

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

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

Как выбрать планшет по размеру экрана.

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

Обзор поддержки экранов

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

Условия и понятия

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

Плотность экрана Количество пикселей в физической области экрана; обычно называемый dpi (точек на дюйм). Например, экран с низкой плотностью имеет меньше пикселей в заданной физической области по сравнению с экраном с «нормальной» или «высокой» плотностью.

Для простоты Android группирует все фактические плотности экрана в шесть обобщенных плотностей: низкое, среднее, высокое, сверхвысокое, сверх-экстра-высокое и сверх-экстра-экстра-высокое.

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

Независимый от плотности пиксель эквивалентен одному физическому пикселю на экране с разрешением 160 точек на дюйм, который представляет собой базовую плотность, принимаемую системой для экрана средней плотности. Во время работы система прозрачно обрабатывает любое масштабирование блоков dp ​​по мере необходимости, исходя из фактической плотности используемого экрана. Преобразование блоков dp ​​в пиксели экрана просто: px = dp * (dpi / 160). Например, на экране с разрешением 240 точек на дюйм 1 дп равен 1,5 физическим пикселям. Вы всегда должны использовать модули dp при определении пользовательского интерфейса вашего приложения, чтобы обеспечить правильное отображение вашего интерфейса на экранах с различной плотностью.

Диапазон поддерживаемых экранов

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

Чтобы упростить разработку пользовательских интерфейсов для нескольких экранов, Android делит диапазон фактических размеров экрана и плотности:

Заметка: Начиная с Android 3.2 (уровень API 13), эти группы размеров устарели в пользу нового метода управления размерами экрана на основе доступной ширины экрана. Если вы разрабатываете Android 3.2 и выше, см. Декларация планшета для Android 3.2 для получения дополнительной информации.

480dpi

  • xxxhdpi (Экстра-экстра-экстра-высокий)
  • Каждый обобщенный размер и плотность охватывает диапазон фактических размеров экрана и плотности. Например, два устройства, которые сообщают размер экрана нормальный могут иметь фактические размеры экрана и пропорции, которые немного отличаются при измерении вручную. Аналогично, два устройства, которые сообщают о плотности экрана ИПЧР могут иметь реальную плотность пикселей, которые немного отличаются. Android делает эти различия абстрактными для приложений, поэтому вы можете предоставить пользовательский интерфейс, предназначенный для обобщенных размеров и плотности, и пусть система обрабатывает любые окончательные настройки по мере необходимости. На рисунке 1 показано, как различные размеры и плотности грубо разделяются на группы разного размера и плотности.

    Рисунок 1. Иллюстрация того, как Android грубо сопоставляет фактические размеры и плотности с обобщенными размерами и плотностями (цифры не точны).

    Когда вы разрабатываете свой пользовательский интерфейс для разных размеров экрана, вы обнаружите, что для каждого проекта требуется минимальное пространство. Таким образом, каждый обобщенный размер экрана выше имеет соответствующее минимальное разрешение, определенное системой. Эти минимальные размеры находятся в единицах «dp» - те же единицы, которые вы должны использовать при определении своих макетов, что позволяет системе избежать беспокойства об изменениях плотности экрана.

    • XLarge экраны не менее 960dp x 720dp
    • большой экраны не менее 640dp x 480dp
    • нормальный экраны не менее 470dp x 320dp
    • маленький экраны составляют не менее 426dp x 320dp

    Заметка: Эти минимальные размеры экрана были не так четко определены до Android 3.0, поэтому вы можете столкнуться с некоторыми устройствами, которые неправильно классифицируются между нормальными и большими. Они также основаны на физическом разрешении экрана, поэтому могут варьироваться в зависимости от устройства - например, планшета с разрешением 1024x720 с системной панелью, фактически, имеет немного меньше свободного пространства для приложения из-за того, что он используется системной панелью.

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

    Вам не нужно предоставлять альтернативные ресурсы для каждой комбинации размера и плотности экрана. Система обеспечивает надежные функции совместимости, которые могут обрабатывать большую часть работы по рендерингу вашего приложения на любом экране устройства при условии, что вы внедрили свой пользовательский интерфейс, используя методы, позволяющие его изящно изменять размер (как описано в разделе «Лучшие практики» ниже).

    Заметка: Характеристики, определяющие общий размер и плотность экрана устройства, независимы друг от друга. Например, экран высокой плотности WVGA считается экраном нормального размера, поскольку его физический размер примерно такой же, как у T-Mobile G1 (первое устройство Android и базовая конфигурация экрана). С другой стороны, экран средней плотности WVGA считается экраном большого размера. Хотя он предлагает такое же разрешение (одинаковое количество пикселей), экран со средней плотностью WVGA имеет меньшую плотность экрана, что означает, что каждый пиксель физически больше, и, таким образом, весь экран больше, чем экран базовой линии (нормальный размер) ,

    Независимость плотности

    Ваше приложение достигает «независимости плотности», когда оно сохраняет физический размер (с точки зрения пользователя) элементов пользовательского интерфейса при отображении на экранах с различной плотностью.

    Сохранение независимости плотности важно, поскольку без него элемент пользовательского интерфейса (например, кнопка) физически больше отображается на экране с низкой плотностью и меньше на экране с высокой плотностью. Такие изменения размера, связанные с плотностью, могут вызвать проблемы при планировании и удобстве использования. На рисунках 2 и 3 показана разница между приложением, когда он не обеспечивает независимость от плотности и, когда это происходит, соответственно.

    Фигура 2. Пример применения без поддержки разных плотностей, как показано на экранах с низким, средним и высоким уровнем плотности.

    Рисунок 3. Пример применения с хорошей поддержкой различных плотностей (он не зазавис от плотности), как показано на экранах с низкой, средней и высокой плотностью.

    Система Android помогает вашему приложению добиться независимости плотности двумя способами:

    • Система масштабирует модули dp, соответствующие текущей плотности экрана
    • Система масштабирует доступные ресурсы на соответствующий размер, исходя из текущей плотности экрана, если необходимо

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

    В большинстве случаев вы можете обеспечить независимость плотности в своем приложении, просто указав все значения размеров макета в независимых от плотности пикселей (dp units) или с помощью «wrap_content», если это необходимо. Затем система масштабирует растровые рисунки в зависимости от ситуации, чтобы отображать соответствующий размер на основе соответствующего коэффициента масштабирования для плотности текущего экрана.

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

    Как поддерживать несколько экранов

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

    • Явно объявить в манифесте размеры экрана, поддерживаемые вашим приложением

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

    Чтобы объявить размеры экрана, поддерживаемые вашим приложением, вы должны включить <поддерживает-экраны> элемент в файле манифеста.

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

    Квалификаторы конфигурации, которые вы можете использовать для предоставления ресурсов, зависящих от размера, являются небольшими, нормальными, большими и xlarge. Например, макеты для особо большого экрана должны идти в layout-xlarge /.

    Начиная с Android 3.2 (уровень API 13), вышеупомянутые группы размеров устарели, и вместо этого вы должны использовать sw<N>dp для определения наименьшей доступной ширины, необходимой вашим ресурсам макета. Например, если для вашего планшета с несколькими панелями требуется не менее 600 dpi ширины экрана, вы должны поместить его в layout-sw600dp /. Использование новых методов для объявления ресурсов макета обсуждается далее в разделе «Объявление шаблонов планшетов для Android 3.2».

    По умолчанию Android масштабирует ваши рисунки растровых изображений (.png, .jpg и .gif) и Nine-Patch drawables (файлы .9.png), чтобы они отображались с соответствующим физическим размером на каждом устройстве. Например, если ваше приложение предоставляет растровые чертежи только для базовой линии, плотности среднего экрана (mdpi), система масштабирует их на экране с высокой плотностью и масштабирует их на экране с низкой плотностью. Это масштабирование может вызвать артефакты в растровых изображениях. Чтобы ваши растровые изображения выглядели как можно лучше, вы должны включить альтернативные версии с различными разрешениями для разных плотностей экрана.

    Квалификаторы конфигурации (подробно описанные ниже), которые вы можете использовать для ресурсов плотности: ldpi (low), mdpi (medium), hdpi (high), xhdpi extra-high), xxhdpi (extra-extra-high) и xxxhdpi (extra-extra-extra-high). Например, растровые изображения для экранов с высокой плотностью должны идти в drawable-hdpi /.

    Некоторые устройства масштабируют значок запуска на целых 25%. Например, если изображение пиктограммы с наивысшей плотностью запуска еще более экстра-высокой плотности, процесс масштабирования сделает его менее четким. Таким образом, вы должны предоставить значок запуска более высокой плотности в каталоге mipmap-xxxhdpi, который использует система, вместо того, чтобы масштабировать меньшую версию значка.

    Заметка: Поместите все ваши значки запуска в папку res / mipmap- / папки, а не res / drawable / папки. Система Android сохраняет ресурсы в этих папках с определенной плотностью, например mipmap-xxxhdpi, независимо от разрешения экрана устройства, на котором установлено ваше приложение. Такое поведение позволяет запускать приложения, чтобы отображать значок лучшего разрешения для вашего приложения для отображения на главном экране. Дополнительные сведения об использовании папок mipmap см. В разделе «Управление проектами».

    Конфигураторы конфигурации размера и плотности соответствуют обобщенным размерам и плотности, описанным выше в разделе Поддерживаемые экраны.

    Заметка: Если вы не знакомы с классификаторами конфигурации и как система использует их для применения альтернативных ресурсов, прочитайте «Предоставление альтернативных ресурсов» для получения дополнительной информации.

    Во время выполнения система обеспечивает наилучшее отображение на текущем экране со следующей процедурой для любого заданного ресурса:

    1. Система использует соответствующий альтернативный ресурс

    Основываясь на размере и плотности текущего экрана, система использует любой размер и плотность ресурсов, предоставляемых в вашем приложении. Например, если устройство имеет экран с высокой плотностью и приложение запрашивает ресурс, пригодный для переноски, система ищет каталог ресурса, который подходит для конфигурации устройства, который наилучшим образом соответствует конфигурации устройства. В зависимости от других доступных альтернативных ресурсов каталог ресурсов с квалификатором hdpi (например, drawable-hdpi /) может быть лучшим совпадением, поэтому система использует ресурс с возможностью извлечения из этого каталога.

    Ресурсами по умолчанию являются те, которые не помечены спецификатором конфигурации. Например, ресурсы в drawable / являются доступными по умолчанию ресурсами. Система предполагает, что ресурсы по умолчанию предназначены для базового размера и плотности экрана, который является обычным размером экрана и средней плотностью. Таким образом, система масштабирует ресурсы плотности по умолчанию для экранов с высокой плотностью и, соответственно, вниз для экранов с низкой плотностью.

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

    Для получения дополнительной информации о том, как Android выбирает альтернативные ресурсы, сопоставляя квалификаторы конфигурации с конфигурацией устройства, прочитайте «Как Android» найдет наилучший ресурс.

    Использование спецификаторов конфигурации

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

    Чтобы использовать квалификатор конфигурации:

    1. Создайте новый каталог в директории res / проекта и назовите его в формате: <resources_name>-<спецификатор>
      • <resources_name> это стандартное имя ресурса (например, drawable или layout).
      • <спецификатор> является классификатором конфигурации из таблицы 1 ниже, указывая конфигурацию экрана, для которой эти ресурсы должны использоваться (например, hdpi или xlarge).

      Вы можете использовать более одного <спецификатор> в то время - просто отделите каждый квалификатор с тире.

      Например, xlarge является спецификатором конфигурации для сверхбольших экранов. Когда вы добавляете эту строку в имя каталога ресурса (например, layout-xlarge), она указывает системе, что эти ресурсы должны использоваться на устройствах с очень большим экраном.

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

      160dpi). (Это базовая плотность.)

      Заметка: Если вы разрабатываете приложение для Android 3.2 и выше, см. Раздел «Декларирование планшетных макетов для Android 3.2» для получения информации о новых квалификаторах конфигурации, которые следует использовать при объявлении ресурсов макета для определенных размеров экрана (вместо использования спецификаторов размера в таблице 1).

      Для получения дополнительной информации о том, как эти квалификаторы примерно соответствуют реальным размерам экрана и плотности, см. Раздел «Поддерживаемые экраны», ранее в этом документе.

      Например, следующие каталоги ресурсов приложений предоставляют различные схемы компоновки для разных размеров экрана и различных чертежей. Используйте mipmap / folders для значков запуска.

      Дополнительные сведения об использовании альтернативных ресурсов и полный список спецификаторов конфигурации (не только для конфигураций экрана) см. В разделе «Предоставление альтернативных ресурсов».

      Имейте в виду, что, когда система Android выбирает, какие ресурсы использовать во время выполнения, она использует определенную логику для определения «наилучшего соответствия» ресурсам. То есть, используемые вами квалификаторы не должны точно соответствовать текущей конфигурации экрана во всех случаях, чтобы система их использовала. В частности, при выборе ресурсов на основе определителей размера система будет использовать ресурсы, предназначенные для экрана, меньшего, чем текущий экран, если нет ресурсов, которые лучше соответствуют (например, на большом экране экран будет использовать ресурсы экрана обычного размера, если необходимо). Однако, если доступны только доступные ресурсы больше чем текущий экран, система не будет их использовать, и ваше приложение выйдет из строя, если никакие другие ресурсы не совпадут с конфигурацией устройства (например, если все ресурсы макета отмечены спецификатором xlarge, но устройство является экраном нормального размера). Для получения дополнительной информации о том, как система выбирает ресурсы, читайте «Как Android называет ресурс наилучшего соответствия».

      Наконечник: Если у вас есть доступные ресурсы, которые система никогда не должна масштабировать (возможно, потому, что вы выполняете некоторые корректировки изображения самостоятельно во время выполнения), вы должны поместить их в каталог с квалификатором конфигурации nodpi. Ресурсы с этим квалификатором считаются плотно-агностическими, и система не будет масштабировать их.

      Проектирование альтернативных макетов и чертежей

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

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

      Альтернативные макеты

      Как правило, вы узнаете, нужны ли вам альтернативные макеты для разных размеров экрана после тестирования вашего приложения на разных конфигурациях экрана. Например:

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

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

      Подводя итог, вы должны быть уверены, что ваш макет приложения:

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

      Если ваш пользовательский интерфейс использует растровые изображения, которые должны соответствовать размеру представления даже после того, как система масштабирует макет (например, фоновое изображение для кнопки), вы должны использовать файлы растровых изображений Nine-Patch. Файл Nine-Patch представляет собой файл PNG, в котором вы указываете двумерные области, которые можно растягивать. Когда системе необходимо масштабировать представление, в котором используется растровое изображение, система растягивает растровое изображение Nine-Patch, но растягивает только указанные области. Таким образом, вам не нужно предоставлять различные рисунки для разных размеров экрана, так как растровое изображение Nine-Patch может настраиваться на любой размер. Однако вы должны предоставить альтернативные версии ваших файлов Nine-Patch для разных плотностей экрана.

      Альтернативные чертежи

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

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

      Заметка: Вам нужно только предоставить чертежи с плотностью для файлов растровых изображений (.png, .jpg или .gif) и файлов Nine-Patch (.9.png). Если вы используете XML-файлы для определения фигур, цветов или других доступных ресурсов, вы должны поместить одну копию в каталог по умолчанию (drawable /).

      Чтобы создать альтернативные чертежи растровых изображений для разных плотностей, вы должны следовать 3: 4: 6: 8: 12: 16 между шестью обобщенными плотностями. Например, если у вас есть растровое изображение, равное 48x48 пикселям для экранов со средней плотностью, все разные размеры должны быть:

      • 36x36 (0,75x) для низкой плотности
      • 48x48 (базовый уровень 1,0x) для среды с низкой плотностью
      • 72x72 (1,5x) для высокой плотности
      • 96x96 (2.0x) для сверхвысокой плотности
      • 144x144 (3.0x) для сверхвысокой плотности
      • 192x192 (4.0x) для сверх-сверхвысокой плотности

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

      Объявление планшета для Android 3.2

      Для первого поколения планшетов, работающих под управлением Android 3.0, правильный способ объявить макеты планшета состоял в том, чтобы поместить их в каталог с квалификатором конфигурации xlarge (например, res / layout-xlarge /). Для размещения других типов планшетов и размеров экрана, в частности, 7-дюймовые планшеты Android 3.2 представляют новый способ указания ресурсов для более дискретных размеров экрана. Новая методика основана на количестве пространства, которое требуется вашему макету (например, 600dp ширины), вместо того, чтобы пытаться сделать ваш макет подходящим для групп обобщенного размера (например, большой или XLarge).

      Причиной проектирования для 7-дюймовых планшетов сложно, когда использование обобщенных групп размеров состоит в том, что 7-дюймовый планшет технически находится в той же группе, что и 5-дюймовая телефонная трубка большой группа). Хотя эти два устройства кажутся близкими друг к другу по размеру, объем пространства для пользовательского интерфейса приложения существенно отличается, как и стиль взаимодействия с пользователем. Таким образом, экран 7 "и 5" не всегда должен использовать один и тот же макет. Чтобы вы могли предоставить разные макеты для этих двух видов экранов, Android теперь позволяет вам указать ресурсы макета на основе ширины и / или высоты, которые действительно доступны для макета вашего приложения, указанного в единицах dp.

      Например, после того, как вы разработали макет, который хотите использовать для устройств с планшетом, вы можете определить, что макет перестает работать, когда экран имеет ширину менее 600 дБ. Таким образом, этот порог становится минимальным размером, который требуется для раскладки планшета. Таким образом, вы можете теперь указать, что эти ресурсы макета должны использоваться только тогда, когда для пользовательского интерфейса вашего приложения доступно не менее 600dp ширины.

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

      Заметка: Помните, что все фигуры, используемые с этими API-интерфейсами нового размера, представляют собой значения плотности пикселя (dp), не зависящие от плотности, и ваши размеры макета также должны всегда определяться с помощью блоков dp, потому что то, что вам нужно, это объем пространства экрана, доступный после системных учетных записей плотность экрана (в отличие от использования необработанного пиксельного разрешения). Для получения дополнительной информации о не зависящих от плотности пикселях читайте «Условия и понятия» ранее в этом документе.

      Использование классификаторов нового размера

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

      Заметка: Размеры, указанные вами с помощью этих не фактические размеры экрана. Скорее, размеры для ширины или высоты в единицах dp, которые доступный для windows вашей деятельности. Система Android может использовать часть экрана для пользовательского интерфейса системы (например, системную панель в нижней части экрана или строку состояния вверху), поэтому некоторые из экранов могут быть недоступны для вашего макета. Таким образом, размеры, которые вы объявляете, должны быть конкретно о размерах, необходимых для вашей деятельности, - система учитывает любое пространство, используемое системным интерфейсом, при объявлении, сколько места оно предоставляет для вашего макета. Также будьте осторожны, что панель действий считается частью windows вашего приложения, хотя ваш макет не объявляет об этом, поэтому он уменьшает пространство, доступное для вашего макета, и вы должны учитывать его в своем дизайне.

      Таблица 2. Новые настройки конфигурации для размера экрана (представлены в Android 3.2).

      Фундаментальный размер экрана, о чем свидетельствует кратчайший размер доступной площади экрана. В частности, наименьшая ширина устройства является самой короткой из доступных по высоте и ширине экрана (вы можете также считать ее «минимальной шириной» для экрана). Вы можете использовать этот квалификатор, чтобы гарантировать, что независимо от текущей ориентации экрана у вашего приложения есть как минимум <N> dps ширины, доступной для его пользовательского интерфейса.

      Например, если ваш макет требует, чтобы его наименьший размер области экрана был не менее 600 д.п., вы можете использовать этот квалификатор для создания ресурсов макета, res / layout-sw600dp /. Система будет использовать эти ресурсы только тогда, когда наименьший размер доступного экрана составляет не менее 600dp, независимо от того, является ли сторона 600dp воспринимаемой пользователем высотой или шириной. Наименьшая ширина - это фиксированный размер экрана, характерный для устройства; наименьшая ширина устройства не изменяется при изменении ориентации экрана.

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

      Это альтернатива обобщенным спецификаторам размера экрана (малый, нормальный, большой, xlarge), который позволяет вам определить дискретное число для эффективного размера, доступного для вашего пользовательского интерфейса. Использование smallestWidth для определения общего размера экрана полезно, потому что ширина часто является движущей силой при разработке макета. Пользовательский интерфейс часто прокручивается по вертикали, но имеет довольно жесткие ограничения на минимальное пространство, которое требуется горизонтально. Доступная ширина также является ключевым фактором при определении того, следует ли использовать однопанельный макет для мобильных телефонов или многоуровневую компоновку для планшетов. Таким образом, вы, вероятно, больше всего заботитесь о том, какая минимально возможная ширина будет на каждом устройстве.

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

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

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

      Использование этого для определения высоты, необходимой вашему макету, полезно так же, как и w<N>dp - для определения требуемой ширины вместо использования как размера экрана, так и определения ориентации. Тем не менее, большинству приложений не понадобится этот определитель, учитывая, что пользовательские интерфейсы часто прокручиваются по вертикали и, таким образом, более гибки в зависимости от того, сколько высоты доступно, тогда как ширина более жесткая.

      Хотя использование этих квалификаторов может показаться более сложным, чем использование групп размеров экрана, на самом деле это будет проще, если вы определите требования к своему пользовательскому интерфейсу. Когда вы разрабатываете свой пользовательский интерфейс, главное, о чем вы, вероятно, заботитесь, - это фактический размер, при котором ваше приложение переключается между пользовательским интерфейсом в стиле телефона и пользовательским интерфейсом в стиле планшета, который использует несколько панелей. Точная точка этого переключателя будет зазавис от вашего конкретного дизайна - возможно, вам нужна ширина 720dp для вашего планшета планшета, возможно, 600dp достаточно или 480dp, или некоторое число между ними. Используя эти квалификаторы в таблице 2, вы контролируете точный размер, при котором изменяется ваш макет.

      Дополнительные сведения об этих спецификаторах конфигурации размеров см. В документе «Предоставление ресурсов».

      Примеры конфигурации

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

      • 320dp: обычный экран телефона (240x320 ldpi, 320x480 mdpi, 480x800 hdpi и т. Д.).
      • 480dp: планшет Tweener, такой как Streak (480x800 mdpi).
      • 600dp: 7-дюймовый планшет (600x1024 mdpi).
      • 720dp: 10-дюймовый планшет (720x1280 mdpi, 800x1280 mdpi и т. Д.).

      Используя квалификаторы размеров из таблицы 2, ваше приложение может переключаться между различными ресурсами макета для телефонов и планшетов, используя любое число, которое вы хотите использовать для ширины и / или высоты. Например, если 600dp - самая маленькая доступная ширина, поддерживаемая вашим планшетом планшета, вы можете предоставить эти два набора макетов:

      В этом случае наименьшая ширина доступного пространства экрана должна быть 600dp, чтобы план табло был применен.

      В других случаях, когда вы хотите дополнительно настроить свой пользовательский интерфейс, чтобы различать такие размеры, как 7 "и 10" планшеты, вы можете определить дополнительные макеты минимальной ширины:

      Обратите внимание, что в предыдущих двух наборах примеров ресурсов используется определитель «наименьшей ширины», sw<N>dp, который определяет наименьшую из двух сторон экрана, независимо от текущей ориентации устройства. Таким образом, используя sw<N>dp - это простой способ указать общий размер экрана, доступный для вашего макета, игнорируя ориентацию экрана.

      Однако, в некоторых случаях, что может быть важно для вашего макета, это точно, насколько ширина или высота В данный момент доступный. Например, если у вас есть двухпанельный макет с двумя фрагментами бок о бок, вы можете использовать его всякий раз, когда экран обеспечивает ширину не менее 600dp, независимо от того, находится ли устройство в альбомной или портретной ориентации. В этом случае ваши ресурсы могут выглядеть так:

      Обратите внимание, что второй набор использует квалификатор «доступной ширины», w<N>dp. Таким образом, одно устройство может фактически использовать оба макета в зависимости от ориентации экрана (если доступная ширина не менее 600 дп в одной ориентации и менее 600 дп в другой ориентации).

      Если доступная высота вас беспокоит, вы можете сделать то же самое, используя h<N>dp. Или, даже объединяя w<N>dp и h<N>dp, если вам нужно быть конкретным.

      Объявление поддержки размера экрана

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

      Наряду с новыми настройками конфигурации для размера экрана, Android 3.2 вводит новые атрибуты для <поддерживает-экраны> Явный элемент:

      android: requireSmallestWidthDp Указывает минимальную минимальную ширину. Наименьшая ширина - это кратчайший размер пространства экрана (в единицах dp), который должен быть доступен для вашего пользовательского интерфейса приложения - это самый короткий из двух размеров доступного экрана. Таким образом, для того, чтобы устройство считалось совместимым с вашим приложением, наименьшая ширина устройства должна быть равна или больше этого значения. (Обычно значение, которое вы предоставляете для этого, представляет собой «минимальную ширину», которую поддерживает ваш макет, независимо от текущей ориентации экрана.)

      Например, если ваше приложение предназначено только для устройств с планшетом с минимальной доступной шириной 600dp:

      Однако, если ваше приложение поддерживает все размеры экрана, поддерживаемые Android (размером 426dp x 320dp), вам не нужно объявлять этот атрибут, потому что минимальная ширина вашего приложения минимально возможна на любом устройстве.

      Внимание: Система Android не обращает внимания на этот атрибут, поэтому она не влияет на поведение приложения во время выполнения. Вместо этого он используется для фильтрации фильтрации для вашего приложения на таких сервисах, как Google Play. Этот атрибут применяется только к устройствам под управлением Android 3.2 (API уровня 13) и выше.

      android: compatibleWidthLimitDp Этот атрибут позволяет включить режим совместимости с экраном в качестве пользовательской дополнительной функции, указав максимальную «минимальную ширину», поддерживаемую вашим приложением. Если самая маленькая часть доступного экрана устройства больше вашего значения, пользователи все равно могут установить ваше приложение, но им предлагается запустить его в режиме совместимости с экраном. По умолчанию режим совместимости с экраном отключен, и размер макета изменяется в соответствии с настройками экрана, как обычно, но на системной панели имеется кнопка, которая позволяет пользователям включать и выключать режим совместимости экрана.

      Заметка: Если макет вашего приложения правильно изменяет размеры для больших экранов, вам не нужно использовать этот атрибут. Мы рекомендуем избегать использования этого атрибута и вместо этого обеспечить изменение размера макета для больших экранов, следуя рекомендациям этого документа.

      android: maximumWidthLimitDp Этот атрибут позволяет принудительно активировать режим совместимости экрана, указав максимальную «минимальную ширину», поддерживаемую вашим приложением. Если наименьшая часть доступного экрана устройства больше вашего значения, приложение запускается в режиме совместимости с экраном, и пользователь не может отключить его.

      Заметка: Если макет вашего приложения правильно изменяет размеры для больших экранов, вам не нужно использовать этот атрибут. Мы рекомендуем избегать использования этого атрибута и вместо этого обеспечить изменение размера макета для больших экранов, следуя рекомендациям этого документа.

      Внимание: При разработке для Android 3.2 и выше не следует использовать более старые атрибуты размера экрана в сочетании с перечисленными выше атрибутами. Использование новых атрибутов и атрибутов более старого размера может привести к неожиданному поведению.

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

      Объявление максимального соотношения сторон

      Приложение может объявить максимальное соотношение сторон, которое оно может поддерживать. Если приложение работает на устройстве (или на части экрана), соотношение сторон которого больше, чем максимальное соотношение сторон приложения, система автоматически отправляет почтовые ящики в приложение, оставляя части экрана неиспользованными, поэтому приложение может работать с указанным максимальным аспектом соотношение.

      Заметка: Если значение атрибута android: resizeableActivity равно true, приложение не может иметь максимальное соотношение сторон, независимо от того, явно ли вы указали его. В этом случае приложение использует родное соотношение сторон устройства. В Android 7.0 (API level 24) и выше, android: resizeableActivity по умолчанию соответствует true. Вы должны установить для этого атрибута значение false для максимального соотношения сторон, которое вы ввели в силу.

      Большинство устройств не поддерживают соотношение ниже 16: 9; некоторые устройства поддерживают более высокие отношения, чем 16: 9. Кроме того, если устройство работает в многооконном режиме, приложение может работать в части экрана, которая намного шире, чем высокая.

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

      Максимальное соотношение сторон в Android 8.0 и выше

      Если ваше приложение предназначено для Android 8.0 (уровень API 26) или выше, максимальный коэффициент сжатия по умолчанию - это родное соотношение сторон устройства, на котором работает приложение.

      Чтобы установить явное максимальное соотношение сторон, объявите атрибут android: maxAspectRatio, указав коэффициент в десятичной форме. На устройствах, отличных от носимых, вы должны указать значение не менее 1,33; на носимых устройствах минимальное значение равно 1,0. Если вы укажете значение меньше соответствующего минимума, система использует значение по умолчанию.

      В следующем примере показано, как объявить максимальное соотношение сторон 7: 3 или 2.33.

      Мы рекомендуем вам разработать приложение для поддержки пропорций в 2,1 или выше, если это возможно.

      Максимальное соотношение сторон в Android 7.1 и ниже

      Если ваше приложение предназначено для Android 7.1 (уровень API 25) или ниже, максимальный формат изображения по умолчанию - 16: 9 или приблизительно 1,86.

      Чтобы установить максимальное соотношение сторон, объявите <мета-данные> элемент с именем android.max_aspect в приложении <заявление> элемент, определяющий отношение в десятичной форме. На устройствах, отличных от носимых, вы должны указать значение не менее 1,33; на носимых устройствах минимальное значение равно 1,0. Если вы укажете значение меньше соответствующего минимума, система использует значение по умолчанию.

      В следующем примере показано, как объявить максимальное соотношение сторон 3: 1 или 3.0:

      Мы рекомендуем вам разработать приложение для поддержки пропорций в 2,1 или выше, если это возможно.

      Лучшие практики

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

      Вот быстрый контрольный список о том, как вы можете обеспечить правильное отображение вашего приложения на разных экранах:

      1. Используйте параметры wrap_content, match_parent или dp при указании размеров в файле макета XML
      2. Не используйте жестко закодированные значения пикселей в коде приложения
      3. Не используйте AbsoluteLayout (он устарел)
      4. Поставлять альтернативные рисунки растровых изображений для различных плотностей экрана

      В следующих разделах приведены более подробные сведения.

      1. Используйте параметр wrap_content, match_parent или dp для параметров макета

      При определении андроида: layout_width и android: layout_height для представлений в файле макета XML с использованием элементов «wrap_content», «match_parent» или dp гарантирует, что на экране будет отображаться соответствующий размер.

      Например, представление с layout_width = «100dp» измеряет ширину 100 пикселей на экране средней плотности, а система масштабирует его до 150 пикселей на экране высокой плотности, так что вид занимает примерно такое же физическое пространство на экране ,

      Аналогично, вы должны предпочесть sp (не зависящий от масштаба пиксель) для определения размеров текста. Коэффициент масштабирования sp зазавис от пользовательской настройки, и система масштабирует размер так же, как и для dp.

      2. Не используйте жестко закодированные значения пикселей в коде приложения.

      По соображениям производительности и упрощения кода система Android использует пиксели в качестве стандартного устройства для выражения размеров или значений координат. Это означает, что размеры представления всегда выражаются в коде с использованием пикселей, но всегда зависят от текущей плотности экрана. Например, если myView.getWidth () возвращает 10, вид будет иметь ширину 10 пикселей на текущем экране, но на устройстве с экраном с более высокой плотностью возвращаемое значение может быть 15. Если вы используете значения пикселей в коде приложения для работа с растровыми изображениями, которые не предварительно масштабируются для текущей плотности экрана, вам может потребоваться масштабировать значения пикселей, которые вы используете в своем коде, в соответствии с немасштабированным источником растрового изображения.

      Если ваше приложение управляет растровыми изображениями или имеет дело с значениями пикселей во время выполнения, см. Раздел ниже «Дополнительные соображения плотности».

      3. Не используйте AbsoluteLayout

      В отличие от других виджетов макетов, AbsoluteLayout обеспечивает использование фиксированных позиций для размещения своих дочерних представлений, что может легко привести к тому, что пользовательские интерфейсы не будут работать на разных дисплеях. Из-за этого AbsoluteLayout устарел в Android 1.5 (API Level 3).

      Вместо этого вы должны использовать RelativeLayout, который использует относительное позиционирование для размещения своих дочерних представлений. Например, вы можете указать, что виджет кнопки должен появиться «справа от» текстового виджета.

      4. Используйте ресурсы размера и плотности

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

      Если вам нужно точно контролировать, как ваше приложение будет выглядеть в разных конфигурациях экрана, отрегулируйте макеты и рисунки растровых изображений в каталогах ресурсов для конкретных конфигураций. Например, рассмотрите значок, который вы хотите отображать на экранах средней и высокой плотности. Просто создайте свой значок на двух разных размерах (например, 100x100 для средней плотности и 150x150 для высокой плотности) и поместите два варианта в соответствующие каталоги, используя соответствующие квалификаторы:

      Заметка: Если определитель плотности не определен в имени каталога, система предполагает, что ресурсы в этом каталоге предназначены для базовой плотности среды и будут масштабироваться для других плотностей, если это необходимо.

      Дополнительные сведения о допустимых квалификаторах конфигурации см. В разделе «Использование спецификаторов конфигурации» ранее в этом документе.

      Дополнительные соображения плотности

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

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

      1. Предварительное масштабирование ресурсов (например, рисование растровых изображений)

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

      Если вы запрашиваете размеры предварительно масштабированного ресурса, система возвращает значения, представляющие размеры после масштабирование. Например, растровое изображение, рассчитанное на 50x50 пикселей для экрана mdpi, масштабируется до 75x75 пикселей на экране hdpi (если нет альтернативного ресурса для hdpi), и система сообщает размер как таковой.

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

      Когда система использует растровое изображение icon.png из этой папки, оно не масштабирует его на основе текущей плотности устройства.

      Приложение может отключить предварительное масштабирование, установив android: anyDensity для «false» в манифесте или программно для Bitmap, установив inScaled в «false». В этом случае система автоматически масштабирует любые абсолютные пиксельные координаты и значения размера пикселя во время рисования. Это делается для обеспечения того, чтобы элементы экрана, определенные в пикселях, все еще отображались примерно на том же физическом уровне, что и при базовой плотности экрана (mdpi). Система обрабатывает это масштабирование прозрачно для приложения и сообщает размеру масштабированного размера приложения, а не размеры физического пикселя.

      Например, предположим, что устройство имеет WVGA-экран с высокой плотностью, который составляет 480x800 и примерно того же размера, что и традиционный экран HVGA, но на нем работает приложение, которое отключило предварительное масштабирование. В этом случае система будет «лежать» в приложении, когда она запрашивает размеры экрана, и сообщает 320x533 (приблизительный перевод mdpi для плотности экрана). Затем, когда приложение выполняет операции рисования, такие как недействительность прямоугольника от (10,10) до (100, 100), система преобразует координаты, масштабируя их соответствующую сумму и фактически аннулирует область (15,15) до (150, 150). Это несоответствие может привести к неожиданному поведению, если ваше приложение напрямую манипулирует масштабированным растровым изображением, но это считается разумным компромиссом, чтобы максимально повысить производительность приложений. Если вы столкнулись с этой ситуацией, прочитайте следующий раздел о преобразовании единиц dp в единицы пикселей.

      Как правило, вам не следует отключать предварительное масштабирование. Лучший способ поддержки нескольких экранов - следовать основным методам, описанным выше в разделе «Поддержка нескольких экранов».

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

      Масштабирование объектов Bitmap, созданных во время выполнения

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

      Если ваше приложение создает растровое изображение в памяти (объект Bitmap), система предполагает, что битмап предназначен для базового экрана средней плотности по умолчанию и автоматически масштабирует битмап во время рисования. Система применяет «автоматическое масштабирование» к растровому изображению, когда растровое изображение имеет неопределенные свойства плотности. Если вы неправильно учитываете плотность экрана текущего устройства и указываете свойства плотности растрового изображения, автоматическое масштабирование может привести к масштабированию артефактов так же, как если бы вы не предоставляли альтернативные ресурсы.

      Чтобы контролировать, масштабируется ли растровое изображение, созданное во время выполнения, вы можете указать плотность растрового изображения с помощью setDensity (), передавая константу плотности из DisplayMetrics, такую ​​как DENSITY_HIGH или DENSITY_LOW.

      Если вы создаете Bitmap, используя BitmapFactory, например, из файла или потока, вы можете использовать BitmapFactory.Options для определения свойств растрового изображения, поскольку он уже существует, который определяет, будет ли и как система будет масштабировать его. Например, вы можете использовать поле inDensity для определения плотности, для которой сконфигурировано растровое изображение, и в поле inScaled указать, следует ли масштабировать растровое изображение для соответствия плотности экрана текущего устройства.

      Если вы установите для поля inScaled значение false, то вы отключите любое предварительное масштабирование, которое система может применить к растровому изображению, и затем система автоматически масштабирует его во время рисования. Использование автоматического масштабирования вместо предварительного масштабирования может быть более дорогостоящим процессором, но использует меньше памяти.

      На рисунке 5 показаны результаты механизмов предварительного масштабирования и автомасштабирования при загрузке изображений с низкой (120), средней (160) и высокой (240) плотностью на экране с высокой плотностью. Различия тонкие, потому что все растровые изображения масштабируются в соответствии с текущей плотностью экрана, однако масштабированные растровые изображения имеют несколько разные проявления в зависимости от того, были ли они предварительно масштабированы или автомасштабированы во время рисования.

      Заметка: В Android 3.0 и выше не должно быть ощутимой разницы между предварительно масштабированными и автоматически масштабированными растровыми изображениями из-за улучшения в графической структуре.

      Преобразование блоков dp ​​в пиксельные единицы

      В некоторых случаях вам нужно будет выразить измерения в dp, а затем преобразовать их в пиксели. Представьте себе приложение, в котором признак прокрутки или бега распознается после того, как палец пользователя перемещается по меньшей мере на 16 пикселей. На экране базовой линии пользователь должен перемещаться на 16 пикселов / 160 точек на дюйм, что равно 1/10 дюйма (или 2,5 мм) до того, как распознается жест. На устройстве с дисплеем высокой плотности (240 точек на дюйм) пользователь должен перемещаться на 16 пикселей / 240 точек на дюйм, что равно 1/15 дюйма (или 1,7 мм). Расстояние намного короче, и приложение, таким образом, становится более чувствительным к пользователю.

      Чтобы исправить эту проблему, порог жестов должен быть выражен в коде в dp, а затем преобразован в фактические пиксели. Например:

      Поле DisplayMetrics.density указывает коэффициент масштабирования, который вы должны использовать для преобразования единиц dp в пиксели в соответствии с текущей плотностью экрана. На экране средней плотности DisplayMetrics.density равен 1.0; на экране с высокой плотностью он равен 1,5; на экране с повышенной плотностью он равен 2,0; и на экране с низкой плотностью он равен 0,75. Эта цифра является фактором, с помощью которого вы должны умножить единицы измерения dp на порядок, чтобы получить фактическое количество пикселей для текущего экрана. (Затем добавьте 0.5f для округления фигуры до ближайшего целого числа при преобразовании в целое число.) Для получения дополнительной информации обратитесь к классу DisplayMetrics.

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

      Использование предварительно заданных значений конфигурации

      Вы можете использовать класс ViewConfiguration для доступа к общим расстояниям, скоростям и времени, используемым системой Android. Например, расстояние в пикселях, используемое каркасом в качестве порога прокрутки, может быть получено с помощью getScaledTouchSlop ():

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

      Как протестировать приложение на нескольких экранах

      Рисунок 6. Поддерживается набор AVD для тестирования экранов.

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

      Чтобы настроить среду для проверки поддержки экрана вашего приложения, вы должны создать серию AVD (Android Virtual Devices), используя скины эмулятора и конфигурации экрана, которые эмулируют размеры экрана и плотность, которую вы хотите, чтобы ваше приложение поддерживало. Для этого вы можете использовать AVD Manager для создания AVD и запускать их с помощью графического интерфейса.

      Чтобы запустить Android SDK Manager, выполните SDK Manager.exe из каталога Android SDK (только для Windows) или выполните андроид с <SDK>/ tools / (на всех платформах). На рисунке 6 показан AVD Manager с выбором AVD для тестирования различных конфигураций экрана.

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

      Дополнительные сведения о создании и использовании AVD для тестирования приложения см. В разделе Управление AVD с помощью AVD Manager.

      Таблица 3. Различные конфигурации экрана доступны из скинов эмулятора в SDK Android (выделено жирным шрифтом) и других репрезентативных разрешений.

      † Этот скин доступен с платформой Android 3.0

      Чтобы увидеть относительные числа активных устройств, которые поддерживают любую конфигурацию экрана, см. Панель инструментов «Размеры экрана и плотность».

      Рисунок 7. Параметры размера и плотности, которые вы можете установить, при запуске AVD из AVD Manager.

      Мы также рекомендуем вам протестировать ваше приложение в эмуляторе, который настроен для работы с физическим размером, который точно соответствует фактическому устройству. Это значительно облегчает сравнение результатов при различных размерах и плотностях. Для этого вам нужно знать приблизительную плотность в dpi на мониторе компьютера (например, монитор Dell Dell размером 30 дюймов имеет плотность около 96 точек на дюйм). Когда вы запускаете AVD из AVD Manager, вы можете указать размер экрана для эмулятора и тэг монитора в параметрах запуска, как показано на рисунке 7.

      Если вы хотите протестировать приложение на экране с разрешением или плотностью, не поддерживаемыми встроенными скинами, вы можете создать AVD, который использует настраиваемое разрешение или плотность. При создании AVD из AVD Manager задайте разрешение вместо выбора встроенного скина.

      Если вы запускаете AVD из командной строки, вы можете указать масштаб для эмулятора с опцией -scale. Например:

      Чтобы уточнить размер эмулятора, вместо этого вы можете передать опцию -scale число от 0,1 до 3, которое представляет желаемый коэффициент масштабирования.

      Дополнительные сведения о создании AVD из командной строки см. В разделе Управление AVD из командной строки.

      За исключением случаев, отмеченных, этот контент лицензируется в соответствии с Creative Commons Attribution 2.5. Подробности и ограничения см. В Лицензии на контент.

      Получите последние новости и советы разработчиков Android, которые помогут вам найти успех в Google Play.

      Ура!

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

      Следите за новостями от разработчиков Google в WeChat

      Просмотрите этот сайт?

      Вы запросили страницу, но предпочитаете использовать этот язык для этого сайта.

      Вы хотите изменить свой языковой настрой и просмотреть этот сайт? Если вы хотите позже изменить свой язык, используйте языковое меню внизу каждой страницы.

      Для этого класса требуется уровень API или выше.

      Этот документ скрыт, потому что выбранный вами уровень API для документации. Вы можете изменить уровень API документации с помощью селектора над левой навигацией.

      Для получения дополнительной информации о указании уровня API, которое требуется вашему приложению, читайте в разделе «Поддержка разных версий платформы».

      Похожие вопросы