摘要：對(duì)android 上圖片壓縮，其實(shí)總結(jié)起來基本可以分為兩類壓縮：尺寸壓縮和質(zhì)量壓縮， 尺寸壓縮其實(shí)也可以理解為是對(duì)像素上的壓縮庐完，而質(zhì)量壓縮使我們?cè)诓桓淖兂叽绲那疤嵯聦?duì)圖片壓縮供常。如果沒有理解你可能有疑惑點(diǎn)，這兩種壓縮有什么區(qū)別了？或者說什么時(shí)候用尺寸壓縮 什么時(shí)候用質(zhì)量壓縮。區(qū)別后面提到，而具體什么時(shí)候用什么壓縮耀怜，這個(gè)是要看需求的來決定恢着，判斷標(biāo)準(zhǔn)后面會(huì)給一些建議，僅供參考财破。
一 . 圖片的基本知識(shí)
圖像是由像素組成的掰派，而像素實(shí)際上是帶著坐標(biāo)的位置和顏色信息的。它是有若干行和若干列的點(diǎn)組成的左痢，他們相交就會(huì)有無數(shù)個(gè)點(diǎn)靡羡。假如我們隨便取出一個(gè)點(diǎn)A 那個(gè)這個(gè)點(diǎn)可以表示為
A[m,n] = [blue,green,red]
m和n 就是圖像中的第m行和n列
blue 表示藍(lán)色，是三原色（RGB）的第一個(gè)值
green 表示綠色抖锥，是三原色（RGB）的第二個(gè)值
red 表示紅色亿眠，是三原色（RGB）的第三個(gè)值
1. 分辨率
我們通常說圖片分辨率其實(shí)就是指像素?cái)?shù)，通俗的說是橫向多少個(gè)像素 x 縱向多個(gè)像素 磅废。那什么是像素： 每張圖片是有色點(diǎn)組成的纳像，每個(gè)色點(diǎn)就稱之為像素。比如一張圖片有10萬個(gè)色點(diǎn)構(gòu)成拯勉，那么這個(gè)圖片像素就是 10W竟趾。
我們舉個(gè)例子：一張圖片分辨率為 500x400 ，那么圖片是有橫向 500個(gè)像素宫峦、縱向 400個(gè)像素岔帽，（合計(jì)20000像素點(diǎn)）構(gòu)成。
2. 圖片格式
我們?cè)趯?shí)際項(xiàng)目開開發(fā)中遇到比較多的圖片格式 一般有 .PNG导绷、.JPG犀勒、.JPEG、 .WebP 妥曲、.GIF贾费、.SVG 等等
PNG：它是一種無損數(shù)據(jù)壓縮位圖圖形文件格式。這也就是說PNG 只支持無損壓縮檐盟。對(duì)于PNG 格式是有8 位褂萧、24位、32位的三種形式的葵萎。區(qū)別就是對(duì)透明度的支持导犹。
JPG：其實(shí)就是 JPEG的另一種叫法
JPEG：它是一種有損壓縮的圖片格式
WebP：Google 開發(fā)出的一種支持alpha 通道的有損壓縮。同等質(zhì)量情況下比 JPEG和PNG小 25%~45%.
GIF：它是動(dòng)態(tài)圖片的一種格式羡忘，和PNG 一樣是一種無損壓縮谎痢。
**SVG **: 是一種無損、矢量圖（放大不失真）
就目前來說卷雕，Android 原生支持的格式只有 JPEG节猿、PNG、GIF爽蝴、WEBP（android 4.0 加入）沐批、BMP。而在android層代碼中我們只能調(diào)用的編碼方式只有PNG蝎亚、JPEG九孩、和WEBP 三種。不過目前來說android 還不支持對(duì)GIF 這種的動(dòng)態(tài)編碼发框。
注意 ：我們?nèi)粘Ｋ械?.png躺彬、.jpg、.jpeg 等等指的是圖像數(shù)據(jù)經(jīng)過壓縮編碼后在媒體上的封存形式梅惯，是不能和PNG 宪拥、JPG、JEPG 混為一談的铣减。
我們不是說圖片怎么壓縮的嗎她君？為什么要說圖片格式。因?yàn)樗麄冎g是存在聯(lián)系的葫哗，比如其中 PNG是無損壓縮格式的圖片缔刹，JPEG是有損壓縮格式的圖片，所以對(duì)應(yīng)的也有各自的壓縮算法劣针，比如在android中PNG壓縮使用的就是 libpng 進(jìn)行壓縮的校镐，而JPEG的壓縮是用libjepg（7.0之前） 壓縮的，7.0 之后改為libjpeg-turbo是基于libjepg修改的捺典，而比libjepg更快鸟廓。最大的變化就是相同質(zhì)量的下7.0之后的機(jī)器比7.0之前的機(jī)器壓縮的圖片要小。
二 . Bitmap
對(duì)于開發(fā)android的 小伙伴襟己，對(duì)Bitmap肯定是不陌生的引谜，甚至有的小伙伴被它虐的“體無完膚”。在Android中任何圖片資源的顯示對(duì)象都是通過bitmap 來顯示的（XML資源通Canvas繪制除外）稀蟋。
Bitmap 它是圖像處理中的一個(gè)非常重要對(duì)象煌张。
1.何為bitmap？
我們可以稱之為位圖退客，是一種存儲(chǔ)像素的數(shù)據(jù)結(jié)構(gòu)骏融，通過這個(gè)對(duì)象我們可以獲取到一系列和圖片相關(guān)的屬性， 并且可以對(duì)圖像進(jìn)行處理萌狂，比如切割档玻，放大等等，相關(guān)操作茫藏。
2.bitmap 存儲(chǔ)空間
隨著android系統(tǒng)的不斷升級(jí)误趴，bitmap的存儲(chǔ)空間也在發(fā)生變成，而bitmap 的存儲(chǔ)空間主要有三個(gè)地方：
1）Native Memory
在android 2.3 以下的版本务傲，bitmap像素?cái)?shù)據(jù)是存儲(chǔ)在 Native 空間中凉当，如果需要釋放是要主動(dòng)調(diào)用 recycle()方法
2）Dalvik Heap
在Android 3.0 以上版本枣申，bitmap的像素?cái)?shù)據(jù)存儲(chǔ)在虛擬機(jī)堆中，不需要我們?cè)偃ブ鲃?dòng)調(diào)用recycle()方法看杭，gc會(huì)幫我們?nèi)セ厥铡?/p>
3）Ashmem
很多小伙伴可能不知道這個(gè)是什么忠藤，它是匿名共享存儲(chǔ)空間。我們?cè)趯?shí)際開發(fā)中使用圖片加載庫中楼雹，有一個(gè)庫就是利用這個(gè)一個(gè)空間來進(jìn)行bitmap 對(duì)象的存儲(chǔ)的模孩，他就是大名鼎鼎的Fresco 圖片加載庫。
不過這里需要注意一點(diǎn): 在Android 4.4 以前的版本中 Ashmem 是和App 進(jìn)程空間是隔離的互相不影響贮缅，而在Android 4.4以后的版本中榨咐，Ashmemk空間是包含在App所占用的內(nèi)存空間。
說了這么多我們還是不知道bitmap 在內(nèi)存空間中到底是占用多大的谴供，其實(shí)bitmap 在內(nèi)存空間中所占用的內(nèi)存計(jì)算是這樣的：
pixelWidth x pixelHeight x bytesPerPixel（bitmap 的寬 x 高 x 每個(gè)像素所占的字節(jié)）块茁，所有如果相同的Bitmap對(duì)象， 每個(gè)像素所占用的字節(jié)大小桂肌，決定了這個(gè)bitmap 在內(nèi)存中所占用的內(nèi)存大小龟劲。
上面既然說了，所占用的字節(jié)大小決定bitmap內(nèi)存大小轴或，那么怎么樣能讓每個(gè)像素所占的字節(jié)變小昌跌。在我們Bitmap對(duì)象中有一個(gè)比較重要的枚舉類 Config ，這個(gè)Config 是用來設(shè)置顏色配置信息的照雁。對(duì)于Config配置有四個(gè)變量蚕愤。
Config 配置：
1. alpha_8 ： 占用8位，1個(gè)字節(jié)饺蚊，顏色信息只由透明組成萍诱。
2. argb_4444: 占用16位，2個(gè)字節(jié)污呼，顏色有透明度和R (red)G(green)B(blue)組成裕坊。
3.argb_8888: 占用34位，4個(gè)字節(jié)燕酷，顏色有透明度和R (red)G(green)B(blue)組成籍凝。
這里可能有人會(huì)問為什么 argb_4444和 argb_8888都是 有ARGB組成為什么所占的字節(jié)不同，因?yàn)槊總€(gè)部分所占用的字節(jié)是不同的苗缩，argb_4444每個(gè)部分占用4個(gè)字節(jié)饵蒂，而argb_8888每個(gè)部分占用8位。
4.rgb_565: 占用16位酱讶，2個(gè)字節(jié)退盯，顏色有R (red)G(green)B(blue)組成。
提示：我們通常在操作bitmap 的時(shí)候，是必須要和這個(gè)配置打交道的渊迁，搞明白對(duì)使用bitmap的時(shí)候慰照，提供幫助。特別是防止OOM琉朽，有很大作用焚挠。如果我們平時(shí)對(duì)圖片處理，如多對(duì)圖片的透明度沒特別要求漓骚，比較建議使用 rgb_565 這個(gè)配置，因?yàn)樗推渌鼛讉€(gè)比較榛泛，性價(jià)比最高的蝌蹂。比argb_4444 顯示圖片清晰，argb_8888占用內(nèi)存少一半曹锨，而alpha_8只有透明度孤个，對(duì)圖片沒什么意思。既然我們知道這寫參數(shù)的意義了沛简，我們就可以通過設(shè)置該配置齐鲤，來讓我們bitmap 占用內(nèi)存空間變小。
說了這么多椒楣，那么Bitmap在內(nèi)存究竟占用多少內(nèi)存给郊？使用Android Api的 getByteCount 方法即可。
通過這個(gè)方法捧灰，我們就可以獲取大當(dāng)前運(yùn)行的 bitmap 占用的內(nèi)存淆九。 下面我們舉個(gè)例子吧，看看一張 3000 * 4000 的圖片在不做處理的情況下占用內(nèi)存多大毛俏？
[圖片上傳失敗...(image-54378a-1516619645554)]
從打印出的log 可以看出炭庙，一張 3000x4000的圖，在內(nèi)存中占用了 45M煌寇。 這只是一張如果多張了焕蹄，同時(shí)占用內(nèi)存，很容易OOM了阀溶。因此在對(duì)bitmap 處理的過程中稍有不當(dāng)就會(huì)出現(xiàn)導(dǎo)致程序崩潰腻脏。
三. 壓縮
既然我們知道了，bitmap在內(nèi)存中占用空間 = bitmap 的寬 x 高 x 每個(gè)像素所占的字節(jié)數(shù)银锻。那么Bitmap 壓縮都是圍繞這個(gè)來做文章的迹卢。這里的三個(gè)參數(shù)我們，減少任意一個(gè)的值徒仓，就可能會(huì)達(dá)到了我們壓縮的效果了。
1. 圖片存在的形式
圖片存在大致可以分為三種形式：
file形式 ，我們存在硬盤上的 都是以file 文件的形式存在的症见。
bitmap或 stream 形式喂走，圖片在內(nèi)存中要么以bitmap形式要么已 stream形式存在的。
stream 形式谋作，我們圖片在網(wǎng)絡(luò)傳輸?shù)倪^程中芋肠，都是已stream 形式存在。
那么在android中 圖片文件主要是有png遵蚜，jpg帖池，webP，gif 等幾種類型格式進(jìn)行存儲(chǔ)的吭净。其實(shí)我們圖片壓縮也是在幾個(gè)類型中做處理睡汹。
我們?yōu)槭裁匆f圖片存在的形式，這會(huì)對(duì)我們以后開發(fā)過程中對(duì)圖片處理需要有一定的幫助的寂殉。
2. api
在介紹壓縮之前我們先看下相關(guān)api吧囚巴，讓我們?cè)谑褂玫臅r(shí)候更加方便和選擇合適的pai來做相關(guān)操作。
我們?cè)賹?duì)圖片進(jìn)行相關(guān)操作的時(shí)候友扰，主要涉及的類有 Bitmap彤叉，BitmapFactory，Matrix村怪。等
Bitmap
//將位圖壓縮到指定的outputstream中
boolean compress (Bitmap.CompressFormat format, int quality, OutputStream stream)
// 創(chuàng)建一個(gè)Bitmap 對(duì)象 秽浇，該方法有個(gè)重載函數(shù)
Bitmap createBitmap (Bitmap src)
//根據(jù)新配置 拷貝一份新的bitmap ，第二次參數(shù)的意思 他的像素是否可以修改
//返回的位圖具有與原圖相同的密度和顏色空間
Bitmap copy (Bitmap.Config config, boolean isMutable)
//創(chuàng)建一個(gè)新的bitmap 甚负，根據(jù)傳入的寬和高進(jìn)行縮放兼呵。
Bitmap createScaledBitmap (Bitmap src, int dstWidth, int dstHeight, boolean filter)
// 表示圖片以什么格式的算法進(jìn)行壓縮，壓縮后為何格式
Bitmap.CompressFormat . JPEG / PNG/ WEBP
BitmapFactory
// 根據(jù)文件路徑解碼成位圖
Bitmap decodeFile (String pathName, BitmapFactory.Options opts)
//根據(jù) 留解碼成位圖
Bitmap decodeStream (InputStream is)
//根據(jù) 資源解碼成為位圖
Bitmap decodeResource (Resources res, int id, BitmapFactory.Options opts)
//根據(jù) 數(shù)組解碼成位圖
Bitmap decodeByteArray (byte[] data, int offset, int length, BitmapFactory.Options opts)
// opts.inJustDecodeBounds表示是否將圖片加載到內(nèi)存中 true 不加載但可以獲取圖片的寬高等相關(guān)信息 腊敲，false 加載
這里另外需要注意的是击喂， BitmapFactory 獲取圖片的寬/高和圖片位置相關(guān)信息是和程序運(yùn)行的設(shè)備有關(guān)的。
什么意思：就是將一張圖片放到不同的 drawable 目錄下碰辅，在不同屏幕密度的設(shè)置上運(yùn)行懂昂，獲取到的結(jié)果是不同的，這個(gè)是和android資源加載機(jī)制有關(guān)系的没宾，感興趣的小伙伴可以去研究研究凌彬。
BitmapFactory.Options.inSampleSize
圖片縮放的倍數(shù)，主要這個(gè)只必須大于1循衰，這個(gè)值很重要铲敛，后面說到的尺寸壓縮，就是對(duì)這個(gè)值的計(jì)算会钝，也就是對(duì)原圖進(jìn)行采樣伐蒋，最后放回一個(gè)較小的圖片放到內(nèi)存中的工三。例如 inSampleSize == 2 的時(shí)候返回一個(gè)圖像，那它的寬和高 就是原圖的 1/2 , 像素就是原來的 1/4先鱼。 這里inSampleSize 最終值必須是2的冪俭正，任何其他值都將四舍五入到接近2的冪的值。
BitmapFactory.Options.inPreferredConfig
表示一個(gè)像素需要多大的空間存儲(chǔ)焙畔，設(shè)置解碼器色彩模式 掸读，默認(rèn)模式為ARGB_8888 前面我們說了每個(gè)模式下占的字節(jié)數(shù)，通過改字段控制bitmap 最后在內(nèi)存中占用多大內(nèi)存宏多。不過有點(diǎn)需要注意的是儿惫，就算我們?cè)O(shè)置了別的模式，也有可能還是默認(rèn)模式的伸但。為什么了肾请，官方是這么解釋的 ： 解碼器將嘗試根據(jù)系統(tǒng)的屏幕深度選擇最佳匹配配置，以及原始圖像的特征砌烁，比如它是否具有每個(gè)像素的 alpha值。
Matrix
//對(duì)圖片進(jìn)行旋轉(zhuǎn)
setRotate(float degrees, float px, float py)
//對(duì)圖片進(jìn)行縮放
setScale(float sx, float sy)
//對(duì)圖片進(jìn)行平移
setTranslate(float dx, float dy)
3.圖片壓縮
說了這么多總算說到正題了催式，對(duì)于圖片壓縮按照分類的話函喉，大概可以分為兩類吧，一種為質(zhì)量壓縮荣月，一種為尺寸壓縮管呵。我們這里不管說的是那種壓縮，其實(shí)用的都是 google 在android 中封裝好了的壓縮算法哺窄，我們只是使用封裝好api進(jìn)行講解捐下，和一些我們做壓縮的時(shí)候的一些經(jīng)驗(yàn)吧。
1）質(zhì)量壓縮
何為質(zhì)量壓縮萌业，在文章開頭摘要中就簡(jiǎn)單的介紹了坷襟，這里我們?cè)僭敿?xì)的說下質(zhì)量壓縮，前面提到過生年，質(zhì)量壓縮其實(shí)是不改變?cè)瓐D片的尺寸的前提下改變圖片的透明度和位深婴程，原圖尺寸不改變，像素自然也是沒有改變的抱婉。隨著他壓縮圖片文件大小變小档叔，可是在bitmap內(nèi)存中占用的內(nèi)存是不會(huì)改變的和原圖相比。它雖然沒有改變圖片的像素蒸绩，可是它壓縮了圖片中每個(gè)像素的質(zhì)量衙四，這樣就會(huì)出現(xiàn)，如果質(zhì)量比較低患亿，那么這個(gè)圖片就會(huì)變得非常模糊传蹈，色彩失真很嚴(yán)重的。我在開發(fā)中對(duì)圖片壓縮的時(shí)候，一個(gè)壓縮好的bitmap對(duì)象卡睦，在寫入文件的時(shí)候宴胧，因?yàn)槲以O(shè)置圖片CompressFormat 屬性為 Bitmap.CompressFormat.PNG，結(jié)果寫入到文件中的圖片體積比原圖還大表锻。這里一定要注意的就是恕齐，png格式的圖片是不適合質(zhì)量壓縮的，不管你壓縮質(zhì)量多低瞬逊，內(nèi)部壓縮算法根本是不會(huì)對(duì)其進(jìn)行壓縮的显歧，為什么? 我們前面在說圖片格式的時(shí)候說過，png 圖片是一種無損的圖片壓縮格式确镊，這也是為什么在說圖片壓縮之前士骤，對(duì)圖片的一些基本知識(shí)做個(gè)簡(jiǎn)單介紹。在需求上蕾域，這種壓縮非常不適合做縮略圖拷肌，也不適合想通過壓縮圖片來減小對(duì)內(nèi)存的使用。個(gè)人認(rèn)為這個(gè)只適合旨巷，既想保證圖片的尺寸或像素巨缘，而同時(shí)又希望減小文件大小的需求而已。說了這么多采呐，那么在android中質(zhì)量壓縮通過什么api來實(shí)現(xiàn)的了若锁，其實(shí)google 一下這種代碼滿屏都是的，為了減少看到這個(gè)文章的小伙伴去查閱代碼的時(shí)間斧吐，就貼上一小段代碼吧：
2）尺寸壓縮
尺寸壓縮 其實(shí)就是針對(duì)圖片的尺寸進(jìn)行修改又固，這個(gè)過程就是一個(gè)圖片重新采樣。在android 中圖片重采樣是提供了兩種方法的煤率，一種是臨近采樣仰冠，也是我們比較熟悉，通過改變 inSampSize 值蝶糯，也叫這采樣率壓縮沪停。第二種叫做雙線性采樣。前面我們?cè)诮榻BApi是時(shí)候?qū)@個(gè)字段進(jìn)行詳細(xì)介紹了裳涛。這個(gè)方法也是android 開發(fā)小伙伴人人皆知的辦法了木张，還有很多比較出名的壓縮庫都說是通過該方法來做的。其實(shí)我個(gè)人認(rèn)為端三，采樣壓縮其實(shí)是比較粗暴的舷礼。
1. 臨近采樣，這個(gè)方式是比較粗暴的郊闯，它是直接選中其中的一個(gè)像素作為生成的像素妻献，它采用的算法叫做臨近點(diǎn)插值算法蛛株，它是圖像縮放算法∮Γ可能還有小伙伴不明白谨履，舉個(gè)例子：
假設(shè)我們有張圖片，他的像素是這樣的
綠 黃 綠 黃
綠 黃 綠 黃
綠 黃 綠 黃
綠 黃 綠 黃
這樣的圖片是一個(gè)綠色的像素隔著一個(gè)黃色的像素熬丧，官方給我的解釋是 x （x為2的倍數(shù)）個(gè)像素最后對(duì)應(yīng)一個(gè)像素笋粟，由于采樣率設(shè)置為1/2,所以是兩個(gè)像素生成一個(gè)像素，另一個(gè)自己就被拋棄了析蝴，如果只選擇綠色害捕，黃色被拋棄，造成圖片只有一種顏色綠色了闷畸。
那到底怎么樣獲取采樣率了尝盼？
將BitmapFactory.Options的inJustDecodeBounds參數(shù)設(shè)置為true并加載圖片
從BitmapFactory.Options取出圖片的原始寬高信息, 他們對(duì)應(yīng)于outWidth和outHeight參數(shù)
根據(jù)采樣率的規(guī)則并結(jié)合目標(biāo)View的所需大小計(jì)算出采樣率inSampleSize
將BitmapFactory.Options的inJustDecodeBounds參數(shù)設(shè)為false, 然后重新加載.
通過以上的四個(gè)步驟，我們最終獲取到一個(gè)最接近我們想要的圖片佑菩。在上面步驟中最重要的就是計(jì)算 inSampleSize的值盾沫，我們下官方推薦我們的計(jì)算做法是怎么寫的，看代碼：
這個(gè)就不做過多解釋了殿漠，應(yīng)該都能看得懂的赴精，很簡(jiǎn)單，就是根據(jù)需要的寬和高凸舵，和圖片的原始寬和高祖娘，一直循環(huán)算出一個(gè)合適的 inSampleSize 的值失尖。
2. 雙線性采樣
雙線性采樣使用的是雙線性內(nèi)插算法啊奄，這個(gè)算法不像臨近采樣那樣粗暴，它是參考了源像素對(duì)應(yīng)的位置周圍 2*2個(gè)點(diǎn)的值根據(jù)相對(duì)位置取對(duì)應(yīng)的權(quán)重掀潮，經(jīng)過計(jì)算之后得到目標(biāo)圖像菇夸。
雙線性采樣在android使用方式 一般有兩種，我們看實(shí)現(xiàn)代碼：
其實(shí)第一種仪吧，在最終也是使用了第二種方式的 matrix 進(jìn)行縮放的庄新。我們發(fā)現(xiàn) createScaledBitmap 函數(shù)的源碼中
還是使用matrix進(jìn)行縮放的
上面兩種也是android中圖片尺寸壓縮中最常見的兩種方法了。對(duì)臨近采樣它的方式是最快的薯鼠，因?yàn)槲覀冋f過它是直接選擇其中一個(gè)像素作為生成像素择诈，生成的圖片可能會(huì)相對(duì)比較失真，壓縮的太厲害會(huì)產(chǎn)生明顯的鋸齒出皇。而雙線性采樣相對(duì)來說失真就沒有這樣嚴(yán)重羞芍。這里可能有小伙伴就要問了，既然雙線性采樣比臨近采樣要好郊艘。為什么很多壓縮框架都是采用臨近采樣來做的荷科？問的好唯咬，我也查閱過相關(guān)資料和官方文檔，可惜沒有找到比較有權(quán)威的說法來證明這點(diǎn)畏浆。我說說我對(duì)這個(gè)觀點(diǎn)的看法吧胆胰，如果我們要是使用雙線性采樣對(duì)圖片尺寸壓縮的話，不管是采用第一種還是第二種刻获，我們都必須要有個(gè)bitmap對(duì)象蜀涨，而再拿到這個(gè)bitmap對(duì)象的時(shí)候，我們是要寫入到內(nèi)存中的将鸵，而如果圖片太大的話勉盅，在decode的時(shí)候，程序就已經(jīng)OOM了顶掉，特別是處理大圖的時(shí)候草娜，這個(gè)方法肯定是不合適的。而臨近采樣是可以在圖片不decode到內(nèi)存的情況下痒筒，對(duì)圖片進(jìn)行壓縮處理宰闰，最后獲取到的bitmap 是很小的，基本不會(huì)導(dǎo)致OOM的簿透。
- LibJpeg壓縮
通過Ndk調(diào)用LibJpeg庫進(jìn)行壓縮移袍，保留原有的像素，清晰度老充。這個(gè)庫廣泛的使用在開源的圖片壓縮上的葡盗。
4.壓縮策略
其實(shí)對(duì)于壓縮策略束世，我認(rèn)為無法肯定的說一定是1统舀，或者2。它其實(shí)是看需求的骡苞，根據(jù)需求來定一個(gè)合理的壓縮策略巷嚣。我個(gè)人認(rèn)為網(wǎng)上的 luban 壓縮庫喘先，他的策略在某種程度上還算比較具有通用性的，適合大部分需求吧廷粒。對(duì)應(yīng) luban的壓縮 算法窘拯，我這里簡(jiǎn)單的介紹下，他是將圖片的比例值（短邊除以長邊）分為了三個(gè)區(qū)間值：
[1, 0.5625) 即圖片處于 [1:1 ~ 9:16) 比例范圍內(nèi)
[0.5625, 0.5) 即圖片處于 [9:16 ~ 1:2) 比例范圍內(nèi)
[0.5, 0) 即圖片處于 [1:2 ~ 1:∞) 比例范圍內(nèi)
然后再去判斷圖片的最長的邊是否超過這個(gè)區(qū)間的邊界值坝茎，然后再去計(jì)算這個(gè)臨近采樣的 inSampleSize的值涤姊。如果想要具體的了解這個(gè)策略，去github 上下載源碼去研究研究嗤放，代碼還是很簡(jiǎn)單的思喊。在實(shí)際的開發(fā)的過程中我們可以根據(jù)我們需求，結(jié)合上面幾種壓縮機(jī)制斤吐，自己制定一個(gè)比較適合自己的壓縮策略搔涝。不過一般情況都不需要我們自己制定圖片的壓縮策略厨喂，采樣壓縮 ，基本已經(jīng)滿足我們的需求的
