12個關於C說話的風趣問答。本站提示廣大學習愛好者：（12個關於C說話的風趣問答）文章只能為提供參考，不一定能成為您想要的結果。以下是12個關於C說話的風趣問答正文
在android法式開辟中我們常常見到須要上傳圖片的場景，在這裡有個技巧點，須要把圖片緊縮處置，然後再停止上傳。如許可以削減流量的消費，進步圖片的上傳速度等成績。
關於android若何緊縮，網上的材料也是許多，但年夜多半都是代碼片斷，講授緊縮步調，而沒有一個適用的對象類庫。那末若何將緊縮算法封裝成一個適用對象庫呢？個中會碰到些甚麼成績，好比：
1.須要緊縮的圖片有若干
2.緊縮後的圖片是籠罩照樣保留到別的的目次
3.假如是另存目次須要將原始圖片刪除嗎
4.假如轉變緊縮後的圖片的尺寸年夜小是依照原圖的比例減少照樣直接指定年夜小
5.假如原圖有扭轉成績，需不須要停止修改
6.關於多圖緊縮是並發回是線性的處置
7.能不克不及應用service來停止緊縮處置，是local（當地）照樣remote（長途）的方法來啟動service
8.假如須要緊縮的圖片異常多，若何應用線程池來處置
基於以上幾點的思慮，自己盤算寫個系列文章來一步一步處理這些成績（忘年夜家連續存眷），將Service，多線程的應用及緊縮算法聚集到一個項目中。如許不只在現實運用中照樣作為進修材料來說都是比擬好的。終究我會將這個系列中觸及的代碼及迭代的進程開源到github，迎接年夜家star，迎接遞交bug。
固然有些同伙能夠會說現實運用中一次上傳的圖片數目不會太多吧，斟酌這些成績是否是有點多慮了，好吧，假如您真是這麼以為的那末可以疏忽本系列文章。
現實需求中根本都邑是依照原圖的寬高比停止緊縮，直接指定尺寸年夜小的比擬少見，所以本系列文章也是針對這類等比率緊縮來停止的。
總之，對圖片停止緊縮，年夜家重要存眷兩點：
1.對圖片的尺寸年夜小停止縮放來到達緊縮的目標
2.對圖片停止質量緊縮
對圖片的尺寸年夜小停止縮放來到達緊縮的目標
針對這類情形及圖片扭轉成績，年夜家可以參考我的 android處置攝影扭轉成績及帶來的對內存占用的思慮 這篇文章。
只是年夜家須要留意的是，這裡須要依照原始圖片的寬高比（srcRatio）來盤算終究輸入圖片的寬高(actualOutWidth,actualOutHeight)，最初經由過程actualOutWidth,actualOutHeight來盤算采樣值sampleSize。
焦點代碼以下：
LGImageCompressor.java
BitmapFactory.Options options = new BitmapFactory.Options();
options.inJustDecodeBounds = true;
BitmapFactory.decodeFile(srcImagePath, options);
//依據原始圖片的寬高比和希冀的輸入圖片的寬高比盤算終究輸入的圖片的寬和高
float srcWidth = options.outWidth;
float srcHeight = options.outHeight;
float maxWidth = outWidth;//希冀輸入的圖片寬度
float maxHeight = outHeight;//希冀輸入的圖片高度
float srcRatio = srcWidth / srcHeight;
float outRatio = maxWidth / maxHeight;
float actualOutWidth = srcWidth;//終究輸入的圖片寬度
float actualOutHeight = srcHeight;//終究輸入的圖片高度
if (srcWidth > maxWidth || srcHeight > maxHeight) {
if (srcRatio < outRatio) {
actualOutHeight = maxHeight;
actualOutWidth = actualOutHeight * srcRatio;
} else if (srcRatio > outRatio) {
actualOutWidth = maxWidth;
actualOutHeight = actualOutWidth / srcRatio;
} else {
actualOutWidth = maxWidth;
actualOutHeight = maxHeight;
}
}
//盤算sampleSize
options.inSampleSize = computSampleSize(options, actualOutWidth, actualOutHeight);
為了便利年夜家懂得以上代碼，舉個極端例子：
假設原始圖片寬為srcWidth＝40，高為srcHeight＝20。希冀輸入的寬為maxWidth=300，高為maxHeight＝10。 那末srcRatio＝40:20=2，outRatio＝300:10=30. 明顯srcRatio<outRatio，那末我們的現實終究輸入圖片的尺寸應當以maxHeight（10）為准即actualOutHeight = maxHeight，最初依據原圖的比率來盤算actualOutWidth=actualOutHeight*srcRatio = 10*40/20=20，最初獲得的actualOutWidth＝20. 終究輸入圖片的寬高比為20:10=2，和原始圖片寬高比雷同。其它情形相似，這裡不做詳解了。
對圖片停止質量緊縮
針對這類情形，android的Bitmap類中API接口有compress辦法
public boolean compress(CompressFormat format, int quality, OutputStream stream)
三個參數的懂得應當不難，年夜家可以檢查官方doc文檔。compress辦法重要經由過程quality來掌握輸出到stream中的像本質量。
這針對願望輸入的圖片占用的空間不年夜於必定的值這類場景會比擬適合，由於我們可以經由過程輪回斷定緊縮後的年夜小能否年夜於定值，假如知足則削減quality持續履行compress操作。焦點代碼以下：
//停止有損緊縮
ByteArrayOutputStream baos = new ByteArrayOutputStream();
int options_ = 100;
actualOutBitmap.compress(Bitmap.CompressFormat.JPEG, options_, baos);//質量緊縮辦法，把緊縮後的數據寄存到baos中 (100表現不緊縮，0表現緊縮到最小)
int baosLength = baos.toByteArray().length;
while (baosLength / 1024 > maxFileSize) {//輪回斷定假如緊縮後圖片能否年夜於maxMemmorrySize,年夜於持續緊縮
baos.reset();//重置baos即讓下一次的寫入籠罩之前的內容
options_ = Math.max(0, options_ - 10);//圖片質量每次削減10
actualOutBitmap.compress(Bitmap.CompressFormat.JPEG, options_, baos);//將緊縮後的圖片保留到baos中
baosLength = baos.toByteArray().length;
if (options_ == 0)//假如圖片的質量已降到最低則，不再停止緊縮
break;
}
緊縮一個超年夜圖是要費時光的，所以年夜家應當斟酌將緊縮放到後台線程中履行，假如沒有高並發的需求應用AsyncTask就可以處理成績。
焦點代碼：
private class CompressTask extends AsyncTask<String, Void, String> {
@Override
protected String doInBackground(String... params) {
return compressImage();//履行緊縮操作
}
@Override
protected void onPreExecute() {
if (compressListener != null) {
compressListener.onCompressStart();//監聽回調（開端緊縮）
}
}
@Override
protected void onPostExecute(String imageOutPath) {
if (compressListener != null) {
compressListener.onCompressEnd(imageOutPath);//監聽回調（緊縮停止）
}
}
}
經由恰當的封裝代碼可以經由過程在Activity中的履行
LGImgCompressor.getInstance(this).withListener(this).starCompress(Uri.fromFile(imageFile).toString(),outWidth,outHeight,maxFileSize);
來啟動緊縮義務
寫在最初
為了到達最好的緊縮成果，可以將下面兩種計劃同時停止。假如緊縮消費的時光很長，須要將緊縮進程放入後台線程中履行。
自己寫了個簡略的demo法式，完成的功效有：
1.開啟攝像頭拍攝照片
2.指定照片的存儲地位
3.緊縮照片到指定目次下
4.應用AsyncTask履行緊縮操作
5.顯示緊縮後的照片及其相干信息到前台activity
因為這個版本是應用AsyncTask異步義務來履行compress的，而AsyncTask因為android版天職裂成績有些版本是多線程的，有些版本是單線程的，也是醉了，總之此版本實用於一次緊縮義務不是許多的情形，假如須要處置數據很年夜的緊縮義務，須要斟酌用線程池來處置。
別的，若何聯合應用service和多線程會鄙人篇文章詳細解釋。
demo開源github地址以下：
LGImageCompressor
以上所述是小編給年夜家引見的Android圖片緊縮上傳之基本篇的相干常識，願望對年夜家有所贊助，假如年夜家想懂得更多資訊敬請存眷網站！
