Какое разрешение экрана следует учитывать при разработке приложения для Android?

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

Я нашел эти вещи:

xlarge экраны имеют разрешение не менее 960dp x 720dp

большие экраны не менее 640dp x 480dp

обычные экраны имеют разрешение не менее 470dp x 320dp

маленькие экраны имеют разрешение не менее 426dp x 320dp

Какие разрешения устройств следует учитывать при разработке приложений для Android?

но на самом деле это не то, что я хотел.

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

or

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

or

насколько это хорошо - найти ширину и высоту устройства с помощью показателей отображения и создать все представления в соответствии с этими значениями Динамически?


person Archie.bpgc    schedule 03.07.2012    source источник
comment
Вы должны проектировать свое приложение таким образом, чтобы оно не зависело от разрешения, как это делали десктопные и веб-разработчики в течение нескольких десятилетий.   -  person CommonsWare    schedule 03.07.2012


Ответы (4)


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

Вы должны убедиться, что ваше приложение корректно работает на всех экранах, а не только на самом популярном. Я бы начал снизу вверх... сначала убедитесь, что он работает правильно на маленьких/обычных экранах (и при этом вы убедитесь, что он работает на всех экранах). Затем вы можете оптимизировать свои макеты для планшетов, используя макеты с несколькими панелями и т. д.

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

Не знаю, что вы хотите этим сказать, но вы должны всегда с осторожностью относиться к разным разрешениям экрана, используя dp (пиксели, не зависящие от плотности) вместо px.

Найти ширину и высоту устройства с помощью показателей отображения и динамически создавать все представления в соответствии с этими значениями?

Это должно быть последним средством. Однако в большинстве случаев ваши макеты не будут такими сложными, и в этом нет необходимости. В большинстве случаев вы будете использовать wrap_content и match_parent для установки ширины/высоты, и часто вы будете использовать RelativeLayout для размещения представлений относительно друг друга. Вам действительно нужно измерять ширину/высоту представлений только в том случае, если вы считаете это абсолютно необходимым.

person Alex Lockwood    schedule 03.07.2012
comment
под 2-й точкой я имею в виду .... используя только обертку содержимого, заполнение родителя, совпадение родителя и т. д. вместо 10dp/10px - person Archie.bpgc; 03.07.2012
comment
Вы никогда не должны использовать px, так как он плохо масштабируется для устройств с разной плотностью. Можно использовать dp, если это не смешно. т. е. если у вас есть кнопка шириной 20dp, это прекрасно в 99% случаев. Вам просто нужно знать о границах... т. е. если вы установите ширину кнопки так, чтобы она выходила за край экрана, тогда вы захотите использовать показатели отображения, например, для проверки ширины экрана. . Но опять же, это не должно быть проблемой слишком часто. Это еще одна причина, по которой простые макеты с меньшим количеством просмотров облегчают вам жизнь :) - person Alex Lockwood; 03.07.2012
comment
хорошо... значит, использование одного dp решит мою проблему?... большое спасибо - person Archie.bpgc; 03.07.2012
comment
Да, использование dp не зависит от плотности и сделает ваш макет согласованным на устройствах с разной плотностью. Вот почему использование px - плохая практика... потому что разные устройства (с разной плотностью) представляют пиксели по-разному. 100 px на устройстве с высоким разрешением может составлять полдюйма, тогда как тот же 100 px на устройстве с низким разрешением может составлять 2 дюйма. Ну, возможно, измерения немного нереальны, но вы поняли :). Рад, что это помогло. - person Alex Lockwood; 03.07.2012
comment
кстати, я полагаю, вы прочитали это: developer.android.com/guide/practices/screens_support .html - person Alex Lockwood; 03.07.2012
comment
на самом деле я попросил графического дизайнера разработать экраны для моего приложения. Он спросил меня, нацелены ли мы на разрешение 320x480? Поэтому я начал искать об этом. Итак, что я должен ответить?... я думаю, что после этого обсуждения это на самом деле не имеет значения для него, все зависит от того, как я кодирую это в приложении, следуя его экранам?? правильно? - person Archie.bpgc; 04.07.2012
comment
Я не знаю, зачем ему нужно знать точное количество пикселей... насколько я понимаю, все, что ему действительно нужно сделать, это разработать макет, который хорошо работает на прямоугольном экране, верно? Ваша задача — убедиться, что он работает на нескольких устройствах Android... графический дизайнер должен нести ответственность только за макет. Вы также должны убедиться, что он знаком с навигацией/рекомендациями Android, как описано в разделе дизайна на сайте разработчиков. Кроме того... возможно, он просто просил соотношение сторон, а не точное количество пикселей. - person Alex Lockwood; 04.07.2012
comment
но когда я использую изображения в своем приложении, мне нужно создавать изображения для всех ldpi, mdpi, hdpi, xhdpi и хранить их в соответствующих папках ресурсов??... и когда я использую @drawable/myImage, в моем коде он автоматически получает изображение в зависимости от плотности пикселей устройства? - person Archie.bpgc; 24.07.2012
comment
@ Archie.bpgc Да, это правильно. mdpi и hdpi являются наиболее важными и охватывают большинство устройств, но рекомендуется охватывать все устройства. На этом веб-сайте очень легко работать со значками.< /б>. - person Alex Lockwood; 24.07.2012

ИМХО, вы всегда должны кодировать свое приложение так, чтобы поддерживалось каждое устройство. Из значка запуска, подробно описанного здесь (разное разрешение для разных размеров экрана): http://developer.android.com/guide/practices/ui_guidelines/icon_design_launcher.html к макету вашего приложения, которое должно быть разработано таким образом, чтобы все размещалось относительно размера экрана (с использованием таких атрибутов, как match_parent и wrap_content ).

Вы можете попробовать закодировать его таким образом, чтобы представления создавались динамически после определения размера экрана, но я думаю, что проще и эффективнее реализовать свою первую идею!

person javajavajava    schedule 03.07.2012
comment
так вы развиваете мой 2-й пункт, верно? если я правильно понял ваш ответ - person Archie.bpgc; 03.07.2012
comment
Да, если я не использую какие-либо жестко закодированные значения ширины, высоты, полей и т. д., мне никогда не нужно беспокоиться о разрешениях экрана. - person javajavajava; 03.07.2012

Лучший вариант — получить ширину и высоту экрана динамически, используя простые параметры получения высоты и ширины.

DisplayMetrics displaymetrics = new DisplayMetrics();
        getWindowManager().getDefaultDisplay().getMetrics(displaymetrics);
        int height = displaymetrics.heightPixels;
        int wwidth = displaymetrics.widthPixels;

другой вариант — создать его для устройства с наибольшей шириной и высотой экрана, а затем математически обработать его для соответствующего размера экрана.

person Rohit Sangal    schedule 03.07.2012

Ну, рекомендуется дизайн для всех размеров. Но я знаю, что это много накладных расходов.

Итак, что вы можете сделать, так это спроектировать для самого большого устройства, к которому вы стремитесь, и заставить устройства настраивать изображения в зависимости от их размеров. Не используйте жестко закодированные значения. Используйте wrap_content или fill_parent.

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

person slybloty    schedule 03.07.2012