這里不貼大段的代碼了，單單列出思路，和一些解決思路。
我們的圖片加載過程，可以引入緩存，我們設計一種兩層緩存的架構，當拿到一個需要加載的圖片的url時，我們先從內(nèi)存緩存中根據(jù)url查找看內(nèi)存緩存有沒有相關緩存，如果沒有，那么我們在磁盤緩存中進行查找，如果磁盤緩存也沒有，那么我們需要發(fā)出真正的網(wǎng)絡請求，進行圖片的加載，當圖片網(wǎng)絡加載成功時將圖片存入兩級緩存。
內(nèi)存緩存的實現(xiàn)，可以借助LruCache，大小可以指定為app可用內(nèi)存的8分之一。
磁盤緩存可以借助DiskLruCache，也可以自己在app的緩存目錄下進行文件io，注意由于文件Io比較慢，因此存和取最好都要開啟新的異步任務。另外如果自己進行實現(xiàn)，可以考慮對url進行MD5運算，將文件名取為hash值，同時使用app緩存文件時，最好自己在建一個子目錄。另外app內(nèi)部可以有一個菜單展示當前磁盤緩存大小，方便進行清理。
網(wǎng)絡請求的實現(xiàn)，最基本的要通過異步任務來獲取圖片。
加載圖片的優(yōu)化問題。
圖片是各式各樣的，大多數(shù)情況下，我們要展示的圖片，比原始圖片小很多。比如用戶頭像控件只有6464，如果用戶的頭像的原始文件有512512，那么即使我們加載了原始圖片，然而肉眼也看不出區(qū)別。因此，我們加載圖片的時候，可以先獲取即將加載的圖片的大小，格式等，然后根據(jù)需要的尺寸，加載重新采樣的版本。這一個過程，對于網(wǎng)絡加載同樣適用。BitmapFactory的decodeStream可以從網(wǎng)絡輸入流加載圖片。不過如果我們先測量，后加載，可能會爆io異常，這是由于同一個輸入流被讀取了兩次。根據(jù)api，第一次測量的時候，輸入流的讀取位置被改變了，如果需要再次讀取，需要先復位。然而我測試發(fā)現(xiàn)，即使復位，也有可能報異常，因此參考了網(wǎng)絡的其它回答。我們可以將輸入流數(shù)據(jù)寫入字節(jié)數(shù)組輸出流中，然后就可以多次對流進行操作了。
網(wǎng)絡請求的發(fā)出優(yōu)化
當需要加載大量圖片時，可能會有這樣的場景，即當前頁面的圖片還沒有加載出來，我們已經(jīng)滑動到了其它頁面，或者下一頁，這導致發(fā)出的網(wǎng)絡請求越來越多，而用戶目前正在查看的內(nèi)容的網(wǎng)絡請求無法最快完成。比如在一個展示圖片的app中，上拉會加載更多圖片。如果在當前頁的圖片未完全展示的情況下，用戶進行了多次上拉操作，那么即使一開始的頁面的圖片已經(jīng)沒用了，后臺的網(wǎng)絡請求還是回去先加載它們，從而使得當前用戶停留頁面的圖片得不到即使加載。
我在實現(xiàn)中曾引入一個簡單的設計，一個存儲異步任務的數(shù)組，發(fā)出任務時，加入數(shù)組，如果超過一定的閾值，那么就取消最先加入的任務，而添加新的任務。
