在android的開發指南上有這樣一篇文章，如何更有效率的加載圖片，地址為 https://developer.android.com/training/displaying-bitmaps/index.html，這篇文章詳細地介紹了如何加載高清圖到內存，同時避免系統報OOM的問題，文章寫得很不錯，示例程序也可以直接運行。在我們項目的一次小版本升級的過程中，我們嘗試了使用git上的一個開源項目afinal(bitmapfun的封裝版)來加載圖片，但是在測試的時候發現了一個問題，新的圖片加載器(bitmapfun)比之前用的ImageDownloader要慢很多，特別是在網絡狀況不好的時候，那簡直是坑爹，等5s鐘算少的，一般要等10s左右，老大找到我，說這個圖片加載不出來啊，太慢了。我靠，不是吧，這玩笑開的有點大了吧，拿來一用，果然是慢很多。

　　然后開始了調試工作，開始我在想是不是網絡下載部分不一樣，之前用的是httpclient，現在bitmapfun用的是url.openConnection，果斷替換成之前的httpclient方法，感覺有所好轉(其實是自己心理在作怪)，再試試，發現有時快，有時慢，對比之前的，之前的圖片一直很穩定，不會出現這種情況啊，然后想了個辦法，在項目中的找了兩個頁面，一個用之前的ImageDownload加載，另一個用bitmapfun加載，然后把各個時段(可以分為3段吧，1是從內存緩存中查找、2是從網絡加載、3是存到內在緩存和sdcard緩存)的時間打印出來對比，發現確實是bitmapfun下載這塊(processBitmap方法)里面最耗時間，這部分的代碼，看到同步鎖，應該是他吧，咋一看，沒問題啊，只鎖住一小塊，應該是防止緩存沒被初始化的吧，過。。。再往下看，頻繁的對sdcard進行io操作，恩對，應該是這里，把剛才的方法重復一下，分段打印耗時，一看結果，tnnd，占用時間最長的居然是wait操作，也就是那個鎖的等待，再去看下代碼，雙擊下鎖的范圍，發現基本是對整個下載過程進行了同步鎖定，這尼瑪，太坑爹了吧，一個圖片在下載的時候，其他的都得在那等著，那前面新建的3個核心線程，被你同步成一個，我說怎么看到這個加載圖片這么整齊，一個個出現。

　　發現了問題，問下為什么，他這么做的原因是什么，其實就是為了那個DiskLruCache的日志文件，不允許多個線程同時操作，否則日志會錯亂，就沒辦法統計哪個文件是最久未被使用的。自己想試著改下鎖的范圍，發現有點困難，因為下載過程中對日志文件操作的太頻繁了，哪位大牛有好的方法告訴下我，不勝感激。

　　對使用bitmapfun或者afinal的一點建議，DiskLruCache慢的關鍵在于對日志文件(目錄下journal文件)的要求太高了，日志文件的作用就是記錄每一個文件的訪問次數，所以它每一次讀取和寫入都要寫入日志記文件，這樣是可以更準確的統計出最久未被使用的文件，但是代價太高了(頻繁的io操作和同步鎖)，記得上個版本的bitmapfun是不用日志文件的，直接從程序訪問sdcard緩存開始計算訪問時間，其實這樣更合適一些，對性能更好。所以如果使用這個示例程序來加載圖片，最好的方式就是使用上個版本的DiskLruCache或者自己想辦法來實現日志文件的記錄，有更好的方法包括日志文件的記錄方法，記得告訴我哦！

附：老版本的bitmapfun，不想自己重寫文件鎖的同學可以把這里面的文件緩存移植進去。點擊文件下載