android不一樣屏幕分辨率的適配

有必要了解的 Android中常見的單位 dip, dp, px, sp之間的區別：

dip: device independent pixels(設備獨立像素). 不一樣設備有不一樣的顯示效果,這個和設備硬件有關，通常咱們爲了支持WVGA、HVGA和QVGA 推薦使用這個，不依賴像素。
px: pixels(像素). 不一樣設備顯示效果相同，通常咱們HVGA表明320x480像素，這個用的比較多。
pt: point，是一個標準的長度單位，1pt＝1/72英寸，用於印刷業，很是簡單易用；
sp: scaled pixels(放大像素). 主要用於字體顯示best for textsize，根據 google 的建議，TextView 的字號最好使用 sp 作單位，

Android支持下列全部單位：
px（像素）：屏幕上的點。
in（英寸）：長度單位。
mm（毫米）：長度單位。
pt（磅）：1/72英寸。
dp（與密度無關的像素）：一種基於屏幕密度的抽象單位。在每英寸160點的顯示器上，1dp = 1px。
dip：與dp相同，多用於Android/ophone示例中。
sp（與刻度無關的像素）：與dp相似，可是能夠根據用戶的字體大小首選項進行縮放。

=================================================================================

這些術語都是指屏幕的分辨率。
VGA：Video Graphics Array，即：顯示繪圖矩陣，至關於640×480 像素；
HVGA：Half-size VGA；即：VGA的一半，分辨率爲480×320；
QVGA：Quarter VGA；即：VGA的四分之一，分辨率爲320×240；
WVGA：Wide Video Graphics Array；即：擴大的VGA，分辨率爲800×480像素；

WQVGA：Wide Quarter VGA；即：擴大的QVGA，分辨率比QVGA高，比VGA低，通常是：400×240，480×272；

在設計之初，Android系統就被設計爲一個能夠在多種不一樣分辨率的設備上運行的操做系統。對於應用程序來講，系統平臺向它們提供的是一個穩定的，跨平 臺的運行環境，而關於如何將程序以正確的方式顯示到它所運行的平臺上所須要的大部分技術細節，都由系統自己進行了處理，無需程序的干預。固然，系統自己也 爲程序提供了一系列API，因此在目標平臺的分辨率是能夠徹底肯定的狀況下，程序也能夠精確的控制自身在目標平臺上的界面顯示方式。

　　這個文檔會說明系統平臺究竟提供了哪些分辨率支持特性，與它們如何在程序中使用的信息。若是你遵循文檔中列出的方法，就很容易讓你的程序在全部支持的分辨率下都能完美顯示。這樣你就能夠用一個單獨的.apk文件，將你的程序發佈到全部的平臺上。

　　若是你已經發布過針對Android 1.5或更早版本平臺的程序，你應該仔細閱讀這篇文檔，而後考慮一下到底如何讓本身的老程序能夠在擁有各類不一樣分辨率，而且運行着Android 1.6或更新平臺上正常顯示。在絕大部分狀況下，只須要對程序做出小小的修改就能夠達到目的，但你仍然須要儘量地在各類分辨率的平臺上進行測試。
　　特別的，若是你有一個已經完成的程序，又想讓它能夠在超低分辨率的設備（好比320×240）上正確運行，你須要閱讀「老程序的更新策略」，那篇文檔會告訴你應該怎麼作。

術語和概念
屏幕尺寸
屏幕的物理尺寸，以屏幕的對角線長度做爲依據（好比2.8寸，3.5寸）。
簡而言之，Android把全部的屏幕尺寸簡化爲三大類：大，正常，和小。
程序能夠針對這三種尺寸的屏幕提供三種不一樣的佈局方案，而後系統會負責把你的佈局方案以合適的方式渲染到對應的屏幕上，這個過程是不須要程序員用代碼來干預的。

屏幕長寬比
屏幕的物理長度與物理寬度的比例。程序能夠爲制定長寬比的屏幕提供製定的素材，只須要用系統提供的資源分類符long和notlong。

分辨率
屏幕上擁有的像素的總數。注意，雖然大部分狀況下分辨率都被表示爲「寬度×長度」，但分辨率並不意味着屏幕長寬比。在Android系統中，程序通常並不直接處理分辨率。

密度
以屏幕分辨率爲基礎，沿屏幕長寬方向排列的像素。
密 度較低的屏幕，在長和寬方向都只有比較少的像素，而高密度的屏幕一般則會有不少——甚至會很是很是多——像素排列在同一區域。屏幕的密度是很是重要的，舉 個例子，長寬以像素爲單位定義的界面元素（好比一個按鈕），在低密度的屏幕上會顯得很大，但在高密度的屏幕上則會顯得很小。

密度無關的像素（DIP）
指一個抽象意義上的像素，程序用它來定義界面元素。它做爲一個與實際密度無關的單位，幫助程序員構建一個佈局方案（界面元素的寬度，高度，位置）。
一 個與密度無關的像素，在邏輯尺寸上，與一個位於像素密度爲160DPI的屏幕上的像素是一致的，這也是Android平臺所假定的默認顯示設備。在運行的 時候，平臺會以目標屏幕的密度做爲基準，「透明地」處理全部須要的DIP縮放操做。要把密度無關像素轉換爲屏幕像素，能夠用這樣一個簡單的公 式：pixels = dips * (density / 160)。舉個例子，在DPI爲240的屏幕上，1個DIP等於1.5個物理像素。咱們強烈推薦你用DIP來定義你程序的界面佈局，由於這樣能夠保證你的 UI在各類分辨率的屏幕上均可以正常顯示。


支持的屏幕分辨率範圍
1.5及更早版本的Android系統，在設計的時候假定系統只會運行在一種分辨率的設備上——HVGA（320×480）分辨率，尺寸爲3.2寸。因爲系統只能工做在一種屏幕上，開發人員就能夠針對那個屏幕來編寫本身的程序，而無需去考慮程序在其餘屏幕上的顯示問題。
但自從Android 1.6以來，系統引入了對多種尺寸、多種分辨率屏幕的支持，以此知足擁有各類配置的新平臺的運行需求。這就意味着開發人員在針對Android 1.6或更新版系統開發程序的時候，須要爲本身的程序在多種分辨率的屏幕上良好顯示做出額外的設計。
爲了簡化程序員面在對各類分辨率時的困擾，也爲了具有各類分辨率的平臺均可以直接運行這些程序，Android平臺將全部的屏幕以密度和分辨率爲分類方式，各自分紅了三類：
·三種主要的尺寸：大，正常，小；
·三種不一樣的密度：高（hdpi），中（mdpi）和低（ldpi）。
如 果須要的話，程序能夠爲各類尺寸的屏幕提供不一樣的資源（主要是佈局），也能夠爲各類密度的屏幕提供不一樣的資源（主要是位圖）。除此之外，程序不須要針對屏 幕的尺寸或者密度做出任何額外的處理。在執行的時候，平臺會根據屏幕自己的尺寸與密度特性，自動載入對應的資源，並把它們從邏輯像素（DIP，用於定義界 面佈局）轉換成屏幕上的物理像素。
下表列出了Android平臺支持的屏幕中一些比較經常使用的型號，並顯示了系統是如何把它們分類到不一樣的屏幕配置裏的。有些屏幕分辨率並不在下面的列表上，但系統仍會把它們納入下列的某一個類型中。

	低密度（120），ldpi	中密度（160），mdpi	高密度（240），hdpi
小屏幕	·QVGA（240×320），2.6～3.0寸
普通屏幕	·WQVGA（240×400），3.2～3.5寸 ·FWQVGA（240×432），3.5～3.8寸	·HVGA（320×480），3.0～3.5寸	·WVGA（480×800），3.3～4.0寸 ·FWVGA（480×854），3.5～4.0寸
大屏幕		·WVGA（480×800），4.8～5.5寸 ·FWVGA（480×854），5.0～5.8寸

 

 

首先，一塊屏幕有幾個參數，屏幕的物理尺寸，分辨率，像素密度(Density, DPI)。

其中

• 物理尺寸，就是所說的幾寸的屏幕，表明屏幕對角線的長度，好比3.5寸、3.7寸、4寸、7寸等。

• 分辨率，是屏幕總共能顯示的像素數，一般咱們都說幾百×幾百，好比240*320，320*480，480*800等，咱們通常直接說乘後的結果。

• 像素密度(DPI)，DPI的全稱是dots per inch，每英寸點數，還有個詞是PPI，是每英寸像素數，其實PPI感受更準確一些，這兩個比較糾結，不少時候混用，這裏就不明確區分了。（本文的意思都是「每英寸像素數」）

這三個參數，任兩個肯定後，第三個量就是肯定了。公式爲：分辨率（總像素數）= 物理尺寸 × 像素密度。

• 好比一個3寸的屏幕，分辨率爲240×320，那麼密度爲 開方(480x800/3.5) 約等於爲160。

• 再好比一個3.5寸的屏幕，分辨率爲480×800，那麼密度爲 開方(480x800/3.5) 約等於爲331。

• 在好比一個3.5寸的屏幕，分辨率爲960x640，那麼密度爲 開方(960x640/3.5) 約等於418。

• 再好比一個4寸的屏幕，分辨率爲480x800,那麼密度爲 開方(480x800/4) 約等於309。

面對種類旁雜的屏幕，開發人員該怎麼辦，人工針對不一樣屏幕作相應調整，No！

讓機器調整！開發人員是天生懶惰的！

那麼要調整什麼，目的該是讓界面元素的物理大小在全部設備上保持一致（可是屏大的彷佛自然能夠顯示的大一點，小屏的能夠小一點。）

過去，開發人員一般以像素爲單位設計計算機用戶界面。例如，定義一個寬度爲300像素的表單字段，列之間的間距爲5個像素，圖標大小爲16×16像素等。 這樣處理的問題在於，若是在一個每英寸點數（dpi）更高的新顯示器上運行該程序，則用戶界面會顯得很小。在有些狀況下，用戶界面可能會小到難以看清內 容。

針對屏幕的三個參數，分析以下：

• 一樣物理尺寸,分辨率不一樣,那麼若是按照像素設計,就會產生,分辨率大的那個,圖像很小.物理尺寸就會很小.

• 一樣分辨率,不一樣物理尺寸,若是按鈕找像素設計,實際看起來的物理比例是同樣的.

• 看起來物理尺寸同樣,不一樣分辨率,分辨率大的,屏幕尺寸就要大.

• 看起來物理尺寸同樣,不一樣屏幕尺寸,大尺寸的,就要像素多.

那麼Android框架爲自動調整尺寸作了什麼呢？

就是密度無關像素，原文以下

The density-independent pixel is equivalent to one physical pixel on a 160 dpi screen.

是說，以160dpi爲標準，在一個160dpi的屏幕上的1個物理像素做爲設備無關像素的1個像素，也就是Android最佳實踐中推薦的dip/dp（如下這兩個單位表示一樣含義，dip常見於Google官方示例中）這個單位。

針對於字體，Android設計了sp這個單位，這個於dp的不一樣在於，字體大小在dp的基礎上，能夠根據用戶的偏好設置，相應調整字體大小，因此是scale的。

可是！

Android的作法不是根據160dpi這個標準值和設備實際的dpi的比值進行縮放！而是設定了一套標準化尺寸和密度：

• 標準化物理尺寸: small, normal, large, and xlarge

• 標準化屏幕密度: ldpi (low), mdpi (medium), hdpi (high), and xhdpi (extra high)

Each generalized size or density spans a range of actual screen sizes or density. 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. Figure 1 illustrates how different sizes and densities are roughly categorized into the different size and density groups.（摘自官方文檔）

（我曾經覺得，Android會根據實際dpi進行縮放，這也是我迷惑好久，以前寫就在這個卡住了）

爲了證實Android確實不是否是根據實際dpi進行縮放，我查閱了相關的源代碼。

咱們知道當顯卡繪製一個圖像的時候，是根據物理像素繪製的。因此，當開發人員設定dp這種單位的時候，須要一個轉化過程，將sp轉化爲px。

若是按我以前所想，計算公式該是：實際dpi / mdpi（也就是160dpi）而後乘上sp的數值，這樣就獲得了在不一樣設備上物理大小徹底同樣的的界面元素。

可是Android不是這樣設計的，正如前文所說，是根據那套標準化的密度來進行轉換的。經過以下代碼(這個是Android將dp轉化爲px值的過程)。

public static float applyDimension(int unit, float value, DisplayMetrics metrics) { switch (unit) { case COMPLEX_UNIT_PX: return value; case COMPLEX_UNIT_DIP: return value * metrics.density; case COMPLEX_UNIT_SP: return value * metrics.scaledDensity; case COMPLEX_UNIT_PT: return value * metrics.xdpi * (1.0f/72); case COMPLEX_UNIT_IN: return value * metrics.xdpi; case COMPLEX_UNIT_MM: return value * metrics.xdpi * (1.0f/25.4f); } return 0; }

能夠看到，若是單位是dip(dp)，那麼返回值則是dip的value * metrics.density。

這裏的density是

The logical density of the display. This is a scaling factor for the Density Independent Pixel unit, where one DIP is one pixel on an approximately 160 dpi screen (for example a 240x320, 1.5"x2" screen), providing the baseline of the system's display. Thus on a 160dpi screen this density value will be 1; on a 120 dpi screen it would be .75; etc.
This value does not exactly follow the real screen size (as given by xdpi and ydpi, but rather is used to scale the size of the overall UI in steps based on gross changes in the display dpi. For example, a 240x320 screen will have a density of 1 even if its width is 1.8", 1.3", etc. However, if the screen resolution is increased to 320x480 but the screen size remained 1.5"x2" then the density would be increased (probably to 1.5).
（摘自Google官方文檔，懶得翻譯了，固然也是怕翻譯壞了原來的味道，這段仍是至關重要的）

重點是This value does not exactly follow the real screen size。這也解釋我以前的疑惑。

這個density值Displaymetrics記錄的，若是你想看看實際狀況，能夠獲取Displaymetrics，經過代碼：

DisplayMetrics metrics = new DisplayMetrics(); getWindowManager().getDefaultDisplay().getMetrics(metrics);

而後就能獲得metrics的值。

另外！

這類還有xdpi和ydpi這兩個值，官方文檔上說：The exact physical pixels per inch of the screen in the X(Y) dimension.

然而，當我試圖獲取某些機器的這兩個值的時候卻與我手動計算所獲得的值徹底不一樣！

後來翻閱StackOverflow，看到也有人遇到相似問題，

做者得到了幾個設備的dip值，以下：

• HTC Desire Z: 480x800, density : HIGH, xdpi: 254.0, ydpi: 254.0

• Motorola Defy: 480x854, density : HIGH, xdpi: 96.0, ydpi: 96.0

• Samsung Galaxy S2: 480x800, density : HIGH, xdpi: 217.71428, ydpi: 218.49463

• LG Optimus 2X: 480x800, density : HIGH, xdpi: 160.0, ydpi: 160.0

（原文地址： http://stackoverflow.com/questions/6224900/android-incorrect-size-for-views-with-mm-or-inch-dimensions）

能夠看到對於Moto和LG的dpi是明顯錯誤的。

再回想剛纔Android轉換單位的函數裏面這段代碼：

case COMPLEX_UNIT_PT: return value * metrics.xdpi * (1.0f/72); case COMPLEX_UNIT_IN: return value * metrics.xdpi; case COMPLEX_UNIT_MM: return value * metrics.xdpi * (1.0f/25.4f);

對於這幾個單位的處理都用到了xdpi，因此極可能轉換後是錯誤的值，
（這裏應該仍然算是個疑問，難道真的沒有辦法獲得正確的值嗎？咱們都知道是不推薦用pt,in,mm這種單位的，這是否也是一個方面）

至此關於屏幕的問題大致說完，而後就是提供的資源問題，當咱們設置了一個界面元素的的大小後，對於不是標準dpi的機器上就要進行縮放，那麼對於繪製的矢 量元素，天然是不用管，而對於圖像這種位圖，縮放後會致使模糊等問題，因此就要對標準化dpi的幾個大小，提供相應的替換版本，Android會根據實際 屏幕規格，進行相應替換，而且有相應的查找資源的規則，看Android源碼，能夠知道，Android的框架的默認ui使用了大量nine-patch 圖片。這裏就不詳細說了。

好吧，此次就到這裏了。

=======================================================================================

（一）、尺寸

現有的Android手機主要屏幕尺寸有：2.八、3.一、3.二、3.七、四、4.二、4.三、5.0(單位/英寸)

屏幕爲2.8英寸的機型主要由HTC Tattoo(也就是咱們常說的G4)、摩托羅拉FLIPOUT(行貨名稱爲MB511)等機型，這個尺寸的Android手機一般爲入門級機型，價格一般在1000元上下。

　  屏幕尺寸3.1-3.5英寸的機型主要爲中端機型，表明機型有HTC Hero(G3)，摩托羅拉ME600(後空翻)、三星i7500等，價格在2000元上下。

　  新上市的屏幕尺寸3.7英寸以上機型一般爲Android 高端手機，表明機型有HTC Desire S、HTC Sensation、摩托羅拉Droid X(天翼定製型號爲ME811)、摩托羅拉Atrix 4G(行貨型號爲ME860)、三星Nexus S、三星Galaxy S2等，價格一般在3000元以上。

    屏幕尺寸越大，可視範圍就越大，因爲全部Android手機均爲可觸摸操做屏幕，因此操做區域也更大。在用手機玩遊戲，觀看視頻方面，大尺寸手機優點明顯。

   另外，手機尺寸越大，攜帶起來也越不方面。我使用過的最大的Android手機是Dell Mini 5(7英寸Galaxy Tab不在手機之列)，這部手機屏幕尺寸超過5英寸，幾乎沒法塞進褲子的口袋。

（二）、分辨率

Android手機分辨率主要有240X320、320X480、480X800、480X854幾種。

分辨率一詞在港臺地區稱之爲解析度(我的認爲解析度一詞表達的更爲精確)，也就是屏幕圖像的精密度。分辨率越大的顯示屏越清晰。

    分辨率爲240X320、320X480的機型一般爲Android中低端機型，價格一般在1000-2000元。

    分辨率480X800、480X854的機型一般爲中高端機型，價格從2500-5000不等。

目前大部分軟件開發大多以兼容分辨率480X800和480X854的手機爲標準，全部有一些軟件早一些分辨率的手機會被告知沒法運行。

 

2.      手機尺寸分佈狀況（http://developer.android.com/resources/dashboard/screens.html）

目前主要是以分辨率爲800*480和854*480的手機用戶居多

 

 

Data collected during a 7-day period ending on August 1, 2011

ldpi mdpi hdpi xhdpi

small 3.4%

normal 0.9% 16.9% 74.5%

large 3.1%

xlarge 1.2%

 

 

二、術語解釋

術語 說明 備註

Screen size（屏幕尺寸) 指的是手機實際的物理尺寸，好比經常使用的2.8英寸，3.2英寸，3.5英寸，3.7英寸摩托羅拉milestone手機是3.7英寸

Aspect Ratio(寬高比率) 指的是實際的物理尺寸寬高比率,分爲long和nolong Milestone是16：9,屬於long

Resolution(分辨率) 和電腦的分辨率概念同樣，指手機屏幕縱、橫方向像素個數 Milestone是854*480

DPI(dot per inch) 每英寸像素數，如120dpi,160dpi等,假設QVGA(320*240)分辨率的屏幕物理尺寸是（2英寸*1.5英寸），dpi=160 能夠反映屏幕的清晰度，用於縮放UI的

Density(密度) 屏幕裏像素值濃度，resolution/Screen size能夠反映出手機密度  

Density-independent pixel (dip) 指的是邏輯密度計算單位,dip和具體像素值的對應公式是dip/pixel=dpi值/160  表示每英寸有多少個顯示點

 

三、手機屏幕分類和像素密度的對應關係

VGA  ：Video Graphics Array，即：顯示繪圖矩陣，至關於640×480 像素；

HVGA ：Half-size VGA；即：VGA的一半，分辨率爲480×320； density=160

QVGA ：Quarter VGA；即：VGA的四分之一，分辨率爲320×240； density=120

WVGA：Wide Video Graphics Array；即：擴大的VGA，分辨率爲800×480像素；density=240

WQVGA：Wide Quarter VGA；即：擴大的QVGA，分辨率比QVGA高，比VGA低，通常是：400×240，480×272；density=120

apk的資源包中，當屏幕density=240時使用hdpi標籤的資源

當屏density=160時使用mdpi標籤的資源

當屏幕density=120時使用ldpi標籤的資源。

不加任何標籤的資源是各類分辨率狀況共用的

屏幕(Type) 寬度(Pixels) 高度(Pixels) 尺寸Range (inches) 大小Size 密度Group

QVGA 240 320 2.6 - 3.0 Small screen Low density (120)  ldpi

WQVGA 240 400 3.2 - 3.5 Normal screen Low density (120)  ldpi

FWQVGA 240 432 3.5 - 3.8 Normal screen Low density (120)  ldpi

HVGA 320 480 3.0 - 3.5 Normal screen Mediumdensity(160)mdpi

WVGA 480 800 3.3 - 4.0 Normal screen High density (240), hdpi

FWVGA 480 854 3.5 - 4.0 Normalscreen High density (240), hdpi

WVGA 480 800 4.8 - 5.5 Large screen Medium density(160) mdpi

FWVGA 480 854 5.0 - 5.8 Large screen Medium density(160) mdpi

 

四、UI設計

開發角度講，應用程序會根據 3 類 A ndroid 手機屏幕提供3 套UI 佈局文件，可是相應界面圖標也須要提供3 套

con Type Standard Asset Sizes (in Pixels), for Generalized Screen Densities

  Lowdensityscreen(ldpi) Mediumdensityscreen(mdpi) Highdensityscreen(hdpi)

Launcher 36 x 36 px 48 x 48 px 72 x 72 px

Menu 36 x 36 px 48 x 48 px 72 x 72 px

StatusBar 24 x 24 px 32 x 32 px 48 x 48 px

Tab 24 x 24 px 32 x 32 px 48 x 48 px

Dialog 24 x 24 px 32 x 32 px 48 x 48 px

List View 24 x 24 px 32 x 32 px 48 x 48 px

========================================================================================

http://wolfgangkiefer.blog.163.com/blog/static/8626550320111120105136253/

 

各類Android操做系統的手機簡直就是琳琅滿目，屏幕分辨率的差別可想而知。目前比較主流的有WVGA=800x480，HVGA=480x320，另外的還有QVGA=320x240。固然還有魅族M9的DVGA=960x640，還有蛋疼的摩托羅拉的FWVGA=854x480。

　　其實，在你layout的xml文件中，編寫的時候是否是用了許多的padding呢？若是是，那你就蛋疼了。由於這樣的佈局永遠是沒法適應全部手機屏幕的。

　　正確的作法應該是使用的是weight屬性。將你控件的layout中的width、height設置爲fill-parent，不要使用wrap——content。由於wrap-content的大小是不固定的。而weight（權重）這個屬性很好的解決了這個問題。

　　當包裹在控件外面的Layout的width、height屬性都設置爲fill-parent時，能夠利用weight的反比特性。即若是控件A設置weight爲5，控件B設置weight爲7，那麼A所佔的空間爲5/（5+7），B所佔的空間爲7/（5+7）。這樣的反比屬性對任何分辨率下的手機都是合適的。

　　固然，字體就不行了。那怎麼保證字體可以跟佈局同樣可以自適應呢？
　　呵呵，很簡單，就是在你的res文件夾中建立一個文件夾，叫作values-320x240。其中320x240是你手機屏幕的分辨率，根據你手機屏幕的狀況作不一樣的命名，例如values-　800x480。在該文件夾下建立一個dimens.xml文件，定義各類字體的大小。那麼系統就會自動根據你手機屏幕的分辨率去調用響應的文件夾。

   　另外，值得提醒的是，記得在你默認的values文件下的dimens.xml文件中也要寫上相應的字體大小哦，由於當系統沒法認識你手機屏幕大小的時候，它會自動去找你默認文件中的

東西，沒有寫的話程序會崩潰。

************************************************************分割線************************************************************

　　在看下面內容以前首先請看你SDK文檔中如下這篇文章

其實google在分辨率適應性的東西已經寫的很清楚了，只是咱們不少人沒去看而已

　　如下是結論：
　　　　屏幕分辨率：1024x600
　　　　density：1（160）
　　　　文件夾：values-mdpi-1024x600

　　　　屏幕分辨率：1024x600
　　　　density：1.5（240）
　　　　文件夾：values-hdpi-683x400  由1024/1.5  600/1.5獲得，須要四捨五入。

　　　　屏幕分辨率：800x480
　　　　density：1（160）
　　　　文件夾：values-mdpi-800x480

　　　　屏幕分辨率：800x480
　　　　density：1.5（240）
　　　　文件夾：values-hdpi-533x320  由800/1.5  480/1.5獲得，須要四捨五入。

　　以此類推
　　　　通常狀況下須要建立出values 、values-mdpi 、 values-hdpi文件夾，以備在一些沒有規定的尺寸屏幕上找不到資源的狀況。

　　　　而後在裏面使用不一樣的dimens文件，Layout中不要使用顯示的數字，全部的尺寸定義全都援引dimens裏面的內容。

　　　　這樣可以保證深度UI定製的狀況

　　　　另外在工程的default.properties中若是split.density=false，則分辨率適配的時候文件夾命名不須要與scale相除

　　例
　　屏幕分辨率：800x480
　　density：1.5（240）
　　文件夾：values-hdpi-800x480

************************************************************分割線************************************************************

　　關於dimens 

　　　　位置：res\values
　　　　單位：px   Pixel 以畫面的像素爲單位；
       　 in     Inches以畫面的多少英寸爲單位；
        　mm  Millimeter以畫面的多少毫米爲單位；
        　pt     Points 一點爲1/72英寸；
        　dp或dip  Density-indepentdent 爲160dpi屏幕的一個pixel;
        　ap Scale-independent Pixels 隨屏幕尺寸改變的一個pixel;

1.drawable: 存放不一樣分辨率對應圖片

      在2.1版本中有drawable-mdpi、drawable-ldpi、drawable-hdpi三個，這三個主要是爲了支持多分辨率。

　　drawable- hdpi、drawable- mdpi、drawable-ldpi的區別：

　　(1)drawable-hdpi裏面存放高分辨率的圖片,如WVGA (480x800),FWVGA (480x854)

　　(2)drawable-mdpi裏面存放中等分辨率的圖片,如HVGA (320x480)

　　(3)drawable-ldpi裏面存放低分辨率的圖片,如QVGA (240x320)

　　系統會根據機器的分辨率來分別到這幾個文件夾裏面去找對應的圖片。

      在2.1以前的版本能夠經過drawable-800x480, drawable-480x320 等方式實現。

2:layout:放置對應不一樣分辨率的佈局

      建立不一樣的layout文件夾， layout-800x480,layout-480x320, 系統會根據屏幕的大小本身選擇合適的layout進行使用。

      另外：能夠在res目錄下創建layout-port和layout-land兩個目錄，裏面分別放置豎屏和橫屏兩種佈局文件。

下面列出主流的android機型有：

240x320低端，國產入門級採用，例如HTC G4，G8
320x480中端，大部分基於此分辨率，例如HTC G1,G2,G3,G6, MOTO ME600, SAMSUNG I7500
480x800中高端，大部分基於此分辨率，例如HTC G5,G7, MOTO MT810
480x854MOTO特有的，例如Droid, Milestone, XT800
960x640, 魅族M9

更爲詳細的見下圖：

 

參考瞭如下資料：
http://topic.csdn.net/u/20101119/09/29efa19b-958e-493b-9200-38d7205a26fa.html

http://hi.baidu.com/wudaovip/blog/item/7453084e811697c4d1c86a15.html

 

 ========================================================================

一、屏幕相關概念
1.1分辨率
是指屏幕上有橫豎各有多少個像素
1.2屏幕尺寸
指的是手機實際的物理尺寸，好比經常使用的2.8英寸，3.2英寸，3.5英寸，3.7英寸
android將屏幕大小分爲四個級別（small，normal，large，and extra large）。
1.3屏幕密度
每英寸像素數
手機能夠有相同的分辨率，但屏幕尺寸能夠不相同，
Diagonal pixel表示對角線的像素值（=），DPI=933/3.7=252
android將實際的屏幕密度分爲四個通用尺寸（low，medium，high，and extra high）
通常狀況下的普通屏幕：ldpi是120dpi，mdpi是160dpi，hdpi是240dpi，xhdpi是320dpi
對於屏幕來講，dpi越大，屏幕的精細度越高，屏幕看起來就越清楚
1.4密度無關的像素（Density-independent pixel——dip）
dip是一種虛擬的像素單位
dip和具體像素值的對應公式是dip/pixel=dpi值/160,也就是px = dp * (dpi / 160)
當你定義應用的佈局的UI時應該使用dp單位，確保UI在不一樣的屏幕上正確顯示。

手機屏幕分類和像素密度的對應關係如表1所示

手機尺寸分佈狀況（http://developer.android.com/resources/dashboard/screens.html）如圖所示，

目前主要是以分辨率爲800*480和854*480的手機用戶居多
從以上的屏幕尺寸分佈狀況上看，其實手機只要考慮3-4.5寸之間密度爲1和1.5的手機

二、android多屏幕支持機制
Android的支持多屏幕機制即用爲當前設備屏幕提供一種合適的方式來共同管理並解析應用資源。
Android平臺中支持一系列你所提供的指定大小（size-specific）,指定密度（density-specific）的合適資源。
指定大小（size-specific）的合適資源是指small, normal, large, and xlarge。
指定密度（density-specific）的合適資源，是指ldpi (low), mdpi (medium), hdpi (high), and xhdpi (extra high).
Android有個自動匹配機制去選擇對應的佈局和圖片資源
1）界面佈局方面
根據物理尺寸的大小準備5套佈局:
layout(放一些通用佈局xml文件，好比界面頂部和底部的佈局，不會隨着屏幕大小變化，相似windos窗口的title bar),
layout-small(屏幕尺寸小於3英寸左右的佈局），
layout-normal(屏幕尺寸小於4.5英寸左右），
layout-large(4英寸-7英寸之間），
layout-xlarge(7-10英寸之間）
2）圖片資源方面
須要根據dpi值準備5套圖片資源:
drawable：主要放置xml配置文件或者對分辨率要求較低的圖片
drawalbe-ldpi:低分辨率的圖片,如QVGA (240x320)
drawable-mdpi:中等分辨率的圖片,如HVGA (320x480)
drawable-hdpi:高分辨率的圖片,如WVGA (480x800),FWVGA (480x854)
drawable-xhdpi：至少960dp x 720dp
Android有個自動匹配機制去選擇對應的佈局和圖片資源。
　　系統會根據機器的分辨率來分別到這幾個文件夾裏面去找對應的圖片。
　　在開發程序時爲了兼容不一樣平臺不一樣屏幕，建議各自文件夾根據需求均存放不一樣版本圖片。

三、AndroidManifest.xml 配置
android從1.6和更高，Google爲了方便開發者對於各類分辨率機型的移植而增長了自動適配的功能
<supports-screens
android:largeScreens="true"
android:normalScreens="true"
android:smallScreens="true"
android:anyDensity="true"/>
3.1是否支持多種不一樣密度的屏幕
android:anyDensity=["true" | "false"]
若是android:anyDensity="true"
指應用程序支持不一樣密度，會根據屏幕的分辨率自動去匹配。
若是android:anyDensity="false"
應用程序支持不一樣密度，系統自動縮放圖片尺寸和這個圖片的座標。具體解釋一下系統是如何自動縮放資源的。
例如咱們在hdpi,mdpi,ldpi文件夾下擁有同一種資源，那麼應用也不會自動地去相應文件夾下尋找資源，這種狀況都是出如今高密度，以及低密度的手機上，好比說一部240×320像素的手機，
若是設置android:anyDensity="false"，Android系統會將240 x 320(低密度)轉換爲 320×480(中密度)，這樣的話，應用就會在小密度手機上加載mdpi文件中的資源。
3.2是否支持大屏幕
android:largeScreens=["true" | "false"]
若是在聲明不支持的大屏幕，而這個屏幕尺寸是larger的話，系統使用尺寸爲("normal")和密度爲("medium)顯示，
不過會出現一層黑色的背景。
3.3是否支持小屏幕
android:smallScreens=["true" | "false"]
若是在聲明不支持的小屏幕，而當前屏幕尺寸是smaller的話，系統也使用尺寸爲("normal")和密度爲("medium)顯示
若是應用程序能在小屏幕上正確縮放(最低是small尺寸或最小寬度320dp)，那就不須要用到本屬性。不然，就應該爲最小屏幕寬度標識符設置本屬性
來匹配應用程序所需的最小尺寸。


四、Android提供3種方式處理屏幕自適應
4.1預縮放的資源(基於尺寸和密度去尋找圖片)
1）若是找到相應的尺寸和密度，則利用這些圖片進行無縮放顯示。
2）若是無法找到相應的尺寸，而找到密度，則認爲該圖片尺寸爲 "medium"，利用縮放顯示這個圖片。
3）若是都沒法匹配，則使用默認圖片進行縮放顯示。默認圖片默認標配 "medium" (160)。
4.2自動縮放的像素尺寸和座標(密度兼容)
1）若是應用程序不支持不一樣密度android:anyDensity="false",系統自動縮放圖片尺寸和這個圖片的座標。
2）對於預縮放的資源，當android:anyDensity="false"，也不生效。
3）android:anyDensity="false"，只對密度兼容起做用，尺寸兼容沒效果
4.3兼容更大的屏幕和尺寸(尺寸兼容)
1）對於你在聲明不支持的大屏幕，而這個屏幕尺寸是normal的話，系統使用尺寸爲 ("normal")和密度爲("medium)顯示。
2.）對於你在聲明不支持的大屏幕，而這個屏幕尺寸是larger的話，系統一樣使用尺寸爲("normal")和密度爲("medium)顯示，
不過會出現一層黑色的背景。

五、Android系統自動適配技巧
Android系統採用下面兩種方法來實現應用的自動適配：
1）佈局文件中定義長度的時候，最好使用wrap_content,fill_parent, 或者dp 進行描述，這樣能夠保證在屏幕上面展現的時候有合適的大小
2）爲不一樣屏幕密度的手機，提供不一樣的位圖資源，可使得界面清晰無縮放。
對應bitmap 資源來講，自動的縮放有時會形成放大縮小後的圖像變得模糊不清，這是就須要應用爲不一樣屏幕密度配置提供不一樣的資源：爲高密度的屏幕提供高清晰度的圖像等。
3）不要使用AbsoluteLayout
4）像素單位都使用DIP，文本單位使用SP

六、在代碼中獲取屏幕像素、屏幕密度
DisplayMetrics metric = new DisplayMetrics();
getWindowManager().getDefaultDisplay().getMetrics(metric);
int width = metric.widthPixels; // 屏幕寬度（像素）
int height = metric.heightPixels; // 屏幕高度（像素）
float density = metric.density; // 屏幕密度（0.75 / 1.0 / 1.5）
int densityDpi = metric.densityDpi; // 屏幕密度DPI（120 / 160 / 240）

七、 通常多分辨率處理方法及其缺點7.1 圖片縮放基於當前屏幕的精度，平臺自動加載任何未經縮放的限定尺寸和精度的圖片。若是圖片不匹配，平臺會加載默認資源而且在放大或者縮小以後能夠知足當前界面的顯 示要求。例如，當前爲高精度屏幕，平臺會加載高精度資源（如HelloAndroid中drawable-hdpi 中的位圖資源），若是沒有，平臺會將中精度資源縮放至高精度，致使圖片顯示不清晰。7.2 自動定義像素尺寸和位置若是程序不支持多種精度屏幕，平臺會自動定義像素絕對位置和尺寸值等，這樣就能保證元素能和精度160 的屏幕上同樣能顯示出一樣尺寸的效果。例如，要讓WVGA 高精度屏幕和傳統的HVGA 屏幕同樣顯示一樣尺寸的圖片，當程序不支持時，系統會對程序慌稱屏幕分辨率爲320×480,在（10,10）到（100,100）的區域內繪製圖形完成 以後，系統會將圖形放大到（15,15）到（150,150）的屏幕顯示區域。7.3 兼容更大尺寸的屏幕當前屏幕超過程序所支持屏幕的上限時，定義supportsscreens元素，這樣超出顯示的基準線時，平臺在此顯示黑色的背景圖。例如，WVGA 中精度屏幕上，如程序不支持這樣的大屏幕，系統會謊稱是一個320×480 的，多餘的顯示區域會被填充成黑色。7.4 採用OpenGL 動態繪製圖片Android 底層提供了OpenGL 的接口和方法，能夠動態繪製圖片，可是這種方式對不熟悉計算機圖形學的開發者來說是一個很大的挑戰。通常開發遊戲，採用OpenGL 方式。7.5 多個apk 文件Symbian 和傳統的J2ME 就是採用這種方式，爲一款應用提供多個分辨率版本，用戶根據本身的需求下載安裝相應的可執行文件。針對每一種屏幕單獨開發應用程序不失爲一種好方法，可是 目前Google Market 對一個應用程序多個分辨率版本的支持還不完善，開發者仍是須要儘量使用一個apk 文件適應多個分辨率。