Android Scaling和密度問題

更新：一些研究發現，華碩Transformer TF700T（高端）應該有224的像素密度，所以159 android的報告值是錯誤的或已經以某種方式修改（/system/build.prop中的lcd密度鍵），由於某種原因我找不到它。Android Scaling和密度問題

我有兩個幾乎相同的片我開發上，無論是華碩Transformer的，無一不10.1"

高端機型具有以下規格（其中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

較高端模型具有discrepency的密度/ DensityDpi爲1.5 /高，這是有意義的b/C的10.1「屏幕內的高分辨率。但要獲得的1.5的值，也不會Xdpi/Ydpi = 240，使得（對於方程，見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，是正確的？

DPI和比例因子之間的差異導致兩個平板電腦之間的尺寸不匹配，我使用的函數（Context.Resources.GetDimension）在兩個平板電腦之間的比例上升太多（或低端的太小，這取決於我基於哪個「正常/良好」尺寸）。

也就是說，如果密度爲1，或者xdpi/Ydpi爲240，則在第一臺平板電腦上不會出現此問題。這些值似乎沒有連接，因爲它們應該是。這可能是因爲華碩可能已將LCD-Density設置爲159，以獲得更高的分辨率（在/system/build.prop中 - 我查找ro.sf.lcd_density鍵（使用ROM Toolbox）以確認但無法找到它）。

下面是一些供參考的打印輸出，從自定義視圖的構造函數：

高端平板電腦：

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"/>

和夢詩引用它被定義爲

<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>

來源

2013-05-21 samosaris

你正在計算錯誤。對於高端，1920/160 = 12，即12英寸。除以1.5（密度乘數）產生8英寸的寬度。對於低端，1280/160 = 8英寸，除以1 = 8英寸。同樣的高度，使用畢達哥拉斯定理，你會得到一個10英寸的對角線。對於你的具體問題，我不明白你爲什麼會遇到問題，但我總是依靠'WindowManager'。我從來沒有使用過'Resources.GetDimension' – Simon

@Simon它們都是10.1「（加到OP中）另外，我沒有做任何計算，只是讀了ApplicationContext.Resources.DisplayMetrics數據結構。我可能不應該使用Resources.GetDimension;我將直接從視圖的構造函數中引用維，而不是將它們作爲佈局文件中的xml屬性進行分配（然後必須讀取屬性，這是出現問題的位置），因爲那是我在應用程序的其他部分如何做的，沒有尺寸不匹配問題（我在一夜之間就已經明白了）。感謝評論，它確實幫了我很大忙。 – samosaris

注：我不接受我自己的回答讓希望有人知道是怎麼回事，這將拍攝。我發佈這個答案B/C它確實解決了我的問題，但仍然沒有解決一些潛在的問題和謎團。

好，做一些我自己的計算之後，它看起來好像在高端設備具有更精確的Xdpi/Ydpi值，而下端設備報告比計算值更高。兩者都有的

length = 7.12" 
width = 10.35"

物理尺寸所以，我們對高端平板

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

和低端一個

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

華碩文檔指出

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

我明白了， droid「」存儲桶「設備根據密度分爲4組：低，中，高，非常高，並且根據以下這些值將（摘要）dpi值（在/system/build.prop中）賦予預設值： 120,160,240和320。

儘管這些值，Android的每個並正確地報告密度（縮放因子），這是

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

因此，通過機器人（http://developer.android.com/guide/practices/screens_support.html），用於支持多個屏幕的建議，我做了兩個值的文件夾dimens.xml（其中該尺寸的被定義）的兩個版本：

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

和相應調整的值，其中值-HDPI/dimens.xml具有較小的值，以補償1.5的縮放因子，和值-MDPI /dimens.xml有「標準alized「的值縮小1.兩種平板電腦現在都能正確顯示正確的尺寸。 但是，這不是dp/dip指標的用途，所以這些單獨的值集不需要明確定義？

來源

2013-05-22 19:12:24 samosaris

試試您可以在PlayMarket上找到的ScreenInfo應用程序（帶有黃色圖標）。看起來你像我做的一樣。我的意思是你認爲AOS使用DisplayMetrics選擇資源，但那不是事實。還有一個配置。所以舉例來說，我認爲我的HTC是AOS的HDPI，因爲它的DisplayMetrics確實是hdpi/240。但通過配置其正常。請看看http://stackoverflow.com/questions/15837469/display-density-and-resources-usage-ldpi-mdpi-hdpi-xhdpi也許你會發現它很有用。所以也許你的平板電腦必須使用res/large-mdpi和其他res/large-hdpi。 – Stan

@Stan yep，聽起來像你有完全相同的問題，感謝您的鏈接......「所以，也許你的平板電腦之一必須使用res/large-mdpi和其他res/large-hdpi」，是的，上述解決方案恰恰說明了我是如何解決這個問題的。在您的鏈接文章中，可以使用ApplicationContext.Resources.DisplayMetrics.Density或ApplicationContext.Resources.DisplayMetrics.DensityDpi（將它們打印出來以查看... Density = 1＆DensityDpi = 1）來聲明「android威脅我的設備僅作爲MDPI」 Mdpi設備的「正常」）。謝謝。 – samosaris

然後我會發布它作爲答案 – Stan

看起來像你做了像我這樣做。我的意思是你認爲AOS使用DisplayMetrics選擇資源，但那不是事實。還有一個配置。所以舉例來說，我認爲我的HTC是AOS的HDPI，因爲它的DisplayMetrics確實是hdpi/240。但通過配置其正常。 pls look at stackoverflow.com/questions/15837469/…也許你會覺得它有用。
所以，也許你的一個平板電腦必須使用res/large-mdpi和其他res/large-hdpi。

來源

2013-05-24 09:39:33 Stan

Android Scaling和密度問題

回答

相關問題