基於android樣本程式(bitmapfun) 高效載入圖片讓人無語地方

　　在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，不想自己重寫檔案鎖的同學可以把這裡面的檔案快取移植進去。點擊檔案下載