Android 缩放 &密度问题 [英] Android Scaling & Density Issues

查看:14
本文介绍了Android 缩放 &密度问题的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

更新: 一些研究表明,华硕 Transformer TF700T(高端)应该具有大约 224 的像素密度,因此 159 android 报告的值要么是错误的,要么是以某种方式修改(/system/build.prop 中的 lcd-密度键),由于某种原因我找不到.

Update: Some research has turned up that the Asus Transformer TF700T (high end) should have a pixel density of about 224, so the values of 159 android is reporting are either erroneous, or have been modified somehow (the lcd-density key in /system/build.prop), which I can't find for some reason.

我正在开发两款几乎相同的平板电脑,两款都是 ASUS Transformer,两款都是 10.1".

I have two near identical tablets I'm developing on, both ASUS Transformer's, and both 10.1".

高端模型具有以下规格(其中 dm = ApplicationContext.Resources.DisplayMetrics):

The higher end model has the following specs (where dm = ApplicationContext.Resources.DisplayMetrics):

dm.Density = 1.5
dm.DensityDpi = High
dm.WidthPixels = 1920
dm.HeightPixels = 1128
dm.Xdpi = 159.8951
dm.Ydpi = 159.5811

低端型号有:

dm.Density = 1
dm.DensityDpi = Default
dm.WidthPixels = 1280
dm.HeightPixels = 752
dm.Xdpi = 160.1576
dm.Ydpi = 160

高端型号有差异.Density/DensityDpi 是 1.5/High,这在 10.1" 屏幕内的高分辨率是有意义的 b/c.但是要获得 1.5 的值,Xdpi/Ydpi = 240 不会,这样(有关等式,请参阅 http://developer.android.com/guide/practices/screens_support.html)

The higher end model has a discrepency. The Density/DensityDpi is 1.5/High, which makes sense b/c of the high resolution within a 10.1" screen. But to get a value of 1.5, wouldn't Xdpi/Ydpi = 240, such that (for equation, see http://developer.android.com/guide/practices/screens_support.html)

px = dp * (dpi / 160) 

哪里

scale = (dpi / 160)

所以

240/160 = 1.5 

160 的 Xdpi/Ydpi 不对应于 1.5 密度(缩放)因子,即 160/160 = 1,对吗?

Xdpi/Ydpi of 160 doesn't correspond to a 1.5 Density (scaling) factor, which would be 160/160 = 1, correct ?

DPI 和缩放因子之间的这种差异导致我在两个平板电脑之间存在一些尺寸不匹配,b/c 我使用的函数 (Context.Resources.GetDimension) 在高端平板电脑上将值放大太多(或在低端太小,这取决于我基于正常/良好"尺寸的基础)).

This discrepancy between the DPI's and scaling factor is causing me some size mismatches between the two tablets, b/c the functions I'm using (Context.Resources.GetDimension) is scaling the values up too much on the higher end tablet (or too small on the lower end, depending on which I base the "normal/good" sizes on).

也就是说,如果第一块平板电脑上的密度为 1,或者 xdpi/Ydpi 为 240,我就不会有这个问题.这些值似乎没有联系,因为它们应该是.这可能是因为华硕可能已将 LCD-Density 设置设置为 159,以获得更高的分辨率(在/system/build.prop - 我寻找 ro.sf.lcd_density 键(使用 ROM 工具箱)以确认但无法找到它).

That is, I wouldn't have this problem if the Density was 1, or the xdpi/Ydpi was 240, on the first tablet. These values don't appear to be connected, as they should be. This may be because ASUS may have set the LCD-Density setting to 159, to obtain higher resolution (in /system/build.prop - I looked for the ro.sf.lcd_density key (with ROM Toolbox) to confirm but couldn't find it).

这里有一些打印输出供参考,来自自定义视图的构造函数:

Here are some print outs for reference, from the custom view's constructor:

高端平板电脑:

Context.Resources.GetDimension(control_panel_height_id) = 75
Context.Resources.GetDimension(grid_cell_boarder_width_id) = 1.5
Context.Resources.GetDimension(list_title_height_id) = 40.5
Context.Resources.GetDimension(list_title_text_size_id) = 21
Context.Resources.GetDimension(list_item_text_size_1_id) = 18
Context.Resources.GetDimension(list_item_text_size_2_id) = 15
Context.Resources.GetDimension(month_label_text_size_id) = 33

低端平板电脑:

Context.Resources.GetDimension(control_panel_height_id) = 50
Context.Resources.GetDimension(grid_cell_boarder_width_id) = 1
Context.Resources.GetDimension(list_title_height_id) = 27
Context.Resources.GetDimension(list_title_text_size_id) = 14
Context.Resources.GetDimension(list_item_text_size_1_id) = 12
Context.Resources.GetDimension(list_item_text_size_2_id) = 10
Context.Resources.GetDimension(month_label_text_size_id) = 22

视图的布局声明在哪里

<AppName.Droid.Views.Custom.CustomView
  xmlns:calendar="http://schemas.android.com/apk/res/namespace"
  android:id="@+id/CustomView1"
  android:layout_width="match_parent"
  android:layout_height="match_parent"
  android:background="#1100FF00"
  calendar:control_panel_height="@dimen/control_panel_height"
  calendar:grid_cell_boarder_width="@dimen/grid_cell_boarder_width"
  calendar:list_title_height="@dimen/list_title_height"
  calendar:list_title_text_size="@dimen/list_title_text_size"
  calendar:list_item_text_size_1="@dimen/list_item_text_size_1"
  calendar:list_item_text_size_2="@dimen/list_item_text_size_2"
  calendar:month_label_text_size="@dimen/month_label_text_size"/>

并且它引用的维度被定义为

and the dimens it references are defined as

<resources>
  <dimen name="control_panel_height">50dip</dimen>
  <dimen name="grid_cell_boarder_width">1dip</dimen>
  <dimen name="list_title_height">27dip</dimen>
  <dimen name="list_title_text_size">14dip</dimen>
  <dimen name="list_item_text_size_1">12dip</dimen>
  <dimen name="list_item_text_size_2">10dip</dimen>
  <dimen name="month_label_text_size">22dip</dimen>
</resources>

推荐答案

注意:我不接受我自己的回答,希望知道这是怎么回事的人可以试一试.我在 b/c 上发布了这个答案,它确实解决了我的问题,但仍然没有解决一些潜在的问题和谜团.

Note: I'm not accepting my own answered so that hopefully someone that knows what is going on with this will take a shot. I'm posting this answer b/c it did solve my problem, but still doesn't address some underlying questions and mysteries.

好吧,经过我自己的一些计算,看起来高端设备的 Xdpi/Ydpi 值更准确,而低端设备报告的值高于计算值.两者的物理尺寸均为

Well, after doing some calculations of my own, it looks as though the high-end device has more accurate Xdpi/Ydpi values, and the lower end device is reporting higher than calculated values. Both have physical dimensions of

length = 7.12"
width = 10.35"

所以,我们有高端平板电脑

so, we have for the high-end tablet

Xdpi = 1920 / 10.35 = 185.5
Ydpi = 1128 / 7.12 = 158.4

对于低端

Xdpi = 1280 / 10.35 = 123.7
Ydpi = 752 / 7.12 = 105.6

Asus 文档指出

dpi (high-end) = 224
dpi (low-end) = 149

我确实意识到androidbuckets"设备根据密度分为4组:低、中、高、非常高,并分配(抽象)dpi值(在/system/build.prop 中),预设值分别基于这些:120、160、240 和 320.

I do realize that android "buckets" devices into 4 groups based on density: low, medium, high, very-high, and assigns the (abstract) dpi value (in /system/build.prop) with preset values based on these: 120, 160, 240, and 320 respectively.

尽管有这些值,android 确实正确报告了每个的密度(缩放因子),这是

Despite these values, android did correctly report the Density (scaling factor) for each, which was

Density (high-end) = 1.5
Density (low-end) = 1

所以,正如 android 所建议的那样(http://developer.android.com/guide/practices/screens_support.html) 以支持多个屏幕,我为两个版本的 dimens.xml(定义了大小)创建了两个 Values 文件夹:

So, as suggested by android (http://developer.android.com/guide/practices/screens_support.html) for supporting multiple screens, I made two Values folders for two versions of dimens.xml (where the size's were defined):

Resources/Values-Hdpi/dimens.xml
Resources/Values-Mdpi/dimens.xml

并相应地调整值,其中 Values-Hdpi/dimens.xml 具有较小的值以补偿 1.5 缩放因子,而 Values-Mdpi/dimens.xml 具有标准化"的值,该值缩放为 1.现在这两款平板电脑正确显示正确的尺寸.但是,这不是 dp/dip 指标的用途吗,因此不需要明确定义这些单独的值集?

and adjusted the values accordingly, where Values-Hdpi/dimens.xml had smaller values to compensate for the 1.5 scaling factor, and Values-Mdpi/dimens.xml had "normalized" values that get scaled by 1. Both tablets now correctly display the correct sizes. But, isn't that what the dp/dip metric is for, so that these separate value sets do not need to be explicitly defined ?

这篇关于Android 缩放 &amp;密度问题的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆