android 仿最新版本微信相冊

ytqc3099 7年前發布 | 10K 次閱讀安卓開發 Android開發移動開發

仿微信相冊選擇圖片，查看大圖，寫的不太好，希望評論指出不足，諒解，先介紹一下我的基本思路。

思路

第一步，獲取所有圖片路徑

第一步獲取手機上的所有圖片路徑：

Uri uri = MediaStore.Images.Media.EXTERNAL_CONTENT_URI;
ContentResolver contentResolver = getContentResolver();
//獲取jpeg和png格式的文件，并且按照時間進行倒序
Cursor cursor = contentResolver.query(uri, null, MediaStore.Images.Media.MIME_TYPE + "=\"image/jpeg\" or " +
        MediaStore.Images.Media.MIME_TYPE + "=\"image/png\"", null, MediaStore.Images.Media.DATE_MODIFIED+" desc");
if (cursor != null){
    while (cursor.moveToNext()){
        //do something
    }
    handler.sendEmptyMessage(0);
}

然后定義一個存儲圖片的數據格式：

/** 按時間排序的所有圖片list */  
private ArrayList<SingleImageModel> allImages;  
/** 按目錄排序的所有圖片list */  
private ArrayList<SingleImageDirectories> imageDirectories;  
 /** 
 * 一個文件夾中的圖片數據實體 
 */  
private class SingleImageDirectories{  
    /** 父目錄的路徑 */  
    public String directoryPath;  
    /** 目錄下的所有圖片實體 */  
    public ImageDirectoryModel images;  
}

一個是全部圖片的存儲順序，第二個是按照目錄的圖片存儲順序。

第二步，壓縮加載圖片

獲取到圖片之后，放入到 Gridview 中進行顯示，但是 BitmapFactory.decodeFile() 函數會非常耗時，所以為了使得非常流暢的顯示圖片，創建一個類 AlbumBitmapCacheHelper ，用來異步加載圖片，該類使用 LruCache<String,Bitmap> 來緩存 Bitmap，使得存儲圖片不會造成 OOM，我這里設置 LruCache 的初始大小為 1/4 的運行時內存然后使用 ThreadPoolExecutor 線程池來處理圖片的顯示，線程池大小應該設置適中（可以根據系統的處理器線程數來設置，系統也提供一個相關的線程池，感興趣的也可以去了解），做完這兩件事情之后就可以用來加載圖片了，方法 getBitmap 用來返回圖片：

Bitmap bitmap = getBitmapFromCache(path, width, height);
//如果能夠從緩存中獲取符合要求的圖片，則直接回調
if (bitmap != null) {
} else {
    //新建線程放入線程池去處理該圖片的顯示
}
return bitmap;

如果 cache 中找不到該圖片，則調用 BitmapFactory.decodeFile() 去加載圖片，加載圖片不能夠直接加載原圖，會造成 OOM，所以要去計算壓縮比：

BitmapFactory.Options options = new BitmapFactory.Options();
options.inJustDecodeBounds = true;
BitmapFactory.decodeFile(path, options);
options.inSampleSize = computeScale(options, width, height);
options.inJustDecodeBounds = false;
bitmap = BitmapFactory.decodeFile(path, options);
//獲取之后，放入緩存，以便下次繼續使用
if (bitmap != null && cache!=null) {
    cache.put(path, bitmap);
}

方法 computeScale() 主要是計算圖片最小的壓縮比，這樣在 Gridview 中的 getview 方法中去調用 AlbumBitmapCacheHelper 的 getBitmap() 方法即可。

第三步，處理顯示問題

經過上面的處理之后，在實際顯示的時候會出現一些問題，這里也匯總和分析一下：

顯示圖片閃爍

第一個問題就是圖片顯示會閃爍，這主要是由于 getview 方法的 convertView 的復用導致一個 Imageview 被設置多次 background，解決方法就是使用 setTag 方法：

holder.iv_content.setTag(path);

將要顯示的 Imageview 的 tag 設置為需要顯示的圖片路徑，這樣在回調的時候使用方法 gridView.findViewWithTag(path)，找到這個 Imageview 進行顯示，閃爍的問題就解決了。

大圖片加載速度緩慢

第二個問題就是加載速度很慢，拉的速度很快的情況下，圖片要很久才會加載出來，特別是很大的圖片，比如拍照和截圖的照片，這個問題可以有兩個步驟去優化：第一個優化方案就是在 AlbumBitmapCacheHelper 類中維護一個 ArrayList currentShowString，在 getView 方法中，如果該圖片要顯示，則直接將 path 加入到該 list 中，同時如果這個 view 的 tag 不為空，說明該 view 的原來的 path 是不需要顯示的，所以需要將這個 path 從 ArrayList 中刪除：

//優化顯示效果
if(holder.iv_content.getTag() != null) {
    String remove = (String) holder.iv_content.getTag();
    AlbumBitmapCacheHelper.getInstance().removePathFromShowlist(remove);
}
AlbumBitmapCacheHelper.getInstance().addPathToShowlist(path);

這樣在線程池中的處理方式就是先查看需要顯示的 path 是否在 ArrayList 中，如果沒有在 ArrayList 中，則該線程直接關閉，如果在 ArrayList 中，則顯示該圖片：

if (!currentShowString.contains(path)||cache==null) {
         return;
}

第二個優化方案是如果顯示的圖片很大，特別是拍照和截圖的圖片，decode 有時會耗時幾秒鐘，微信顯示效果非常好，我自己參考微信的表現想出來的處理的方式是：

第一步，從應用的緩存 temp 目錄下取，如果取不到，則進行下一步；
第二步，計算圖片的壓縮比例 samplesize，如果 samplesize < 4（根據表現一般的相機拍攝照片為 4000*3000，需要縮放 4 倍才能加速 decode 步驟），圖片的 BitmapFactory.decodeFile() 時間短，直接返回圖片，但是如果 samplesize > 4，執行第三步；
第三步則將壓縮后的圖片存入 temp 目錄下，以便下次快速取出，這樣微信圖片展示的效果就出來了，顯示的速度和微信一樣，第一次大圖加載慢之外，之后的顯示就能很快：

if (!new File(CommonUtil.getDataPath()).exists())
    new File(CommonUtil.getDataPath()).mkdirs();
//臨時文件的文件名
String tempPath = CommonUtil.getDataPath() + hash + ".temp";
//如果該文件存在
if (new File(tempPath).exists())
    bitmap = BitmapFactory.decodeFile(tempPath);
......
//第三步,如果縮放比例大于4，該圖的加載會非常慢，所以將該圖保存到臨時目錄下以便下次的快速加載
if (options.inSampleSize >= 4) {
    try {
        File file = new File(tempPath);
        if (!file.exists())
            file.createNewFile();
        FileOutputStream fos = new FileOutputStream(file);
        ByteArrayOutputStream baos = new ByteArrayOutputStream();
        bitmap.compress(Bitmap.CompressFormat.PNG, 100, baos);
        fos.write(baos.toByteArray());
        fos.flush();
        fos.close();
    } catch (FileNotFoundException e) {
        e.printStackTrace();
    } catch (IOException e) {
        e.printStackTrace();
    }
}

問題到這里就差不多解決了；

第四步，詳情頁面大圖的展示

第四步大圖的查看，大圖主要是使用網上開源的 ZoomImageView+Viewpagger 的組合，但是使用這個出現的問題就是很容易 OOM，沒辦法，我的處理方式就是在點進去大圖的時候：

public void releaseHalfSizeCache() {  
    cache.resize((int) (Runtime.getRuntime().maxMemory() / 1024 / 8));  
}

直接將 LruCache 的大小變成原來的一半，因為查看大圖頁加載一張大圖占用的內存本身就很大，所以這樣去特殊處理，顯示效果頁還湊合，有別的方法，一定要留言告訴我。

還有一點需要注意的是大圖的查看由于需要通過 intent 傳遞數據，但是 intent 傳遞的數據大小不能太大，如果手機上有幾千張圖片，則數據量大小可能會超過 intent 所能傳遞的最大量，所以可以寫入一個公共的地方，共享內存、數據庫或者文件都可以。

第五步，退出相冊頁面清空 LruCache

圖片選擇完成之后，完成善后工作，將 AlbumBitmapCacheHelper 類中 LruCache 清空，差不多就這樣了，還有很多的功能小點，比如圖片時間的顯示，這里就不詳細一一去介紹了，具體大家看源碼。

問題討論

最新發現的問題：3.0 以前 GC 操作需要很長時間，經常大于 100ms，在執行 GC 時（，程序就會出現卡的現象，3.0 以后 GC 修改為同步，執行的時間通常在 5ms 以內，在 3.0 以前的版本中，加載圖片時，系統把 Bitmap 加載到 Native 緩存中，并不受 GC 管理，需要手機自己釋放，不然會遇到莫名奇妙的內存問題。3.0 以后 Bitmap 直接放到內存中在執行 GC 時，會及時清理無用的 Bitmap 所占的內存，在初始化圖片時把圖片放到內存中，當加載完后，系統會把圖片從內存轉移到顯存中，當你用內存測試工具時，會發現在加載圖片時，內存占用率很高，當加載完成后，內存使用量突然下來，加載大量圖片時會發現這種情況。

總而言之就是 2.x 版本的時候，就算你使用的是 LruCache，Bitmap 還是不會被 GC 主動回收，必須要手動釋放，所以如果需要適配 2.x 版本，該 demo 需要加入手動釋放 Bitmap 的操作。

顯示效果

這里寫圖片描述

項目主頁：http://www.baiduhome.net/lib/view/home/1491531326147

本文由用戶 ytqc3099 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。

轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。

本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！

本文地址：http://www.baiduhome.net/lib/view/open1491531326147.html

安卓開發 Android開發移動開發