一组六个广义密度:

ldpi (low) ~120dpi
mdpi (medium) ~160dpi
hdpi (high) ~240dpi
xhdpi (extra-high) ~320dpi
xxhdpi (extra-extra-high) ~480dpi
xxxhdpi (extra-extra-extra-high) ~640dpi

来自每个手机显示的 wiki 页面

缩小到存储桶中，即如果 ppi 为 300 会进入 hdpi 存储桶，因为它小于 320？

Galaxy S3 306ppi -> bucket hdpi
Nexus 4  318ppi -> bucket hdpi
Nexus 5  445ppi -> bucket xhdpi
Nexus 5X 432ppi -> bucket xhdpi
Nexus 6  493ppi -> bucket xxhdpi 
Nexus 6P 518ppi -> bucket xxhdpi

这是计算屏幕尺寸的正确方法吗？

我之所以问是因为我创建了以下值目录资源:

values-hdpi/dimens
values-xhdpi/dimens
values-xxhdpi/dimens
values-xxxhdpi/dimens

在 dimens.xml 我有不同的边距，并根据桶大小设置 dp，即

<dimen name="network_quantity_margin_top">100dp</dimen>

我很想知道这是否是正确的方法。

最佳答案

The reason I asked is because I have created the following value directory resources. (...) In the dimens.xml I have different margins and set the dp depending on the bucket size. (...) I am interested to know if this is the correct way to do this.

我不确定为什么要根据密度在 dp 中指定不同的边距。将边距指定为 dp 一次，对于基线密度，已经为您处理了所有其他密度，这意味着边距的物理尺寸在任何设备上显示时都是相同的。

如果您使用 px 而不是 dp(但不使用)，那么您必须自己为不同的屏幕进行缩放。

Scaling down into the buckets i.e if the ppi is 300 that would go into the hdpi bucket as it less then 320?

是的，但不是因为它小于 320。如果有经验法则，我会说它是四舍五入到最接近的广义密度。请参阅此图，了解 Android 如何将实际密度大致映射到广义密度(数字不准确):

the documentation 的相关部分这是:

Each generalized size and density spans a range of actual screen sizes and densities. For example, two devices that both report a screen size of normal might have actual screen sizes and aspect ratios that are slightly different when measured by hand. Similarly, two devices that report a screen density of hdpi might have real pixel densities that are slightly different. Android makes these differences abstract to applications, so you can provide UI designed for the generalized sizes and densities and let the system handle any final adjustments as necessary.

同样，如果您只是在编写应用程序，那么您不应该真正关心Android 是如何做到这一点的。你应该关心的是:

• 指定所有layout dimension dp 或 wrap_content/match_parent 中的值，视情况而定(文本可以在 sp 中以额外匹配用户偏好，但仅是文本)，
• 根据 physical size 考虑不同的布局和 orientation屏幕，
• 为不同的densities提供位图资源，只是为了避免模糊或像素化伪影(因为如果您使用 dp 或 wrap_content，Android 会缩放它们以具有正确的物理尺寸)。

Android 将 lookup the best matching resource , 和 then transparently handle根据使用中屏幕的实际密度，根据需要对 dp 单位进行任何缩放。 dp 单位到屏幕像素的转换很简单:px = dp * (dpi/160).

注意 actual 密度与 generalized 密度相对。后者只是方便开发人员，因为不可能为每个屏幕提供可绘制对象。这样，开发人员只需要提供 3 或 4 组图形，而 Android 会选择最合适的并根据特定设备的需要进一步调整它。 (现在可以使用一个可绘制的矢量而不是许多预先缩放的光栅图形，这意味着更好的质量和更小的尺寸。)

Is this the correct way to work out buckets for screen sizes.

不，不是。根据Google device metrics您列出的所有设备都落入比您预期高的存储桶中:

Galaxy S3    NA        NA
Nexus 4     318     xhdpi
Nexus 5X    424    xxhdpi
Nexus 5     445    xxhdpi
Nexus 6     493   xxxhdpi
Nexus 6P    515   xxxhdpi

我从该列表中提取了一些其他设备，并绘制了不同设备如何根据其实际物理密度落入密度桶的情况。

Chromebox 30            101      mdpi
Chromebook 11           135      mdpi
Samsung Galaxy Tab 10   149      mdpi
Nexus 7 '12             216     tvdpi
Android One             218      hdpi
Chromebook Pixel        239     xhdpi
Nexus 9                 288     xhdpi
Nexus 10                299     xhdpi
Moto X                  312     xhdpi
Nexus 4                 318     xhdpi
Nexus 7 '13             323     xhdpi 
Moto G                  326     xhdpi
Dell Venue 8            359     xhdpi
LG G2                   424    xxhdpi
Nexus 5X                424    xxhdpi
HTC One M8              441    xxhdpi
Nexus 5                 445    xxhdpi
Nexus 6                 493   xxxhdpi
Nexus 6P                515   xxxhdpi
LG G3                   534    xxhdpi

您可以看到，除了一些值得注意的异常(exception)，选择最接近的广义密度的规则仍然成立。

Nexus 6 和 6P 除外，它们被列为 xxxhdpi，尽管 LG G3 具有更高的物理密度并且距离 640px/in 还很远。 Android One 是 hdpi，但它只比 Nexus 7 '12 的 tvdpi 稍微密集一些。 Chromebox 30 和 Chromebook Pixel(不可否认，不是 Android)被分配到存储桶 mdpi 和 xhdpi 即使它们在物理上低于 ldpi 和 hdpi，分别。

关于android - 将屏幕密度放入正确的桶中，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/33739945/