在android的開發(fā)指南上有這樣一篇文章，如何更有效率的加載圖片，這篇文章詳細(xì)地介紹了如何加載高清圖到內(nèi)存，同時避免系統(tǒng)報OOM的問題，文章寫得很不錯，示例程序也可以直接運(yùn)行。在我們項目的一次小版本升級的過程中，我們嘗試了使用git上的一個開源項目afinal(bitmapfun的封裝版)來加載圖片，但是在測試的時候發(fā)現(xiàn)了一個問題，新的圖片加載器(bitmapfun)比之前用的ImageDownloader要慢很多，特別是在網(wǎng)絡(luò)狀況不好的時候，等5s鐘算少的，一般要等10s左右，老大找到我，說這個圖片加載不出來啊，太慢了。不是吧，這玩笑開的有點(diǎn)大了吧，拿來一用，果然是慢很多。

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

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

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

附：老版本的bitmapfun，不想自己重寫文件鎖的同學(xué)可以把這里面的文件緩存移植進(jìn)去。

最新評論