Android實戰技術: 用Dimension解決多螢幕適配的問題
阿新 • • 發佈：2018-12-16
膚上線啦
比如:字串的獲取和使用.最直接的方式就是直接在程式碼中使用字面常量.但處理多語言時,這就非常的麻煩,需要程式碼去判斷當前系統語言,然後決定使用哪個!但如果使用資源管理器來獲取字串,就把程式碼耦合降到最低:只有資源管理器需要判斷當前系統語言,然後去去相應的字串.其他人則無需要關心.
Android當中也是這樣子的,程式碼通過統一的介面獲取系統資源,而由資源管理器來處理裝置相關性的問題.
螢幕尺寸的大與小,通常能決定螢幕究竟能顯示多少內容,比如電腦上能顯示的區域一般都要比手機要多.
有了螢幕密度的概念就可以看到,同樣尺寸(解析度)的圖片在高密度的螢幕上顯示的物理尺寸就會小(看起來小了),在低密度的螢幕上顯示的物理尺寸就會變大(看起來大了).
所以為什麼,沒有為MBP視網膜屏做適配的軟體,比如PS的圖示會看起來模糊.因為MBP視網膜螢幕的密度大大提高,是以前的4倍,所以同樣尺寸的圖片看起來就會比原來小,是原來的1/4,太小了會看不見的,但是這樣使用起來是很不方便的.所以Mac系統為了適應新的視網膜螢幕,就必須把圖片進行縮放,放大原來的四倍,這樣在使用者眼中"看起來"(物理尺寸)圖片還是那麼大!因為圖示被拉大了四倍,當然會模糊了!所以,Mac上面的應用,在視網膜之後必須對應用進行專門的優化和適配.
根據不同的螢幕解析度來區分不同的裝置,比如一些常見的名字:
那麼,有一些的GUI系統就是以解析度方式來區分不同的資源.
但是,如前面所述,解析度不能代表螢幕的清晰程度.同樣解析度的圖片,或者同樣的長度在高密度的螢幕上看起來就會小,在低密度的螢幕上就會變大!因為它的單位是畫素.所以,如果以解析度作為依據來區分資源,那麼就必須為所有不同的解析度設定資源,並且做適配的優化,否則就不會得到好的顯示效果!而想一想這工作量會多大!
所以,就出來了一個新的長度單位DIP---Density Independent Pixels,也就是密度無關的一個抽象的單位長度.它不像畫素或者Inch之類的固定不變,而是隨著裝置的密度而變化的.在低密度的裝置上它的值很小,而在高密度的螢幕上它的值會變得大些,這樣一來,開發者就可以指定一個長度從而適應不同密度的螢幕,以解決低密度螢幕變大,高密度螢幕變小的問題.詳細的來講:比如某一視窗的長度是100DIP,在低密度的螢幕上DIP值,假如說是1pixel,那麼長度就變成了100 pixels；而到了高密度螢幕上,DIP可能會變成了1.5 pixel,這樣長度就變成了150pixels. 這樣就達到了,以不變應萬變的目的.而DIP具體取什麼值,也是由裝置來給出,因為裝置知道它自己是什麼樣的密度.
當然,現實的生活沒有這麼完美,各種裝置千差萬別.但是總體仍可分為這三大類,為這三大類準備好圖片後,其他的只要與某一類較接近,即使稍有拉伸或失真,也不太明顯,是可以接受的.所以,對於一般性的應用程式,寫一個佈局檔案在layout中,為三種密度準備圖片drawable-hdpi, drawable-mdpi, drawable-ldpi,就足以應對80%的裝置.
但是光以密度螢幕來分類和處理還不夠.隨著裝置的越來越多,以及螢幕尺寸越來越大,還有就是Tablet的出現,又會出現這樣的問題:裝置的螢幕密度雖然不高,但其解析度很高.舉個簡單的例子:iPad2的解析度是1024x768,iPhone 4 960x640,但是iPhone 4的密度是326ppi,遠大於iPad2.但是,無論密度有多高它的螢幕就那麼,最多能顯示960x640個畫素點,一個1024*768的圖片在iPad上可以看到全部,而iPhone上只能看到一大半!這也是為什麼用iPad來執行iPhone上的應用程式時,只是以螢幕中間的一部分來模擬顯示的原因.
對Android來說也是一樣的.如此一來,即使相同的dpi,假如其螢幕尺寸非常大,那麼為其準備的圖片將被拉伸很大或者顯示不全.UI元素也會被拉伸很長.這樣並不是很好的體驗.對於尺寸大的螢幕應該讓其顯示更多的內容,而不是把一部分元素拉伸很大.所以,很多手機安卓應用如果未經專門適配,在平板上直接使用體驗將會是非常差的.
為了解決這樣的問題,就還必須以螢幕尺寸來區分裝置
主要有四種螢幕尺寸:small, normal, large and xlarge
這主要是配合螢幕密度來一起使用,比如,適配平板的圖片:
drawable-xlarge-hdpi/ic_launcher.png
這裡就要提到了密度,尺寸和解析度的對應關係了. 螢幕解析度是隨裝置變化最明顯的一個,上面的二種分類方法僅是對螢幕進行的大致的一個分類.雖然螢幕解析度與密度沒有直接的關係,但是所有的裝置都基本上一致的(約定俗成?):
ldpi QVGA 240*320 0.8
mdpi HVGA 320*480 1.0
hdpi WVGA 480*800 1.5
hdpi qHD 540*960 1.5
xdpi WXGA 720*1280 2
對於,如何適配,以及如何提供資源可以閱讀官方文件,裡面講的還算詳細.http://developer.android.com/guide/topics/resources/providing-resources.html
這時可以把高度或者寬度抽象出來放到一個單獨 的資源dimensions中,從而把變化的東西降到最小:
比如某個View的高度:
最後,分享一個坑,資源的預設值並不總是values,drawable和layout. 當你分別在values中指定一個值和在values-mdpi中指定一個值,對於其他的型別如hdpi會使用mdpi中的值,而非values中的值.
另外就是,做圖片時需要注意尺寸問題
比如:字串的獲取和使用.最直接的方式就是直接在程式碼中使用字面常量.但處理多語言時,這就非常的麻煩,需要程式碼去判斷當前系統語言,然後決定使用哪個!但如果使用資源管理器來獲取字串,就把程式碼耦合降到最低:只有資源管理器需要判斷當前系統語言,然後去去相應的字串.其他人則無需要關心.
Android當中也是這樣子的,程式碼通過統一的介面獲取系統資源,而由資源管理器來處理裝置相關性的問題.
螢幕尺寸的大與小,通常能決定螢幕究竟能顯示多少內容,比如電腦上能顯示的區域一般都要比手機要多.
有了螢幕密度的概念就可以看到,同樣尺寸(解析度)的圖片在高密度的螢幕上顯示的物理尺寸就會小(看起來小了),在低密度的螢幕上顯示的物理尺寸就會變大(看起來大了).
所以為什麼,沒有為MBP視網膜屏做適配的軟體,比如PS的圖示會看起來模糊.因為MBP視網膜螢幕的密度大大提高,是以前的4倍,所以同樣尺寸的圖片看起來就會比原來小,是原來的1/4,太小了會看不見的,但是這樣使用起來是很不方便的.所以Mac系統為了適應新的視網膜螢幕,就必須把圖片進行縮放,放大原來的四倍,這樣在使用者眼中"看起來"(物理尺寸)圖片還是那麼大!因為圖示被拉大了四倍,當然會模糊了!所以,Mac上面的應用,在視網膜之後必須對應用進行專門的優化和適配.
根據不同的螢幕解析度來區分不同的裝置,比如一些常見的名字:
那麼,有一些的GUI系統就是以解析度方式來區分不同的資源.
但是,如前面所述,解析度不能代表螢幕的清晰程度.同樣解析度的圖片,或者同樣的長度在高密度的螢幕上看起來就會小,在低密度的螢幕上就會變大!因為它的單位是畫素.所以,如果以解析度作為依據來區分資源,那麼就必須為所有不同的解析度設定資源,並且做適配的優化,否則就不會得到好的顯示效果!而想一想這工作量會多大!
所以,就出來了一個新的長度單位DIP---Density Independent Pixels,也就是密度無關的一個抽象的單位長度.它不像畫素或者Inch之類的固定不變,而是隨著裝置的密度而變化的.在低密度的裝置上它的值很小,而在高密度的螢幕上它的值會變得大些,這樣一來,開發者就可以指定一個長度從而適應不同密度的螢幕,以解決低密度螢幕變大,高密度螢幕變小的問題.詳細的來講:比如某一視窗的長度是100DIP,在低密度的螢幕上DIP值,假如說是1pixel,那麼長度就變成了100 pixels；而到了高密度螢幕上,DIP可能會變成了1.5 pixel,這樣長度就變成了150pixels. 這樣就達到了,以不變應萬變的目的.而DIP具體取什麼值,也是由裝置來給出,因為裝置知道它自己是什麼樣的密度.
當然,現實的生活沒有這麼完美,各種裝置千差萬別.但是總體仍可分為這三大類,為這三大類準備好圖片後,其他的只要與某一類較接近,即使稍有拉伸或失真,也不太明顯,是可以接受的.所以,對於一般性的應用程式,寫一個佈局檔案在layout中,為三種密度準備圖片drawable-hdpi, drawable-mdpi, drawable-ldpi,就足以應對80%的裝置.
但是光以密度螢幕來分類和處理還不夠.隨著裝置的越來越多,以及螢幕尺寸越來越大,還有就是Tablet的出現,又會出現這樣的問題:裝置的螢幕密度雖然不高,但其解析度很高.舉個簡單的例子:iPad2的解析度是1024x768,iPhone 4 960x640,但是iPhone 4的密度是326ppi,遠大於iPad2.但是,無論密度有多高它的螢幕就那麼,最多能顯示960x640個畫素點,一個1024*768的圖片在iPad上可以看到全部,而iPhone上只能看到一大半!這也是為什麼用iPad來執行iPhone上的應用程式時,只是以螢幕中間的一部分來模擬顯示的原因.
對Android來說也是一樣的.如此一來,即使相同的dpi,假如其螢幕尺寸非常大,那麼為其準備的圖片將被拉伸很大或者顯示不全.UI元素也會被拉伸很長.這樣並不是很好的體驗.對於尺寸大的螢幕應該讓其顯示更多的內容,而不是把一部分元素拉伸很大.所以,很多手機安卓應用如果未經專門適配,在平板上直接使用體驗將會是非常差的.
為了解決這樣的問題,就還必須以螢幕尺寸來區分裝置
主要有四種螢幕尺寸:small, normal, large and xlarge
這主要是配合螢幕密度來一起使用,比如,適配平板的圖片:
drawable-xlarge-hdpi/ic_launcher.png
這裡就要提到了密度,尺寸和解析度的對應關係了. 螢幕解析度是隨裝置變化最明顯的一個,上面的二種分類方法僅是對螢幕進行的大致的一個分類.雖然螢幕解析度與密度沒有直接的關係,但是所有的裝置都基本上一致的(約定俗成?):
ldpi QVGA 240*320 0.8
mdpi HVGA 320*480 1.0
hdpi WVGA 480*800 1.5
hdpi qHD 540*960 1.5
xdpi WXGA 720*1280 2
對於,如何適配,以及如何提供資源可以閱讀官方文件,裡面講的還算詳細.http://developer.android.com/guide/topics/resources/providing-resources.html
這時可以把高度或者寬度抽象出來放到一個單獨 的資源dimensions中,從而把變化的東西降到最小:
比如某個View的高度:
最後,分享一個坑,資源的預設值並不總是values,drawable和layout. 當你分別在values中指定一個值和在values-mdpi中指定一個值,對於其他的型別如hdpi會使用mdpi中的值,而非values中的值.
另外就是,做圖片時需要注意尺寸問題
Android實戰技術: 用Dimension解決多螢幕適配的問題
原文地址
開閉原則--可變與不變的分離,且容易定製
應用程式的目的是儘可能做到適用於多種裝置,這些裝置的配置不盡相同,有些不同的物理尺寸,解析度.為了達到最佳的適配效果,和最少的程式碼重複,以及最好的可擴充套件性,就需要分離資源的使用和資源.用一個統一的資源管理者來管理資源.程式碼通過資源管理者提供的統一的介面來獲取資源.這樣對於使用者來講資源的獲取的方式是統一,資源者無需關心如何為不同的裝置獲取不同的資源.這樣就把隨不同裝置變化而變化的程式碼降到最低,只有資源管理者需要操心不同的裝置相關的不同的資源.比如:字串的獲取和使用.最直接的方式就是直接在程式碼中使用字面常量.但處理多語言時,這就非常的麻煩,需要程式碼去判斷當前系統語言,然後決定使用哪個!但如果使用資源管理器來獲取字串,就把程式碼耦合降到最低:只有資源管理器需要判斷當前系統語言,然後去去相應的字串.其他人則無需要關心.
Android當中也是這樣子的,程式碼通過統一的介面獲取系統資源,而由資源管理器來處理裝置相關性的問題.
Android的資源裡面常見的hdpi等這都是什麼意思呢?要理解這些,先要了解一下標準的Graphic Design中的一些度量和尺寸的
基本的術語和概念:
螢幕尺寸 Screen size
是指螢幕的物理尺寸,度量的方式是以螢幕對角線的長度,單位是英寸(1英寸=2.54釐米).螢幕尺寸的大與小,通常能決定螢幕究竟能顯示多少內容,比如電腦上能顯示的區域一般都要比手機要多.
解析度Resolution
通常以畫素為單位,畫素的定義為裝置能顯示的基本單元,比如480x800,或者1024x768,這意思就是說這個螢幕在長度上能顯示1024這麼多個點,在高度上能顯示768個點.解析度通常用於表示影象的尺寸.但是解析度不能代表影象的真實物理尺寸.也不能決定在螢幕上顯示的物理尺寸.螢幕密度Density
是指這個螢幕在單位長度上能顯示的畫素點數,也就是一英寸上能顯示的畫素點數,計算方式就是解析度除以物理尺寸.螢幕密度能反應裝置的清晰程度.單位通常是PPI(Pixels Per Inch). PPI值越高,證明螢幕的清晰程度越好,能顯示的越清楚.比如蘋果的Retina系列螢幕,達到了326PPI.人眼的識別能力在300PPI左右,所以達到326時,人眼就無法分辨出畫素點了,所以它顯示的就更清晰.有了螢幕密度的概念就可以看到,同樣尺寸(解析度)的圖片在高密度的螢幕上顯示的物理尺寸就會小(看起來小了),在低密度的螢幕上顯示的物理尺寸就會變大(看起來大了).
所以為什麼,沒有為MBP視網膜屏做適配的軟體,比如PS的圖示會看起來模糊.因為MBP視網膜螢幕的密度大大提高,是以前的4倍,所以同樣尺寸的圖片看起來就會比原來小,是原來的1/4,太小了會看不見的,但是這樣使用起來是很不方便的.所以Mac系統為了適應新的視網膜螢幕,就必須把圖片進行縮放,放大原來的四倍,這樣在使用者眼中"看起來"(物理尺寸)圖片還是那麼大!因為圖示被拉大了四倍,當然會模糊了!所以,Mac上面的應用,在視網膜之後必須對應用進行專門的優化和適配.
螢幕的長寬比
物理長度與物理寬度的比例.如何適配不同的螢幕
適配不同的螢幕的目的也就是讓應用在所有的系統上體驗一致. 這個不同的平臺有不同的策略.有些平臺僅是以螢幕解析度為依據.也就是把裝置以螢幕解析度為分類依據.這也是平常所見的VGA一類的名字的來源:根據不同的螢幕解析度來區分不同的裝置,比如一些常見的名字:
QVGA: 240*320 Quarter VGA 四分之一的意思(1/2 * 1/2 = 1/4)等等,關於解析度的區分可以參考維基百科:Graphics display resolution
HVGA: 320*480 Half size VGA 的意思 二分之一(1/2 * 1 = 1/2)
VGA: 480*640 遠古時代的電腦顯示器的解析度,其他的都是以此為基礎來縮放
WVGA: 480*800 Wide VGA
SVGA: 600*800 Super VGA
那麼,有一些的GUI系統就是以解析度方式來區分不同的資源.
但是,如前面所述,解析度不能代表螢幕的清晰程度.同樣解析度的圖片,或者同樣的長度在高密度的螢幕上看起來就會小,在低密度的螢幕上就會變大!因為它的單位是畫素.所以,如果以解析度作為依據來區分資源,那麼就必須為所有不同的解析度設定資源,並且做適配的優化,否則就不會得到好的顯示效果!而想一想這工作量會多大!
螢幕密度無關的單位長度
適配不同的螢幕的目的是什麼 呢?就是為了能讓1.應用在不同的平臺都能正常的顯示,也就是把該顯示的顯示出來,不能太大(低密度上)也不能太小(高密度上)做為懶惰的人類的目的是:用最小的工作量來適配最多的螢幕,那麼怎麼做到呢?如果能有一個度量單位能隨螢幕變化而變化,那多好啊,這樣就可以指定一個長度,讓裝置自己去處理變化的因素.
2. 排版等能夠一致.也就是說元素在大尺寸螢幕上(高解析度)上要大些,在小尺寸螢幕(低解析度)上要小些
所以,就出來了一個新的長度單位DIP---Density Independent Pixels,也就是密度無關的一個抽象的單位長度.它不像畫素或者Inch之類的固定不變,而是隨著裝置的密度而變化的.在低密度的裝置上它的值很小,而在高密度的螢幕上它的值會變得大些,這樣一來,開發者就可以指定一個長度從而適應不同密度的螢幕,以解決低密度螢幕變大,高密度螢幕變小的問題.詳細的來講:比如某一視窗的長度是100DIP,在低密度的螢幕上DIP值,假如說是1pixel,那麼長度就變成了100 pixels；而到了高密度螢幕上,DIP可能會變成了1.5 pixel,這樣長度就變成了150pixels. 這樣就達到了,以不變應萬變的目的.而DIP具體取什麼值,也是由裝置來給出,因為裝置知道它自己是什麼樣的密度.
Android上的適配策略
Android上面如何解決適配不同尺寸(解析度)和密度的問題呢?它主要是通過以密度分類,再加上解析度的方式來減化適配不同尺寸螢幕的工作量.
高密度: hdpi (High dots per inch)並且佈局中推薦使用密度無關單位dip或dp,來作為長度或者寬度的單位.這樣,從理論上來講,開發者只需要做:
中等密度: mdpi (Medium dots per inch)
低密度: ldpi (Low dots per inch)
1. 為不同的密度螢幕準備圖片資源就可以適配所有的裝置,讓佈局在所有的螢幕上都得到比較好的顯示效果.
(圖片是沒辦法的,因為圖片的長度和寬度是固定的畫素值,不能夠隨密度變化而變化,可以強行拉伸,但圖片會失真.當然也有9 Patch圖片可以解決隨意拉伸的問題.但普通的圖片的長度和寬度是固定的.
2. 用dip作為單位來指定長度或者寬度
當然,現實的生活沒有這麼完美,各種裝置千差萬別.但是總體仍可分為這三大類,為這三大類準備好圖片後,其他的只要與某一類較接近,即使稍有拉伸或失真,也不太明顯,是可以接受的.所以,對於一般性的應用程式,寫一個佈局檔案在layout中,為三種密度準備圖片drawable-hdpi, drawable-mdpi, drawable-ldpi,就足以應對80%的裝置.
res/(這裡可能有點過時了,因為現在多了xdpi,而且很多裝置也是xdpi的.)
drawable-hdpi/
ic_launcher.png
drawable-mdpi/
ic_launcher.png
drawable-ldpi/
ic_launcher.png
layout/
main.xml
但是光以密度螢幕來分類和處理還不夠.隨著裝置的越來越多,以及螢幕尺寸越來越大,還有就是Tablet的出現,又會出現這樣的問題:裝置的螢幕密度雖然不高,但其解析度很高.舉個簡單的例子:iPad2的解析度是1024x768,iPhone 4 960x640,但是iPhone 4的密度是326ppi,遠大於iPad2.但是,無論密度有多高它的螢幕就那麼,最多能顯示960x640個畫素點,一個1024*768的圖片在iPad上可以看到全部,而iPhone上只能看到一大半!這也是為什麼用iPad來執行iPhone上的應用程式時,只是以螢幕中間的一部分來模擬顯示的原因.
對Android來說也是一樣的.如此一來,即使相同的dpi,假如其螢幕尺寸非常大,那麼為其準備的圖片將被拉伸很大或者顯示不全.UI元素也會被拉伸很長.這樣並不是很好的體驗.對於尺寸大的螢幕應該讓其顯示更多的內容,而不是把一部分元素拉伸很大.所以,很多手機安卓應用如果未經專門適配,在平板上直接使用體驗將會是非常差的.
為了解決這樣的問題,就還必須以螢幕尺寸來區分裝置
主要有四種螢幕尺寸:small, normal, large and xlarge
這主要是配合螢幕密度來一起使用,比如,適配平板的圖片:
drawable-xlarge-hdpi/ic_launcher.png
這裡就要提到了密度,尺寸和解析度的對應關係了. 螢幕解析度是隨裝置變化最明顯的一個,上面的二種分類方法僅是對螢幕進行的大致的一個分類.雖然螢幕解析度與密度沒有直接的關係,但是所有的裝置都基本上一致的(約定俗成?):
ldpi QVGA 240*320 0.8
mdpi HVGA 320*480 1.0
hdpi WVGA 480*800 1.5
hdpi qHD 540*960 1.5
xdpi WXGA 720*1280 2
對於,如何適配,以及如何提供資源可以閱讀官方文件,裡面講的還算詳細.http://developer.android.com/guide/topics/resources/providing-resources.html
適配不同螢幕的常見問題
雖然有了上述的策略的方式,但是在實際中還是不夠的.因為螢幕尺寸的比例與密度的比例並不一致.舉例來說HVGA與WVGA相比,寬度的比例與密度的比例是一致的480/320=1.5.所以說寬度上顯示的內容一樣多.無需操心.但是高度上面就不一樣了.800/480 >1.5,這就造成了什麼情況呢,也就是同樣的東西縮放了1.5倍以後,對於WVGA還會有相當的螢幕空著.或者如果以WVGA為基準時,放到HVGA上就會顯示不全. 在qHD上這個問題會更明顯.甚至同樣的hdpi的WVGA和qHD都會有問題,qHD能顯示的內容要多於WVGA.使用dimension資源來解決問題
從上面的問題可以看出,密度無關的單位解決不了上面的問題.當然也可以選擇為每一解析度做一佈局,但這樣又會造成大量的重複工作,因為畢竟佈局是相同的,僅是元素的高度或者寬度需要考慮解析度和螢幕密度.這時可以把高度或者寬度抽象出來放到一個單獨 的資源dimensions中,從而把變化的東西降到最小:
比如某個View的高度:
layout/還有一點就是,儘可能用相對的值,如wrap_content和fill_parent(or match_parent)它們不是固定的值而是會在具體佈局的時候計算出來.
main.xml # android:layout_height="@dimen/view_height"
values-mdpi
dimensions.xml item name="view_height">20dip</item>
values-hdpi
dimensions.xml 30dip
values-hdpi-960x540
dimensions.xml 40dip
最後,分享一個坑,資源的預設值並不總是values,drawable和layout. 當你分別在values中指定一個值和在values-mdpi中指定一個值,對於其他的型別如hdpi會使用mdpi中的值,而非values中的值.
另外就是,做圖片時需要注意尺寸問題
因為圖片的尺寸是以畫素為單位,而Android應用程式中多以dip或dp為單位,所以就要注意不同密度上它們的對應關係.讓畫素仁值和用dip換算過後都是整數.舉例來講HVGA上或者mdpi上1個dip就等於1個畫素.但到了WVGA或者hdpi上1個dip就是1.5個畫素,所以對於WVGA的圖片的尺寸的畫素值最好能是1.5的倍數.這樣就更方便用dip來定義圖片的長度的寬度.
其他有用的資料:
1. Support different Android device configurations with dimension resources
3. 適配特定的解析度
開閉原則--可變與不變的分離,且容易定製
應用程式的目的是儘可能做到適用於多種裝置,這些裝置的配置不盡相同,有些不同的物理尺寸,解析度.為了達到最佳的適配效果,和最少的程式碼重複,以及最好的可擴充套件性,就需要分離資源的使用和資源.用一個統一的資源管理者來管理資源.程式碼通過資源管理者提供的統一的介面來獲取資源.這樣對於使用者來講資源的獲取的方式是統一,資源者無需關心如何為不同的裝置獲取不同的資源.這樣就把隨不同裝置變化而變化的程式碼降到最低,只有資源管理者需要操心不同的裝置相關的不同的資源.比如:字串的獲取和使用.最直接的方式就是直接在程式碼中使用字面常量.但處理多語言時,這就非常的麻煩,需要程式碼去判斷當前系統語言,然後決定使用哪個!但如果使用資源管理器來獲取字串,就把程式碼耦合降到最低:只有資源管理器需要判斷當前系統語言,然後去去相應的字串.其他人則無需要關心.
Android當中也是這樣子的,程式碼通過統一的介面獲取系統資源,而由資源管理器來處理裝置相關性的問題.
Android的資源裡面常見的hdpi等這都是什麼意思呢?要理解這些,先要了解一下標準的Graphic Design中的一些度量和尺寸的
基本的術語和概念:
螢幕尺寸 Screen size
是指螢幕的物理尺寸,度量的方式是以螢幕對角線的長度,單位是英寸(1英寸=2.54釐米).螢幕尺寸的大與小,通常能決定螢幕究竟能顯示多少內容,比如電腦上能顯示的區域一般都要比手機要多.
解析度Resolution
通常以畫素為單位,畫素的定義為裝置能顯示的基本單元,比如480x800,或者1024x768,這意思就是說這個螢幕在長度上能顯示1024這麼多個點,在高度上能顯示768個點.解析度通常用於表示影象的尺寸.但是解析度不能代表影象的真實物理尺寸.也不能決定在螢幕上顯示的物理尺寸.螢幕密度Density
是指這個螢幕在單位長度上能顯示的畫素點數,也就是一英寸上能顯示的畫素點數,計算方式就是解析度除以物理尺寸.螢幕密度能反應裝置的清晰程度.單位通常是PPI(Pixels Per Inch). PPI值越高,證明螢幕的清晰程度越好,能顯示的越清楚.比如蘋果的Retina系列螢幕,達到了326PPI.人眼的識別能力在300PPI左右,所以達到326時,人眼就無法分辨出畫素點了,所以它顯示的就更清晰.有了螢幕密度的概念就可以看到,同樣尺寸(解析度)的圖片在高密度的螢幕上顯示的物理尺寸就會小(看起來小了),在低密度的螢幕上顯示的物理尺寸就會變大(看起來大了).
所以為什麼,沒有為MBP視網膜屏做適配的軟體,比如PS的圖示會看起來模糊.因為MBP視網膜螢幕的密度大大提高,是以前的4倍,所以同樣尺寸的圖片看起來就會比原來小,是原來的1/4,太小了會看不見的,但是這樣使用起來是很不方便的.所以Mac系統為了適應新的視網膜螢幕,就必須把圖片進行縮放,放大原來的四倍,這樣在使用者眼中"看起來"(物理尺寸)圖片還是那麼大!因為圖示被拉大了四倍,當然會模糊了!所以,Mac上面的應用,在視網膜之後必須對應用進行專門的優化和適配.
螢幕的長寬比
物理長度與物理寬度的比例.如何適配不同的螢幕
適配不同的螢幕的目的也就是讓應用在所有的系統上體驗一致. 這個不同的平臺有不同的策略.有些平臺僅是以螢幕解析度為依據.也就是把裝置以螢幕解析度為分類依據.這也是平常所見的VGA一類的名字的來源:根據不同的螢幕解析度來區分不同的裝置,比如一些常見的名字:
QVGA: 240*320 Quarter VGA 四分之一的意思(1/2 * 1/2 = 1/4)等等,關於解析度的區分可以參考維基百科:Graphics display resolution
HVGA: 320*480 Half size VGA 的意思 二分之一(1/2 * 1 = 1/2)
VGA: 480*640 遠古時代的電腦顯示器的解析度,其他的都是以此為基礎來縮放
WVGA: 480*800 Wide VGA
SVGA: 600*800 Super VGA
那麼,有一些的GUI系統就是以解析度方式來區分不同的資源.
但是,如前面所述,解析度不能代表螢幕的清晰程度.同樣解析度的圖片,或者同樣的長度在高密度的螢幕上看起來就會小,在低密度的螢幕上就會變大!因為它的單位是畫素.所以,如果以解析度作為依據來區分資源,那麼就必須為所有不同的解析度設定資源,並且做適配的優化,否則就不會得到好的顯示效果!而想一想這工作量會多大!
螢幕密度無關的單位長度
適配不同的螢幕的目的是什麼 呢?就是為了能讓1.應用在不同的平臺都能正常的顯示,也就是把該顯示的顯示出來,不能太大(低密度上)也不能太小(高密度上)做為懶惰的人類的目的是:用最小的工作量來適配最多的螢幕,那麼怎麼做到呢?如果能有一個度量單位能隨螢幕變化而變化,那多好啊,這樣就可以指定一個長度,讓裝置自己去處理變化的因素.
2. 排版等能夠一致.也就是說元素在大尺寸螢幕上(高解析度)上要大些,在小尺寸螢幕(低解析度)上要小些
所以,就出來了一個新的長度單位DIP---Density Independent Pixels,也就是密度無關的一個抽象的單位長度.它不像畫素或者Inch之類的固定不變,而是隨著裝置的密度而變化的.在低密度的裝置上它的值很小,而在高密度的螢幕上它的值會變得大些,這樣一來,開發者就可以指定一個長度從而適應不同密度的螢幕,以解決低密度螢幕變大,高密度螢幕變小的問題.詳細的來講:比如某一視窗的長度是100DIP,在低密度的螢幕上DIP值,假如說是1pixel,那麼長度就變成了100 pixels；而到了高密度螢幕上,DIP可能會變成了1.5 pixel,這樣長度就變成了150pixels. 這樣就達到了,以不變應萬變的目的.而DIP具體取什麼值,也是由裝置來給出,因為裝置知道它自己是什麼樣的密度.
Android上的適配策略
Android上面如何解決適配不同尺寸(解析度)和密度的問題呢?它主要是通過以密度分類,再加上解析度的方式來減化適配不同尺寸螢幕的工作量.
高密度: hdpi (High dots per inch)並且佈局中推薦使用密度無關單位dip或dp,來作為長度或者寬度的單位.這樣,從理論上來講,開發者只需要做:
中等密度: mdpi (Medium dots per inch)
低密度: ldpi (Low dots per inch)
1. 為不同的密度螢幕準備圖片資源就可以適配所有的裝置,讓佈局在所有的螢幕上都得到比較好的顯示效果.
(圖片是沒辦法的,因為圖片的長度和寬度是固定的畫素值,不能夠隨密度變化而變化,可以強行拉伸,但圖片會失真.當然也有9 Patch圖片可以解決隨意拉伸的問題.但普通的圖片的長度和寬度是固定的.
2. 用dip作為單位來指定長度或者寬度
當然,現實的生活沒有這麼完美,各種裝置千差萬別.但是總體仍可分為這三大類,為這三大類準備好圖片後,其他的只要與某一類較接近,即使稍有拉伸或失真,也不太明顯,是可以接受的.所以,對於一般性的應用程式,寫一個佈局檔案在layout中,為三種密度準備圖片drawable-hdpi, drawable-mdpi, drawable-ldpi,就足以應對80%的裝置.
res/(這裡可能有點過時了,因為現在多了xdpi,而且很多裝置也是xdpi的.)
drawable-hdpi/
ic_launcher.png
drawable-mdpi/
ic_launcher.png
drawable-ldpi/
ic_launcher.png
layout/
main.xml
但是光以密度螢幕來分類和處理還不夠.隨著裝置的越來越多,以及螢幕尺寸越來越大,還有就是Tablet的出現,又會出現這樣的問題:裝置的螢幕密度雖然不高,但其解析度很高.舉個簡單的例子:iPad2的解析度是1024x768,iPhone 4 960x640,但是iPhone 4的密度是326ppi,遠大於iPad2.但是,無論密度有多高它的螢幕就那麼,最多能顯示960x640個畫素點,一個1024*768的圖片在iPad上可以看到全部,而iPhone上只能看到一大半!這也是為什麼用iPad來執行iPhone上的應用程式時,只是以螢幕中間的一部分來模擬顯示的原因.
對Android來說也是一樣的.如此一來,即使相同的dpi,假如其螢幕尺寸非常大,那麼為其準備的圖片將被拉伸很大或者顯示不全.UI元素也會被拉伸很長.這樣並不是很好的體驗.對於尺寸大的螢幕應該讓其顯示更多的內容,而不是把一部分元素拉伸很大.所以,很多手機安卓應用如果未經專門適配,在平板上直接使用體驗將會是非常差的.
為了解決這樣的問題,就還必須以螢幕尺寸來區分裝置
主要有四種螢幕尺寸:small, normal, large and xlarge
這主要是配合螢幕密度來一起使用,比如,適配平板的圖片:
drawable-xlarge-hdpi/ic_launcher.png
這裡就要提到了密度,尺寸和解析度的對應關係了. 螢幕解析度是隨裝置變化最明顯的一個,上面的二種分類方法僅是對螢幕進行的大致的一個分類.雖然螢幕解析度與密度沒有直接的關係,但是所有的裝置都基本上一致的(約定俗成?):
ldpi QVGA 240*320 0.8
mdpi HVGA 320*480 1.0
hdpi WVGA 480*800 1.5
hdpi qHD 540*960 1.5
xdpi WXGA 720*1280 2
對於,如何適配,以及如何提供資源可以閱讀官方文件,裡面講的還算詳細.http://developer.android.com/guide/topics/resources/providing-resources.html
適配不同螢幕的常見問題
雖然有了上述的策略的方式,但是在實際中還是不夠的.因為螢幕尺寸的比例與密度的比例並不一致.舉例來說HVGA與WVGA相比,寬度的比例與密度的比例是一致的480/320=1.5.所以說寬度上顯示的內容一樣多.無需操心.但是高度上面就不一樣了.800/480 >1.5,這就造成了什麼情況呢,也就是同樣的東西縮放了1.5倍以後,對於WVGA還會有相當的螢幕空著.或者如果以WVGA為基準時,放到HVGA上就會顯示不全. 在qHD上這個問題會更明顯.甚至同樣的hdpi的WVGA和qHD都會有問題,qHD能顯示的內容要多於WVGA.使用dimension資源來解決問題
從上面的問題可以看出,密度無關的單位解決不了上面的問題.當然也可以選擇為每一解析度做一佈局,但這樣又會造成大量的重複工作,因為畢竟佈局是相同的,僅是元素的高度或者寬度需要考慮解析度和螢幕密度.這時可以把高度或者寬度抽象出來放到一個單獨 的資源dimensions中,從而把變化的東西降到最小:
比如某個View的高度:
layout/還有一點就是,儘可能用相對的值,如wrap_content和fill_parent(or match_parent)它們不是固定的值而是會在具體佈局的時候計算出來.
main.xml # android:layout_height="@dimen/view_height"
values-mdpi
dimensions.xml item name="view_height">20dip</item>
values-hdpi
dimensions.xml 30dip
values-hdpi-960x540
dimensions.xml 40dip
最後,分享一個坑,資源的預設值並不總是values,drawable和layout. 當你分別在values中指定一個值和在values-mdpi中指定一個值,對於其他的型別如hdpi會使用mdpi中的值,而非values中的值.
另外就是,做圖片時需要注意尺寸問題
因為圖片的尺寸是以畫素為單位,而Android應用程式中多以dip或dp為單位,所以就要注意不同密度上它們的對應關係.讓畫素仁值和用dip換算過後都是整數.舉例來講HVGA上或者mdpi上1個dip就等於1個畫素.但到了WVGA或者hdpi上1個dip就是1.5個畫素,所以對於WVGA的圖片的尺寸的畫素值最好能是1.5的倍數.這樣就更方便用dip來定義圖片的長度的寬度.
其他有用的資料:
1. Support different Android device configurations with dimension resources
3. 適配特定的解析度