Android drawable微技巧,你不知道的drawable細(xì)節(jié)
話說微技巧這個詞也是我自己發(fā)明的,因為drawable這個東西相信大家天天都在使用,每個人都再熟悉不過了,之所以叫微技巧就是對于這個我們再熟悉不過的技術(shù),可能還有一些你所不知道的細(xì)節(jié),那今天我們就來一起探究一下這些微小的細(xì)節(jié)吧。
大家都知道,在Android項目當(dāng)中,drawable文件夾都是用來放置圖片資源的,不管是jpg、png、還是9.png,都可以放在這里。除此之外,還有像selector這樣的xml文件也是可以放在drawable文件夾下面的。
但是如果你現(xiàn)在使用Android Studio來新建一個項目,你會發(fā)現(xiàn)有如下的目錄結(jié)構(gòu):
嗯?怎么會有這么多mipmap開頭的文件夾,而且它們的命名規(guī)則和drawable文件夾很相似,也是hdpi、mdpi、xhdpi等等,并且里面還真是放的圖片,難道Android項目中放置圖片的位置已經(jīng)改了?
對于剛剛從Eclipse轉(zhuǎn)向Android Studio的開發(fā)者們可能會對mipmap文件夾感到陌生,其實不用擔(dān)心,我們平時的編程習(xí)慣并不需要發(fā)生任何改變,因為mipmap文件夾只是用來放置應(yīng)用程序的icon的,僅此而已。那么在此之前,我們都是把應(yīng)用程序的icon圖標(biāo)和普通的圖片資源一起放到drawable文件夾下的,這樣看上去就會比較雜亂,有的時候想從一堆的圖片資源里面找icon半天也找不到,而文件一多也就容易出現(xiàn)漏放的情況,但恰恰Android是極度建議我們在每一種分辨率的文件夾下面都放一個相應(yīng)尺寸的icon的,因此將它們獨立出來專門放到mimap文件夾當(dāng)中就很好地解決了這個問題。
另外,將icon放置在mipmap文件夾還可以讓我們程序的launcher圖標(biāo)自動擁有跨設(shè)備密度展示的能力,比如說一臺屏幕密度是xxhdpi的設(shè)備可以自動加載mipmap-xxxhdpi下的icon來作為應(yīng)用程序的launcher圖標(biāo),這樣圖標(biāo)看上去就會更加細(xì)膩。
關(guān)于建議使用mipmap的原文可以參閱這篇文章:Getting Your Apps Ready for Nexus 6 and Nexus 9,當(dāng)然你還是要科學(xué)上網(wǎng)的。
除此之外,對于每種密度下的icon應(yīng)該設(shè)計成什么尺寸其實Android也是給出了最佳建議,icon的尺寸最好不要隨意設(shè)計,因為過低的分辨率會造成圖標(biāo)模糊,而過高的分辨率只會徒增APK大小。建議尺寸如下表所示:
然后我們引用mipmap的方式和之前引用drawable的方式是完全一致的,在資源中就使用@mipmap/res_id,在代碼就使用R.mipmap.res_id。比如AndroidManifest.xml中就是這樣引用ic_launcher圖標(biāo)的:
<application android:allowBackup="true" android:icon="@mipmap/ic_launcher" android:label="@string/app_name" android:supportsRtl="true" android:theme="@style/AppTheme"> <activity android:name=".MainActivity"> <intent-filter> <action android:name="android.intent.action.MAIN"/> <category android:name="android.intent.category.LAUNCHER"/> </intent-filter> </activity> </application>
好的,關(guān)于mimap的內(nèi)容就講這么多,它并不是本篇文章的重點,接下來我們來真真正正看一些drawable的微技巧。
首先我準(zhǔn)備了一張270*480像素的圖片:
將圖片命名為android_logo.png,然后把它放在drawable-xxhdpi文件夾下面。為什么要放在這個文件夾下呢?是因為我的手機屏幕的密度就是xxhdpi的。那么怎么才能知道自己手機屏幕的密度呢?你可以使用如下方法先獲取到屏幕的dpi值:
float xdpi = getResources().getDisplayMetrics().xdpi; float ydpi = getResources().getDisplayMetrics().ydpi;
其中xdpi代表屏幕寬度的dpi值,ydpi代表屏幕高度的dpi值,通常這兩個值都是近乎相等或者極其接近的,在我的手機上這兩個值都約等于403。那么403又代表著什么意思呢?我們直接參考下面這個表格就知道了:
從表中可以看出,403dpi是處于320dpi到480dpi之間的,因此屬于xxhdpi的范圍。
圖片放好了之后,下面我在布局文件中引用這張圖片,如下所示:
<?xml version="1.0" encoding="utf-8"?> <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" android:layout_width="match_parent" android:layout_height="match_parent" > <ImageView android:id="@+id/image" android:layout_width="wrap_content" android:layout_height="wrap_content" android:src="@drawable/android_logo" /> </LinearLayout>
在ImageView控件中指定加載android_logo這張圖,并把ImageView控件的寬高都設(shè)置成wrap_content,這樣圖片有多大,我們的控件就會有多大。
現(xiàn)在運行一下程序,效果如下所示:
由于我的手機分辨率是1080*1920像素的,而這張圖片的分辨率是270*480像素的,剛好是手機分辨率的四分之一,因此從上圖中也可以看出,android_logo圖片的寬和高大概都占據(jù)了屏幕寬高的四分之一左右,大小基本是比較精準(zhǔn)的。
到目前為止一切都挺順利的,不是嗎?下面我們嘗試做點改變,將android_logo.png這張圖移動到drawable-xhdpi文件夾下,注意不是復(fù)制一份到drawable-xhdpi文件夾下,而是將圖片移動到drawable-xhdpi文件夾下,然后重新運行一下程序,效果如下圖所示:
嗯?怎么感覺圖片好像變大了一點,是錯覺嗎?
那么我們再將這張圖移動到drawable-mdpi文件夾下試試,重新運行程序,效果如下圖所示:
這次肯定不是錯覺了,這實在是太明顯了,圖片被放大了!
那么為什么好端端的一張圖片會被自動放大呢?而且這放大的比例是不是有點太過份了。其實不然,Android所做的這些縮放操作都是有它嚴(yán)格的規(guī)定和算法的??赡苡胁簧僮隽撕芏嗄闍ndroid的朋友都沒去留意過這些縮放的規(guī)則,因為這些細(xì)節(jié)太微小了,那么本篇的微技巧探索里面,我們就來把這些細(xì)節(jié)理理清楚。
首先解釋一下圖片為什么會被放大,當(dāng)我們使用資源id來去引用一張圖片時,Android會使用一些規(guī)則來去幫我們匹配最適合的圖片。什么叫最適合的圖片?比如我的手機屏幕密度是xxhdpi,那么drawable-xxhdpi文件夾下的圖片就是最適合的圖片。因此,當(dāng)我引用android_logo這張圖時,如果drawable-xxhdpi文件夾下有這張圖就會優(yōu)先被使用,在這種情況下,圖片是不會被縮放的。但是,如果drawable-xxhdpi文件夾下沒有這張圖時, 系統(tǒng)就會自動去其它文件夾下找這張圖了,優(yōu)先會去更高密度的文件夾下找這張圖片,我們當(dāng)前的場景就是drawable-xxxhdpi文件夾,然后發(fā)現(xiàn)這里也沒有android_logo這張圖,接下來會嘗試再找更高密度的文件夾,發(fā)現(xiàn)沒有更高密度的了,這個時候會去drawable-nodpi文件夾找這張圖,發(fā)現(xiàn)也沒有,那么就會去更低密度的文件夾下面找,依次是drawable-xhdpi -> drawable-hdpi -> drawable-mdpi -> drawable-ldpi。
總體匹配規(guī)則就是這樣,那么比如說現(xiàn)在終于在drawable-mdpi文件夾下面找到android_logo這張圖了,但是系統(tǒng)會認(rèn)為你這張圖是專門為低密度的設(shè)備所設(shè)計的,如果直接將這張圖在當(dāng)前的高密度設(shè)備上使用就有可能會出現(xiàn)像素過低的情況,于是系統(tǒng)自動幫我們做了這樣一個放大操作。
那么同樣的道理,如果系統(tǒng)是在drawable-xxxhdpi文件夾下面找到這張圖的話,它會認(rèn)為這張圖是為更高密度的設(shè)備所設(shè)計的,如果直接將這張圖在當(dāng)前設(shè)備上使用就有可能會出現(xiàn)像素過高的情況,于是會自動幫我們做一個縮小的操作。所以,我們可以嘗試將android_logo這張圖移動到drawable-xxxhdpi文件夾下面將會得到這樣的結(jié)果:
可以看到,現(xiàn)在圖片的寬和高都達(dá)到不手機屏幕的四分之一,說明圖片確實是被縮小了。
另外,剛才在介紹規(guī)則的時候提到了一個drawable-nodpi文件夾,這個文件夾是一個密度無關(guān)的文件夾,放在這里的圖片系統(tǒng)就不會對它進(jìn)行自動縮放,原圖片是多大就會實際展示多大。但是要注意一個加載的順序,drawable-nodpi文件夾是在匹配密度文件夾和更高密度文件夾都找不到的情況下才會去這里查找圖片的,因此放在drawable-nodpi文件夾里的圖片通常情況下不建議再放到別的文件夾里面。
圖片被放大的原因現(xiàn)在我們已經(jīng)搞清楚了,那么接下來還有一個問題,就是放大的倍數(shù)是怎么確定的呢?很遺憾,我沒有找到相關(guān)的文檔記載,但是我自己總結(jié)出了一個規(guī)律,這里跟大家分享一下。
還是看一下剛才的 dpi范圍-密度 表格:
可以看到,每一種密度的dpi范圍都有一個最大值,這個最大值之間的比例就是圖片會被系統(tǒng)自動放大的比例。
口說無憑,下面我們來通過實例驗證一下,修改布局文件中的代碼,如下所示:
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" android:layout_width="match_parent" android:layout_height="match_parent" > <ImageView android:id="@+id/image" android:layout_width="wrap_content" android:layout_height="wrap_content" android:src="@drawable/android_logo" /> <Button android:layout_width="wrap_content" android:layout_height="wrap_content" android:text="獲取圖片寬高" android:onClick="buttonClick" /> </LinearLayout>
可以看到,我們添加了一個按鈕,并給按鈕注冊了一個點擊事件。然后在MainActivity中處理這個點擊事件:
public class MainActivity extends AppCompatActivity { ImageView imageView; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); imageView = (ImageView) findViewById(R.id.image); } public void buttonClick(View view) { Toast.makeText(this, "圖片寬度:" + imageView.getWidth(), Toast.LENGTH_SHORT).show(); Toast.makeText(this, "圖片高度:" + imageView.getHeight(), Toast.LENGTH_SHORT).show(); } }
這里在點擊事件中分別獲取圖片的寬和高并使用Toast提示出來。代碼修改這么多就可以了,然后將圖片移動到drawable-mdpi文件夾下。
下面我們來開始分析,mdpi密度的最高dpi值是160,而xxhdpi密度的最高dpi值是480,因此是一個3倍的關(guān)系,那么我們就可以猜測,放到drawable-mdpi文件夾下的圖片在xxhdpi密度的設(shè)備上顯示會被放大3倍。對應(yīng)到android_logo這張圖,原始像素是270*480,放大3倍之后就應(yīng)該是810*1440像素。下面運行程序,效果如下圖所示:
驗證通過。我們再來試驗一次,將圖片移動到drawable-xxxhdpi目錄下。xxxhdpi密度的最高dpi值是640,480是它的0.75倍,那么我們就可以猜測,放到drawable-xxxdpi文件夾下的圖片在xxhdpi密度的設(shè)備上顯示會被縮小至0.75倍。270*480的0.75倍應(yīng)該是202.5*360,由于像素不支持小數(shù)點,那么四舍五入就應(yīng)該是203*360像素。重新運行程序,效果如下圖所示:
再次驗證通過。如果你有興趣的話可以使用其它幾種dpi的drawable文件夾來試一試,應(yīng)該都是適配這套縮放規(guī)則的。這樣我們就把圖片為什么會被縮放,以及具體的縮放倍數(shù)都搞明白了,drawable相關(guān)的細(xì)節(jié)你已經(jīng)探究的非常細(xì)微了。
不過本篇文章到這里還沒結(jié)束,下面我準(zhǔn)備講一講我們在實際開發(fā)當(dāng)中會遇到的場景。根據(jù)Android的開發(fā)建議,我們在準(zhǔn)備圖片資源時盡量應(yīng)該給每種密度的設(shè)備都準(zhǔn)備一套,這樣程序的適配性就可以達(dá)到最好。但實際情況是,公司的UI們通常就只會給一套圖片資源,想讓他們針對每種密度的設(shè)備都設(shè)計一套圖片資源,并且還是按照我們上面講的縮放比例規(guī)則來設(shè)計,就有點想得太開心了。沒錯,這個就是現(xiàn)實情況,那么在這種情況下,我們應(yīng)該將僅有的這一套圖片資源放在哪個密度的文件夾下呢?
可以這樣來分析,根據(jù)我們剛才所學(xué)的內(nèi)容,如果將一張圖片放在低密度文件夾下,那么在高密度設(shè)備上顯示圖片時就會被自動放大,而如果將一張圖片放在高密度文件夾下,那么在低密度設(shè)備上顯示圖片時就會被自動縮小。那我們可以通過成本的方式來評估一下,一張原圖片被縮小了之后顯示其實并沒有什么副作用,但是一張原圖片被放大了之后顯示就意味著要占用更多的內(nèi)存了。因為圖片被放大了,像素點也就變多了,而每個像素點都是要占用內(nèi)存的。
我們?nèi)匀豢梢酝ㄟ^例子來直觀地體會一下,首先將android_logo.png圖片移動到drawable-xxhdpi目錄下,運行程序后我們通過Android Monitor來觀察程序內(nèi)存使用情況:
可以看到,程序所占用的內(nèi)存大概穩(wěn)定在19.45M左右。然后將android_logo.png圖片移動到drawable-mdpi目錄下,重新運行程序,結(jié)果如下圖所示:
現(xiàn)在漲到23.40M了,占用內(nèi)存明顯增加了。如果你將圖片移動到drawable-ldpi目錄下,你會發(fā)現(xiàn)占用內(nèi)存會更高。
通過這個例子同時也驗證了一個問題,我相信有不少比較有經(jīng)驗的Android程序員可能都遇到過這個情況,就是當(dāng)你的項目變得越來越大,有的時候加載一張drawable-hdpi下的圖片,程序就直接OOM崩掉了,但如果將這張圖放到drawable-xhdpi或drawable-xxhdpi下就不會崩掉,其實就是這個道理。
那么經(jīng)過上面一系列的分析,答案自然也就出來了,圖片資源應(yīng)該盡量放在高密度文件夾下,這樣可以節(jié)省圖片的內(nèi)存開支,而UI在設(shè)計圖片的時候也應(yīng)該盡量面向高密度屏幕的設(shè)備來進(jìn)行設(shè)計。就目前來講,最佳放置圖片資源的文件夾就是drawable-xxhdpi。那么有的朋友可能會問了,不是還有更高密度的drawable-xxxhdpi嗎?干嗎不放在這里?這是因為,市面上480dpi到640dpi的設(shè)備實在是太少了,如果針對這種級別的屏幕密度來設(shè)計圖片,圖片在不縮放的情況下本身就已經(jīng)很大了,基本也起不到節(jié)省內(nèi)存開支的作用了。
好的,關(guān)于drawable微技巧方面的探索我們就講到這里,本篇文章中也是集合了不少我平時的工作經(jīng)驗總結(jié),以及通過做試驗所得出的一些結(jié)論,相信還是可以給大家?guī)聿簧賻椭摹?/p>
總結(jié)
以上就是這篇文章的全部內(nèi)容了,希望本文的內(nèi)容對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,謝謝大家對腳本之家的支持。如果你想了解更多相關(guān)內(nèi)容請查看下面相關(guān)鏈接
- 詳解 Android中Libgdx使用ShapeRenderer自定義Actor解決無法接收到Touch事件的問題
- 詳解Android Libgdx中ScrollPane和Actor事件沖突問題的解決辦法
- Android使用libgdx實現(xiàn)模擬方向鍵控制角色移動的方法
- Android 游戲引擎libgdx 資源加載進(jìn)度百分比顯示案例分析
- Android指紋識別API講解,一種更快更好的用戶體驗
- Android在Kotlin中更好地使用LitePal
- Android Studio輕松構(gòu)建自定義模板的步驟記錄
- 詳解Android 檢測權(quán)限的三種寫法
- Android最簡單的狀態(tài)切換布局實現(xiàn)教程
- android自定義環(huán)形對比圖效果
- Libgdx解決部分Android機型鎖屏崩潰的方法
相關(guān)文章
AndroidApk混淆編譯時,報告java.io.IOException...錯誤解決辦法
這篇文章主要介紹了 AndroidApk混淆編譯時,報告Error:Execution failed for task ‘:gviews:transformClassesAndResourcesWithProguardForRelease’.錯誤解決辦法的相關(guān)資料,需要的朋友可以參考下2017-03-03Android應(yīng)用開發(fā)中自定義ViewGroup的究極攻略
這里我們要演示的自定義ViewGroup中將實現(xiàn)多種方式排列和滑動等效果,并且涵蓋子View之間Touch Event的攔截與處理等問題,完全干貨,下面就為大家送上Android應(yīng)用開發(fā)中自定義ViewGroup的究極實例攻略2016-05-05Android實現(xiàn)知乎選項卡動態(tài)隱藏效果實例
選項卡相信對大家來說應(yīng)該不陌生,最近發(fā)現(xiàn)知乎選項卡的動態(tài)隱藏效果不錯,下面這篇文章主要給大家介紹了關(guān)于Android實現(xiàn)知乎選項卡動態(tài)隱藏效果的相關(guān)資料,文中通過示例代碼介紹的非常詳細(xì),需要的朋友可以參考借鑒,下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧。2018-02-02Flutter?WebView?預(yù)加載實現(xiàn)方法(Http?Server)
這篇文章主要介紹了Flutter?WebView?預(yù)加載實現(xiàn)方法,包括資源的配置,資源的下載和存儲,版本的管理,如何根據(jù)實際url獲取對應(yīng)HttpServer?bind的url等,需要的朋友可以參考下2022-05-05Android實現(xiàn)環(huán)形進(jìn)度條代碼
這篇文章主要為大家詳細(xì)介紹了Android實現(xiàn)環(huán)形進(jìn)度條的代碼,具有一定的參考價值,感興趣的小伙伴們可以參考一下2017-01-01解決EditText不顯示光標(biāo)的三種方法(總結(jié))
下面小編就為大家?guī)硪黄鉀QEditText不顯示光標(biāo)的三種方法(總結(jié))。小編覺得挺不錯的,現(xiàn)在就分享給大家,也給大家做個參考。一起跟隨小編過來看看吧2017-04-04android當(dāng)前apn的狀態(tài)以及獲取方法
在絕大多數(shù)android機器etc路徑下存放一個的apns-conf.xml文件,表示當(dāng)前機器使用的apn信息通過root機器可以push出來看看,具體路徑可以上網(wǎng)搜下,接下來介紹獲取apn的狀態(tài)的方法2013-01-01