android圖片采樣

A. Android性能優化總結

常用的Android性能優化方法：

一、布局優化：

1）盡量減少布局文件的層級。

層級少了，繪制的工作量也就少了，性能自然提高。

2）布局重用 <include標簽>

3）按需載入：使用ViewStub,它繼承自View,一種輕量級控制項，本身不參與任何的布局和繪制過程。他的layout參數里添加一個替換的布局文件，當它通過setVisibility或者inflate方法載入後，它就會被內部布局替換掉。

二、繪制優化：

基於onDraw會被調用多次，該方法內要避免兩類操作：

1）創建新的局部對象，導致大量垃圾對象的產生，從而導致頻繁的gc，降低程序的執行效率。

2）不要做耗時操作，搶CPU時間片，造成繪制很卡不流暢。

三、內存泄漏優化：

1）靜態變數導致內存泄漏   比較明顯

2）單例模式導致的內存泄漏 單例無法被垃圾回收，它持有的任何對象的引用都會導致該對象不會被gc。

3）屬性動畫導致內存泄漏  無限循環動畫，在activity中播放，但是onDestroy時沒有停止的話，動畫會一直播放下去，view被動畫持有，activity又被view持有，導致activity無法被回收。

四、響應速度優化：

1）避免在主線程做耗時操作 包括四大組件，因為四大組件都是運行在主線程的。

2）把一些創建大量對象等的初始化工作放在頁面回到前台之後，而不應該放到創建的時候。

五、ListView的優化：

1）使用convertView，走listView子View回收的一套：RecycleBin 機制

主要是維護了兩個數組，一個是mActiveViews,當前可見的view,一個是mScrapViews，當前不可見的view。當觸摸ListView並向上滑動時，ListView上部的一些OnScreen的View位置上移，並移除了ListView的屏幕范圍，此時這些OnScreen的View就變得不可見了，不可見的View叫做OffScreen的View，即這些View已經不在屏幕可見范圍內了，也可以叫做ScrapView，Scrap表示廢棄的意思，ScrapView的意思是這些OffScreen的View不再處於可以交互的Active狀態了。ListView會把那些ScrapView（即OffScreen的View）刪除，這樣就不用繪制這些本來就不可見的View了，同時，ListView會把這些刪除的ScrapView放入到RecycleBin中存起來，就像把暫時無用的資源放到回收站一樣。

當ListView的底部需要顯示新的View的時候，會從RecycleBin中取出一個ScrapView，將其作為convertView參數傳遞給Adapter的getView方法，從而達到View復用的目的，這樣就不必在Adapter的getView方法中執行LayoutInflater.inflate()方法了。

RecycleBin中有兩個重要的View數組，分別是mActiveViews和mScrapViews。這兩個數組中所存儲的View都是用來復用的，只不過mActiveViews中存儲的是OnScreen的View，這些View很有可能被直接復用；而mScrapViews中存儲的是OffScreen的View，這些View主要是用來間接復用的。

2）使用ViewHolder避免重復地findViewById

3)快速滑動不適合做大量非同步任務，結合滑動監聽，等滑動結束之後載入當前顯示在屏幕范圍的內容。

4）getView中避免做耗時操作，主要針對圖片：ImageLoader來處理(原理：三級緩存)

5）對於一個列表，如果刷新數據只是某一個item的數據，可以使用局部刷新，在列表數據量比較大的情況下，節省不少性能開銷。

六、Bitmap優化：

1）減少內存開支：圖片過大，超過控制項需要的大小的情況下，不要直接載入原圖，而是對圖片進行尺寸壓縮，方式是BitmapFactroy.Options 采樣，inSampleSize 轉成需要的尺寸的圖片。

2）減少流量開銷：對圖片進行質量壓縮，再上傳伺服器。圖片有三種存在形式：硬碟上時是file，網路傳輸時是stream，內存中是stream或bitmap，所謂的質量壓縮，它其實只能實現對file的影響，你可以把一個file轉成bitmap再轉成file，或者直接將一個bitmap轉成file時，這個最終的file是被壓縮過的，但是中間的bitmap並沒有被壓縮。bitmap.compress(Bitmap.CompressFormat.PNG,100,bos);

七、線程優化：

使用線程池。為什麼要用線程池？

1、從「為每個任務分配一個線程」轉換到「在線程池中執行任務」

2、通過重用現有的線程而不是創建新線程，可以處理多個請求在創建銷毀過程中產生的巨大開銷

3、當使用線程池時，在請求到來時間 ，不用等待系統重新創建新的線程，而是直接復用線程池中的線程，這樣可以提高響應性。

4、通過和適當調整線程池的大小 ，可以創建足夠多的線程以使處理器能夠保持忙碌狀態，同時還可以防止過多線程相互競爭資源而使應用程序耗盡內存或者失敗。

5、一個App裡面所有的任務都放在線程池中執行後，可以統一管理 ，當應用退出時，可以把程序中所有的線程統一關閉，避免了內存和CPU的消耗。

6、如果這個任務是一個循環調度任務，你則必須在這個界面onDetach方法把這個任務給cancel掉，如果是一個普通任務則可cancel，可不cancel，但是最好cancel

7、整個APP的總開關會在應用退出的時間把整個線程池全部關閉。

八、一些性能優化建議：

1）避免創建過多對象，造成頻繁的gc

2)不要過多使用枚舉，枚舉佔用的空間比整型大很多

3）字元串的拼接使用StringBuffer、StringBuilder來替代直接使用String,因為使用String會創建多個String對象，參考第一條。

4）適當使用軟引用，（弱引用就不太推薦了）

5）使用內存緩存和磁碟緩存。

B. 怎麼查安卓手機最高采樣頻率

查安卓手機最高采樣頻率模團步稿扒驟如下。
1、直接使用adb命令後觸摸屏幕。
2、使用MT管鍵碼昌理器，新建文件命名為查看觸控采樣率即可。

C. 請問android怎樣通過json數據從伺服器獲取圖片

直接獲取是不行的，要有一個文件伺服器，對於文件伺服器會為每個圖片生成一個資源路徑，然後json數據中返回的就是這個資源路徑，最後用URL類就可以通過這個資源路徑把圖片download下來

D. Android 圖片載入（一）高效載入Bitmap 基礎篇

由於Bitmap的特殊性以及Android對單個應用所規定的最大內存限制，我們在同時載入大量Bitmap時很容易發生內存溢出，即我們通常所說的OutOfMemoryError（OOM），因此高效載入Bitmap就成為了每個Android開發者的必備技能。

在學習如何高效地載入Bitmap之前，首先介紹一下如何載入一個Bitmap。我們都知道，Bitmap在Android中通常指的是一張圖片，那麼如何將JPG、PNG等格式的圖片轉換成Bitmap對象呢？BitmapFactory類給我們提供了一些方法：

接下來開始介紹如何高效地載入Bitmap，其實核心思想很簡單： 就是採用BitmapFactory.Options參數來調整圖片尺寸來適配控制項的大小。

假如我們顯示圖片的控制項ImageView寬高為100×100像素，而圖片的尺寸為1024×1024像素，這個時候如果將整個圖片載入進來並顯示到控制項上，自然是很佔用內存資源的。這個時候可以通過BitmapFactory.Options按一定的采樣率載入縮小後的圖片，再將縮小後的圖片顯示到ImageView中，這樣就能減小內存佔用從而在一定程度上避免OOM的發生。

通過BitmapFactory.Options來縮放圖片，主要是使用它的inSampleSize參數，也就是前面提到的采樣率。當采樣率inSampleSize為1時，采樣後的圖片大小為原圖大小；當采樣率inSampleSize>1，比如為2時，采樣後的圖片寬高都為原圖的1/2，即像素降為原圖的1/4，佔用的內存大小也就是原圖的1/4；比較特殊的是，當采樣率inSampleSize<1時，系統會自動將該值當做1來處理。 因此可以得出一個結論：采樣率inSampleSize必須是大於1的整數圖片才會有縮小的效果，並且采樣率同時作用於寬高，也就是說采樣後的圖片會縮小到原圖的1/(inSampleSize^2)。比如inSampleSize=4，那麼縮放比例為1/16。

我們現在知道了，通過采樣率可以提高圖片的載入效率，那麼如何才能計算出最合適的采樣率？我們可以按照如下流程：

接下來以decodeFile方法為例實現圖片的縮放，其他三個方法處理方式類似。

下一篇： Android 圖片載入（二）圖片載入框架Glide 入門篇

《Android開發藝術探索》

E. 關於Android 中 Options.inSampleSize怎麼用

這個是讀取bitmap時用到的屬性,是為了對原圖降采樣.

比如原圖是一個 4000 * 4000 點陣的圖,佔用內存就是 4000 * 4000 * 單個像素佔用位元組數
單個像素佔用位元組數取決於你用的是 RGB565, ARGB8888 等. 4000 * 4000 這個解析度已很接近目前市面主流機器的默認照片解析度.
假設你用的是RGB565解析這張圖,那一個點就佔用2個位元組.如果完整解析這個圖片,就需要 大約3.2MB的內存.
如果你用了一個GridView,同時顯示了30張這種圖,那幾乎可以確定你會收到一個OOM異常.

所以需要對這種大圖進行降采樣,以減小內存佔用.畢竟拇指大小的地方根本用不著顯示那麼高的解析度.
因為直接從點陣中隔行抽取最有效率,所以為了兼顧效率, inSampleSize 這個屬性只認2的整數倍為有效.
比如你將 inSampleSize 賦值為2,那就是每隔2行采1行,每隔2列采一列,那你解析出的圖片就是原圖大小的1/4.
這個值也可以填寫非2的倍數,非2的倍數會被四捨五入.

綜上,用這個參數解析bitmap就是為了減少內存佔用.

一下是我的一個根據指定大小對圖片文件降采樣讀取的一個函數,供參考.

/**
* author: liuxu
* de-sample according to given width and height. if required width or height is
* smaller than the origin picture's with or height, de-sample it.
* NOTE: if image quality is your first concern, do not use this method.
* @param path full path for the picture
* @param width the required width
* @param height the required height
* @return bitmap
*/
public static Bitmap decodeBitmapForSize(String path, int width, int height) {
final BitmapFactory.Options options = new BitmapFactory.Options();

if (width != 0 && height != 0) {
// decode with inJustDecodeBounds=true to check size
options.inJustDecodeBounds = true;
BitmapFactory.decodeFile(path, options);
// calculate inSampleSize according to the requested size
options.inSampleSize = calculateInSampleSize(options, width, height);
options.inJustDecodeBounds = false;
}

// decode bitmap with the calculated inSampleSize
options.inPreferredConfig = Config.RGB_565;
options.inPurgeable = true;
options.inInputShareable = true;
return BitmapFactory.decodeFile(path, options);
}

/**
* author: liuxu
* de-sample according to given width and height
* @param options options
* @param reqWidth the required width
* @param reqHeight the required height
* @return the calculated sample size
*/
private static int calculateInSampleSize(BitmapFactory.Options options,
int reqWidth, int reqHeight) {
// raw height and width of image
final int height = options.outHeight;
final int width = options.outWidth;

int initSize = 1;
if (height > reqHeight || width > reqWidth) {
if (width > height) {
initSize = Math.round((float) height / (float) reqHeight);
} else {
initSize = Math.round((float) width / (float) reqWidth);
}
}

/*
* the function rounds up the sample size to a power of 2 or multiple of 8 because
* BitmapFactory only honors sample size this way. For example, BitmapFactory
* down samples an image by 2 even though the request is 3.
*/
int roundedSize;
if (initSize <= 8) {
roundedSize = 1;
while (roundedSize < initSize) {
roundedSize <<= 1;
}
} else {
roundedSize = (initSize + 7) / 8 * 8;
}

return roundedSize;
}

F. Android 圖片選擇(ImageSelector) (拍照,裁剪,壓縮,查看)

1.遍歷sdcard文件夾(指定層次深度 searchDeep ),如果文件夾發現圖片 , 添加到已搜索到圖片的文件列表中,並跳入下一個文件夾搜索

2.使用 ContentResolver 搜索 添加搜索標簽(png,jpg,jpeg,gif 等) 優點:更快速

壓縮調用

第一步-->

采樣率壓縮:設置 BitmapFactory.Options.inSampleSize 大小

第二步-->

PNG:尺寸壓縮( Config:ARGB_4444 ,工具: Canvas );

JPG:尺寸壓縮( Config:ARGB_565 ,工具: Canvas )+壓縮質量( bitmap.compress() )

注 :

1.GIF不做壓縮處理

2.尺寸壓縮:改變寬高(png,jpg)

3.壓縮質量:改變文件大小(適用jpg,png無效)

G. android 圖片質量壓縮和尺寸壓縮有什麼區別

‍

這個方法用來將特定格式的壓縮圖片寫入輸出流（OutputStream）中，當然例如輸出流與文件聯系在一起，壓縮後的圖片也就是一個文件。如果壓縮成功則返回true，其中有三個參數：

format是壓縮後的圖片的格式，可取值：Bitmap.CompressFormat .JPEG、~.PNG、~.WEBP。

quality的取值范圍為[0,100]，值越小，經過壓縮後圖片失真越嚴重，當然圖片文件也會越小。（PNG格式的圖片會忽略這個值的設定）

stream指定壓縮的圖片輸出的地方，比如某文件。

上述方法還有一個值得注意的地方是：當用BitmapFactory decode文件時可能返回一個跟原圖片不同位深的圖片，或者丟失了每個像素的透明值（alpha），比如說，JPEG格式的圖片僅僅支持不透明的像素。文章android圖片壓縮在文末提到的下面這點可能就是這個原因：

當調用bitmap.compress(CompressFormat.JPEG, 100, fos);保存為圖片時發現圖片背景為黑色，如下圖：

下面是質量壓縮的代碼：

(Bitmapbmp,Filefile){

ByteArrayOutputStreambaos=newByteArrayOutputStream();

intoptions=80;//個人喜歡從80開始,

bmp.compress(Bitmap.CompressFormat.JPEG,options,baos);

while(baos.toByteArray().length/1024>100){

baos.reset();

options-=10;

bmp.compress(Bitmap.CompressFormat.JPEG,options,baos);

}

try{

FileOutputStreamfos=newFileOutputStream(file);

fos.write(baos.toByteArray());

fos.flush();

fos.close();

}catch(Exceptione){

e.printStackTrace();

}

}

這段代碼來自Android圖片壓縮總結，我根據自己的需求改了改，但是大同小異，所以就直接貼了。

隨著代碼中的option逐漸變小，我們可以在logcat中列印baos的大小來查看圖片的大小。我們也可以去掉while的循環條件，一直壓縮下去看效果，最終一張照片可能就由原來的3、4M變成了幾百K甚至幾百B了。我在試的過程中將option設置成100，壓縮後偶爾會出現一張3、4M的圖片經過壓縮後竟變成了6、7M，這里還是有點困惑，不知道為什麼。

隨後，我想把這個壓縮後的圖片（1、200KB）填充到ImageView中時卻失敗了，logcat中提示圖片過大！這就是文章開頭提到的問題，雖然我們通過質量壓縮使File形式的圖片文件縮小了，但是並沒有改變圖片的寬高，原先是1080*1920解析度的圖片經壓縮後還是1080*1920，而File格式轉換成Bitmap格式進入到內存中時，內存是根據圖片的像素數量來給圖片分配內存大小的，還是有好幾M，因此填充ImageView失敗。

順便提一下，可以用bitmap.getByteCount()獲取存儲bitmap像素的內存大小，但是KITKAT（Android 4.4版本）以後用getAllocateByteCount()獲取。一般情況下，後者返回值比前者大，比如，當bitmap被重用去decode另外更小的bitmaps時，或者被人為地配置一下屬性值，比如setWidth()、setHeight()、reconfigure()時，如果bitmap不做以上操作，二者的返回值應該是一樣的。（譯文，不太懂）

二、尺寸壓縮

特點: 通過設置采樣率, 減少圖片的像素, 達到對內存中的Bitmap進行壓縮

我們主要通過BitmapFactory中的decodeFile方法對圖片進行尺寸壓縮：

publicstaticBitmapdecodeFile(StringpathName,BitmapFactory.Optionsopts)

public static Bitmap decodeFile (String pathName, BitmapFactory.Options opts)

其中有兩個參數：

pathName是圖片文件的路徑。

opts 就是所謂的采樣率，它里邊有很多屬性可以設置，我們通過設置屬性來達到根據自己的需要，壓縮出指定的圖片。其中比較常用的屬性有：

booleaninJustDecodeBounds—— 如果設置為true，則只讀取bitmap的寬高，而忽略內容。

intinSampleSize—— 如果>1，調用decodeFile方法後，就會得到一個更小的bitmap對象（已壓縮）。比如設置為2，那麼新Bitmap的寬高都會是原Bitmap寬高的1/2,總體大小自然就是原來的1/4了，以此類推。

booleaninPurgeable—— 如果設置為true，壓縮後的圖片像素占的內存將會在系統清理內存的時候被回收掉，當像素的信息再次被用到時將會自動重新decode該像素（比如getPixels()時）。（慎用！重復decode可以會造成UI的卡頓，API level 21 已棄用）

booleaninInputShareable—— 與inPurgeable配合使用，如果inPurgeable設置成false，自動忽略此值，如果inPurgeable為true，此值決定是否該bitmap能分享引用給輸入數據（inputstream，array等），或者必須進行深拷貝。API level 21 已棄用。（這是譯文，不太理解！！！）

下面是一段實現的代碼

privateBitmapsizeCompres(Stringpath,intrqsW,intrqsH){

//用option設置返回的bitmap對象的一些屬性參數

finalBitmapFactory.Optionsoptions=newBitmapFactory.Options();

options.inJustDecodeBounds=true;//設置僅讀取Bitmap的寬高而不讀取內容

BitmapFactory.decodeFile(path,options);//獲取到圖片的寬高，放在option里邊

finalintheight=options.outHeight;//圖片的高度放在option里的outHeight屬性中

finalintwidth=options.outWidth;

intinSampleSize=1;

if(rqsW==0||rqsH==0){

options.inSampleSize=1;

}elseif(height>rqsH||width>rqsW){

finalintheightRatio=Math.round((float)height/(float)rqsH);

finalintwidthRatio=Math.round((float)width/(float)rqsW);

inSampleSize=heightRatio<widthRatio?heightRatio:widthRatio;

options.inSampleSize=inSampleSize;

}

returnBitmapFactory.decodeFile(path,options);//主要通過option里的inSampleSize對原圖片進行按比例壓縮

}

private Bitmap sizeCompres(String path, int rqsW, int rqsH) {

// 用option設置返回的bitmap對象的一些屬性參數

final BitmapFactory.Options options = new BitmapFactory.Options();

options.inJustDecodeBounds = true;// 設置僅讀取Bitmap的寬高而不讀取內容

BitmapFactory.decodeFile(path, options);// 獲取到圖片的寬高，放在option里邊

final int height = options.outHeight;//圖片的高度放在option里的outHeight屬性中

final int width = options.outWidth;

int inSampleSize = 1;

if (rqsW == 0 || rqsH == 0) {

options.inSampleSize = 1;

} else if (height > rqsH || width > rqsW) {

final int heightRatio = Math.round((float) height / (float) rqsH);

final int widthRatio = Math.round((float) width / (float) rqsW);

inSampleSize = heightRatio < widthRatio ? heightRatio : widthRatio;

options.inSampleSize = inSampleSize;

}

return BitmapFactory.decodeFile(path, options);// 主要通過option里的inSampleSize對原圖片進行按比例壓縮

}

上面就是簡單的質量壓縮與尺寸壓縮。