LruCache（Least Recently Used Cache） 全稱最近最少使用算法等太，其主要思想是使用SoftReference（或者WeakReference），因為我們的緩存容量是有限的甘桑，它會面臨一個問題：當有新的內容需要加入我們的緩存，但我們的緩存空閑的空間不足以放進新的內容時歹叮，我們就需要舍棄原有的部分內容從而騰出空間用來放新的內容跑杭。

在LruCache 中，我們使用url做key咆耿，bitmap做value德谅，利用軟引用的特性（在內存將滿的時候會被垃圾回收器回收，如果還有可用內存票灰，垃圾回收器不會）及時的回收內存女阀，這種方式能夠及時有效回收圖片所占用的內存宅荤，但這些方法并未完全解決單個圖片占用內存過大的問題屑迂，在程序運行的過程中，圖片該多大還多大冯键。我們只是控制在內存中存在圖片對象的個數(shù)而已惹盼。

與Lru相似的還有Lfu，前者是最近最少使用惫确，即淘汰最長時間未使用的對象手报；后者是最近最不常使用，即淘汰一段時間內使用最少的對象改化。比如我們緩存對象的順序是：A B C B D A C A 掩蛤，當需要淘汰一個對象時，如果采用LRU算法陈肛，則淘汰的是B揍鸟，因為它是最長時間未被使用的。如果采用LFU算法句旱，則淘汰的是D阳藻，因為在這段時間內它只被使用了一次晰奖，是最不經(jīng)常使用的。

注意：對于SoftReference(軟引用)或者WeakReference(弱引用)的Bitmap緩存方案腥泥，現(xiàn)在已經(jīng)不推薦使用了匾南。自Android2.3版本(API Level 9)開始，垃圾回收器更著重于對軟/弱引用的回收蛔外。

與此種方法類似蛆楞，我們可以使用硬盤緩存（DiskLruCache）來進行圖片的管理，這種方法比LruCache 節(jié)省內存夹厌，但讀取速度較慢（硬盤的讀取速度是未知的）臊岸。

2. 按照一定規(guī)則壓縮圖片（以android為例）

Android中圖片是以bitmap形式存在的，那么bitmap所占內存尊流，直接影響到了應用所占內存大小帅戒。

bitmap所占內存大小計算方式：

圖片長度 x 圖片寬度 x 一個像素點占用的字節(jié)數(shù)

以下是圖片的壓縮格式：


其中，A代表透明度崖技；R代表紅色逻住；G代表綠色；B代表藍色迎献。

ALPHA_8

表示8位Alpha位圖,即A=8,一個像素點占用1個字節(jié),它沒有顏色,只有透明度

ARGB_4444

表示16位ARGB位圖瞎访，即A=4,R=4,G=4,B=4,一個像素點占4+4+4+4=16位，2個字節(jié)

ARGB_8888

表示32位ARGB位圖吁恍，即A=8,R=8,G=8,B=8,一個像素點占8+8+8+8=32位扒秸，4個字節(jié)

RGB_565

表示16位RGB位圖,即R=5,G=6,B=5,它沒有透明度,一個像素點占5+6+5=16位，2個字節(jié)

2.1 質量壓縮（android sdk 提供）

ByteArrayOutputStream baos =newByteArrayOutputStream();//內存流bitmapOld.compress(CompressFormat.JPEG, quality, baos);//quality為壓縮百分比//quality=50冀瓦，意為壓縮為1/2byte[] bytes = baos.toByteArray();bitmapNew= BitmapFactory.decodeByteArray(bytes,0, bytes.length);//生成圖片對象

通過此種方式伴奥，圖片的大小是沒有變的，因為質量壓縮不會減少圖片的像素翼闽，它是在保持像素的前提下改變圖片的位深及透明度等拾徙，來達到壓縮圖片的目的，這也是為什么該方法叫質量壓縮方法感局。圖片的長尼啡，寬，像素都不變询微，那么bitmap所占內存大小是不會變的崖瞭。

但是bytes.length是隨著quality變小而變小的。這樣適合去傳遞二進制的圖片數(shù)據(jù)撑毛，比如微信分享圖片书聚，要傳入二進制數(shù)據(jù)過去，限制32kb之內。

如果是bit.compress(CompressFormat.PNG, quality, baos);這樣的png格式寺惫，quality就沒有作用了疹吃，bytes.length也不會變化，因為png圖片是無損的西雀，不能進行壓縮萨驶。

2.2 采樣率壓縮（android sdk 提供）

BitmapFactory.Optionsoptions = new BitmapFactory.Options();options.inSampleSize=2;? ? //inSampleSize 為壓縮比? ? ? ? 此處為1/2bm = BitmapFactory.decodeFile(Environment.getExternalStorageDirectory().getAbsolutePath()+"/DCIM/Camera/test.jpg", options);

設置inSampleSize的值(int類型)后，假如設為2艇肴，則寬和高都為原來的1/2腔呜，寬高都減少了，圖片總像素就減少了再悼，自然內存也降低了核畴。

Glide默認加載圖片時是通過將圖片轉換成ImageView的大小后再加載。

Picasso默認是加載了全尺寸的圖片到內存冲九，然后讓GPU來實時重繪大邪荨（也可以手動設置或者將scaletype設置成? centerCrop等）。

2.3 縮放法壓縮（martix莺奸，android sdk 提供）

Matrix matrix = new Matrix();matrix.setScale(0.5f,0.5f);bm = Bitmap.createBitmap(bit,0,0, bit.getWidth(),bit.getHeight(), matrix, true);

通過上述代碼丑孩，bitmap的長度和寬度分別縮小了一半，圖片大小縮小了四分之一灭贷。

2.4 RGB_565法

BitmapFactory.Optionsoptions = new BitmapFactory.Options();options.inPreferredConfig= Bitmap.Config.RGB_565;? //將格式設置成RGB_565bm = BitmapFactory.decodeFile(Environment.getExternalStorageDirectory().getAbsolutePath()? ? ? ? ? ? ? ? ? ? +"/DCIM/Camera/test.jpg", options);

經(jīng)過此種方式温学，圖片大小直接縮小了一半，長度和寬度也沒有變甚疟，相比argb_8888減少了一半的內存仗岖。

注意：由于ARGB_4444的畫質慘不忍睹，一般假如對圖片沒有透明度要求的話览妖，可以改成RGB_565轧拄，相比ARGB_8888將節(jié)省一半的內存開銷。

Glide默認的Bitmap格式就是RGB_565

Picasso是ARGB_8888

2.5 createScaledBitmap

bitmapNew=Bitmap.createScaledBitmap(bitmapOld,150,150,true);

這里是將圖片壓縮成我們所期望的長度和寬度（150黄痪，150）紧帕。?

圖片的內存大小相應也發(fā)生了改變盔然。

但是這里要說桅打，如果用戶期望的長度和寬度和原圖長度寬度相差太多的話，圖片會很不清晰愈案。

android 中 Bitmap壓縮都是圍繞這個來做文章：Bitmap所占用的內存 = 圖片長度 x 圖片寬度 x 一個像素點占用的字節(jié)數(shù)挺尾。3個參數(shù)，任意減少一個的值站绪，就達到了壓縮的效果遭铺。

2.6 Bitmap.recycle() 用于不再使用的圖片對象的處理

該方法不是真正降低圖片內存的方法。主要目的是標記圖片對象，方便回收圖片對象的本地數(shù)據(jù)魂挂。

圖片對象的本地數(shù)據(jù)占用的內存最大甫题，而且與程序Java部分的內存是分開計算的。所以經(jīng)常出現(xiàn)Java heap足夠使用涂召，而圖片發(fā)生OutOfMemoryError的情況坠非。在圖片不使用時調用該方法，可以有效降低圖片本地數(shù)據(jù)的峰值果正，從而減少OutOfMemoryError的概率炎码。不過調用了recycle()的圖片對象處于“廢棄”狀態(tài)，調用時會造成程序錯誤秋泳。所以在無法保證該圖片對象絕對不會被再次調用的情況下潦闲，不建議使用該方法。

特別要注意已經(jīng)用setImageBitmap(Bitmap img)方法分配給控件的圖片對象（意為img存在其他地方的引用）迫皱，可能會被系統(tǒng)類庫調用歉闰，造成程序錯誤。

3.處理美工給的UI圖 tinypng（網(wǎng)站）

一個很好的批處理壓縮圖片文件的網(wǎng)站（工具）卓起，可將圖片壓縮至70%左右新娜。?

網(wǎng)站鏈接：https://tinypng.com

但這種方式只能處理美工給的切圖，不能處理來自服務器的圖片文件既绩。

4.webP圖片格式（android概龄，ios均適用）

WebP圖片格式，由谷歌于2010年推出的新一代圖片格式饲握，在壓縮方面比當前JPEG格式更優(yōu)越私杜。圖片壓縮體積大約只有JPEG的2/3，并能節(jié)省大量的服務器帶寬資源和數(shù)據(jù)空間救欧。Facebook Ebay等知名網(wǎng)站已經(jīng)開始測試并使用WebP格式衰粹。

但WebP是一種有損壓縮。相較編碼JPEG文件笆怠，編碼同樣質量的WebP文件需要占用更多的計算資源铝耻。

谷歌表示，這種格式的主要優(yōu)勢在于高效率蹬刷。他們發(fā)現(xiàn)瓢捉，“在質量相同的情況下，WebP格式圖像的體積要比JPEG格式圖像小40%办成。谷歌瀏覽器已經(jīng)支持webp格式泡态，Opera在版本號Opera11.10后也增加了支持，然而火狐和ie暫時還不支持webp格式迂卢，可以采用flash插件來顯示webp某弦，當然這樣會耗費一些性能桐汤。

美中不足的是，WebP格式圖像的編碼時間“比JPEG格式圖像長8倍”（占用cpu靶壮，節(jié)省內存）怔毛。

分析人士認為，盡管WebP格式尚未像JPEG格式那樣腾降，得到各種軟硬件的廣泛支持馆截，但谷歌推廣這一格式的優(yōu)勢在于Chrome瀏覽器。這款谷歌開發(fā)的瀏覽器的市場份額已達10%以上蜂莉。

桌面版Chrome可打開WebP格式蜡娶。

常用的webp轉換工具有：XnConvet，智圖映穗，ISparta窖张，集成方法請自行百度。

http://www.bkjia.com/Androidjc/1019610.html

5 .圖片上傳 （推薦使用luban from github）

一款仿微信的圖片壓縮庫,一般用作上傳圖片的壓縮?

?感謝：http://blog.csdn.net/qq564045867/article/details/53666893

相關：http://www.reibang.com/p/1759364ca8b6