手機照片的像素一般都遠遠大於手機的屏幕大小。所以爲了節省資源，防止oom異常，我們需要在顯示之前，做一些壓縮處理。不過網上加載圖片的庫有很多，ImageLoder,Glide等，有一篇對它們進行比較的文章，大家有興趣可以看一下：
http://www.trinea.cn/android/android-image-cache-compare/
這篇文章僅僅是壓縮顯示圖片，如果想要運用到項目中，還是推薦大家使用得到大多程序員認可的開源庫，如果想簡單瞭解下原理，可以看下這篇文章，裏面也有講到屏幕dpi的問題。
一、獲取圖片參數
直接獲取Bitmap對象會獲取原圖，這不是我們想要的。BitmapFactory.Options中將 inJustDecodeBounds設置爲true，則會開啓預讀取功能，它的功能是獲取將要讀取的Bitmap空對象，但是這個對象有這個圖片的一系列參數，並且這個時候，我們並沒有真正地加載該圖片，所以不會產生OOM異常。簡單來說：該技術允許你在生成Bitmap對象前對其進行壓縮。
BitmapFactory.Options options = new BitmapFactory.Options();//開啓預加載功能options.inJustDecodeBounds = true;//將要加載的圖片參數傳遞給optionsBitmapFactory.decodeResource(getResources(), R.id.myimage, options);//獲取圖片的參數int imageHeight = options.outHeight;int imageWidth = options.outWidth;String imageType = options.outMimeType;
爲了避免OOM異常，在真正解析圖片之前檢查它的尺寸是非常有必要的。
二、顯示圖片
現在我們有了即將加載的圖片的一系列參數，那我們接下來要做的，就是進行評估：
1、屏幕大小與當前設備的密度
2、呈現這張圖片的控件大小
根據以上條件，我們要最合適地對圖片進行壓縮，爲了告訴解碼器去加載一個縮小版的圖片，我們可以設置BitmapFactory.Options的inSampleSize的值。比如一張2048x2048的圖片，如果將inSampleSize設爲2，則圖片大小就會變爲1024x1024。設爲4，就會變成512x512的，需要注意的是，這個值，必須是平方增長，1、2、4、8、16、24、32、40等，如果不是這些數值，系統也會將你設置的數值四捨五入到最近的數值。細心的人發現了，你提莫在逗我？明明平方增長，怎麼會有24、40呢？沒錯，從16倍之後，每8倍都可以設置一次，而無需遵循平方增長，詳細可查看源碼，我也是在自己的demo中發現，16之後明明是32，結果在24的時候縮小了四分之一，一切都是我一個人在測試，具體縮小多少倍，大家可以根據自己需求，多次運行調試，最後決定。
知道了這個之後，還有一個非常要注意的地方，就是讀取本地的圖片，存放的文件夾。拿Genymotion虛擬機2560x1440,Android6.0爲例，它屏幕的dpi爲xxxhdpi，首先，我將一張640x640的圖片放到了mipmap-mdpi中然後不壓縮將這張圖片加載出來，然後顯示出圖片的寬高，結果是這樣的：
！！！！，等等，怎麼會這麼大，ImageView爲warp_content，最大也應該是640x640呀。
這個就是老話題了：
dpi對應問題
如果不瞭解dpi概念的小夥伴，可以去看下這片文章，如果瞭解的話請無視
http://www.zcool.com.cn/article/ZNjI3NDQ=.html
現在爲把這張圖片放到xxxhdpi文件夾下
然後，加載出來
鐺鐺鐺鐺，就是640x640了，所以加載本地圖片的話一定要注意，還有dpi的影響在，至於dpi的對應表，我簡單寫一下
所有的比例，都是根據mdpi來進行換算，如果高級別的dpi想換算成更高級別的dpi，需要先*(高級別dpi比例/更高級別dpi比例)
| ldpi | mdpi | hdpi | xhdpi | xxhdpi | xxxhdpi | ||||
| 0.75 | 1 | 1.5 | 2 | 3 | 4 | ||||
| dpi範圍 | <120 | 120－159 | 160－239 | 240－320 | 321－479 | 480-640 |
dpi如何計算？根據屏幕分辨率勾股定理算出對角線分辨率長度，然後除以屏幕尺寸。得出的就是dpi了。
好了，至此，屏幕密度的問題，就結束了。接下來就要可以自己考慮控件大小，然後對圖片進行壓縮了。壓縮多少，可根據自己的需求決定。