采用錘子T1手機(1080*1960，xxhdpi)進行測試
對于內存的查看，使用AS自帶的內存查看工具。
圖片大小使用如下代碼獲取
privatevoidprintBitmapSize(ImageView imageView) {? ? ? ? Drawable drawable=imageView.getDrawable();if(drawable!=null) {? ? ? ? ? ? BitmapDrawable bitmapDrawable=(BitmapDrawable) drawable;? ? ? ? ? ? Bitmap bitmap=bitmapDrawable.getBitmap();Log.d(TAG," width = "+bitmap.getWidth()+" height = "+bitmap.getHeight());? ? ? ? }else{Log.d(TAG,"Drawable is null !");? ? ? ? }? ? }
下面將給出測試的過程的截圖，然后進行分析和總結
下面的測試使用的是一張720*1280分辨率的png圖片，32位色，占用硬盤大小為77.11k
下面給出測試工程代碼，非常簡單
主界面
publicclassMainActivityextendsAppCompatActivity{privatestaticfinalString TAG ="MainActivity";privateImageView img;@OverrideprotectedvoidonCreate(Bundle savedInstanceState) {super.onCreate(savedInstanceState);? ? ? ? setContentView(R.layout.activity_main);? ? ? ? img = (ImageView) findViewById(R.id.img);? ? }@OverridepublicvoidonWindowFocusChanged(booleanhasFocus) {super.onWindowFocusChanged(hasFocus);? ? ? ? printBitmapSize(img);? ? }privatevoidprintBitmapSize(ImageView imageView) {? ? ? ? Drawable drawable = imageView.getDrawable();if(drawable !=null) {? ? ? ? ? ? BitmapDrawable bitmapDrawable = (BitmapDrawable) drawable;? ? ? ? ? ? Bitmap bitmap = bitmapDrawable.getBitmap();? ? ? ? ? ? Log.d(TAG," width = "+ bitmap.getWidth() +" height = "+ bitmap.getHeight());? ? ? ? }else{? ? ? ? ? ? Log.d(TAG,"Drawable is null !");? ? ? ? }? ? }}
布局界面
在不設置圖片的情況下，App占用內存8.31M
以下為測試部分
把圖片放置在drawable文件夾下，圖片大小為2160 * 3840，內存占用39.88M
把圖片放置在drawable-mdpi文件夾下，圖片大小為2160 * 3840，內存占用39.84M
把圖片放置在drawable-hdpi文件夾下，圖片大小為1440 * 2560，內存占用22.26M
把圖片放置在drawable-xhdpi文件夾下，圖片大小為1080 * 1920，內存占用16.11M
把圖片放置在drawable-xxhdpi文件夾下，圖片大小為720 * 1280，內存占用11.86M
把圖片放置在drawable-xxxhdpi文件夾下，圖片大小為540 * 960，內存占用10.29M
從上面的測試結果，我們可以得出如下結論：
同一張圖片，放在不同目錄下，會生成不同大小的Bitmap
Bitmap的長度和寬度越大，占用的內存就越大
圖片在硬盤上占用的大小，與在內存中占用的大小完全不一樣
下面我會對上面幾個問題一一解釋。
我們以放在drawable文件夾下面的圖片為例，加載到內存之后，2160*3840大小的Bitmap占用的內存為
2160 * 3840 * 4 = 3317,7600 byte = 3,2400kb = 31.640625 M
所以drawable文件夾下的App內存占用 = 原始內存8.31M+圖片內存31.64M= 39.95M ，與實際內存占用39.88M存在0.1755%的誤差，在誤差范圍之內。
先簡單解釋一下上面的計算公式，長*寬是圖片的像素總數，乘以4則是因為一個像素占用A、R、G、B四個通道，每個通道占用8位，所以描述一個像素需要32位即4個字節。
一個顏色通道需要8位描述，2^8=256，所以每個顏色通道就有256種狀態。如果把彩色圖轉化成灰階圖的話，也有256種狀態分割從白色到黑色之間的過渡顏色。
當然，也并不是所有格式的圖片每個像素占用4字節，這和圖片在加載時設置的Bitmap.Config有關，默認的是Bitmap.Config.ARGB_8888，其他類型如下：
Bitmap.Config.ALPHA_8 此時圖片只有alpha值，沒有RGB值，
一1個像素占用一個字節
Bitmap.Config.ARGB_4444 一個像素占用2個字節，alpha(A)值，Red（R）值，Green(G)值，Blue（B）值各占4個bites共16bites,即2個字節
Bitmap.Config.ARGB_8888 一個像素占用4個字節，alpha(A)值，Red（R）值，Green(G)值，Blue（B）值各占8個bites，共32bites,即4個字節。這是一種高質量的圖片格式，在電腦上普通采用。它也是Android手機上一個Bitmap的默認格式。
Bitmap.Config.RGB_565 一個像素占用2個字節，沒有alpha(A)值，即不支持透明和半透明，Red（R）值占5個bites ，Green(G)值占6個bites ，Blue（B）值占5個bites,共16bites,即2個字節。對于沒有透明和半透明顏色的圖片來說，該格式的圖片能夠達到比較的呈現效果，相對于ARGB_8888來說也能減少一半的內存開銷。因此它是一個不錯的選擇。
那么為啥在硬盤上存儲只需要77.11k，放到內存里面就需要30多M呢？
因為這根本不是一回事呀~
存放在硬盤上的圖片文件，會根據各自的壓縮規則進行壓縮，比如Jpeg這種有損壓縮的圖片格式，最常使用可變字長編碼的哈弗曼編碼，會使用哈弗曼樹，也就是最優二叉樹，根據某些數據出現的頻率對數據段編碼，從而減少占用的硬盤大小。
比如說“10111”這個序列在圖片的二進制數據中出現的概率最大，那我們可以用“01”來代替這一段數據，原來5位的數據，用2位就可以表示了，這就是壓縮率60%。當然這只是打個比方，在實際操作中需要考慮“異前綴原則”等編碼的基本原則。
而如果把圖像讀取到內存中就不一樣了，因為我們需要每一個像素都能在屏幕上顯示，所以會把每個像素點都加載至內存中，不會對相同像素進行壓縮或者是替換，所以你也應該能明白前面提到的Bitmap占用內存大小的計算公式的由來了。
說到這里，其實后兩個結論已經解釋清楚了，那么為什么“同一張圖片，放在不同目錄下，會生成不同大小的Bitmap”呢？
如果你真的看懂了我之前寫的文章，那么這個問題應該不算問題。
我的測試設備為錘子T1，1080*1960，xxhdpi，所以說，如果把這張放置在xxhdpi的話，應該不會對圖像進行放縮，也就是原始大小，所以我們在前面得到drawable-xxhdpi文件夾下，圖片大小為720 * 1280是完全可以理解的，就是圖片本身的大小。
當圖片放置在drawable-hdpi中時，圖片大小為1440 * 2560，長寬變為原來的兩倍，這是因為不同分辨率之間的倍數關系導致的，來一張圖
我們可以很明顯的看到xxhdpi是hdpi的2倍，所以如果單獨放置在某個drawable文件夾，手機會自動根據當前的屏幕密度對圖片進行放縮。
比如上面，當把圖片放置在xxxhdpi里面的時候，在xxhdpi的設備上，圖片長 = 720 * (3/4) = 540，圖片寬 = 1280 * (3/4) = 960，這與上面的測試結果是完全一致的。
至于為什么在前面的測試中，drawable和drawable-mdpi是一樣的大小，是因為drawable-mdpi是系統默認的像素密度，其他像素密度都以它為基數，當只在drawable中存在圖片時，如果使用該圖片，那么將按照drawable-mdpi的放縮比例進行放縮。
從上面的測試我們可以得出以下幾個結論：
當圖片放置在不同drawable文件夾中，且只有這一張圖片時，運行設備會根據自身的屏幕密度，對圖片進行放縮，放縮比例符合前面圖上的規則
圖片文件的大小與在內存中占用的大小沒關系，內存中實際占用大小與圖片分辨率、像素顯示參數有關
所以，在一個App里面使用一套UI理論上應該是沒有問題的，但是要注意
最好使用較高分辨率的切圖，并且放置在正確的drawable文件夾中，比如按照xxhdpi的分辨率進行切圖，放置在drawable-xxhdpi中
對于可以使用.9格式的圖片，最好使用.9，減少資源大小
如果有條件，最好提供多套UI切圖。如果只有一套切圖，系統需要對圖片進行壓縮，會進行大量運算，影響設備性能。同時，在某些情況下，系統對圖片的壓縮會可能會出現鋸齒，造成信息的丟失
如果是多套切圖的話，最好不要直接用工具按照比例放縮，這樣小圖標會丟失一些細節。當然，這部分是美工來做的，可以讓她參考這篇文章利用PS CS6的新功能保持ICON細節飽滿完美
思考一下，如果把一個本來應該放在drawable-xxhdpi里面的圖片放在了drawable文件夾中會出現什么問題呢？
在xxhdpi設備上，圖片會被放大3倍，圖片內存占用就會變為原來的9倍！
http://blog.csdn.net/zhaokaiqiang1992/article/details/49787117
