Android應用開發：ImageLoader小陷阱——同一個URI

引言

ImageLoader是一個被廣泛使用的用於圖片加載的開源項目，項目地址：https://github.com/nostra13/Android-Universal-Image-Loader

關於ImageLoader的使用，作者的README寫的已經非常詳細了，我在這裏就不再贅述。

Android應用都是分別運行在各自的dalvik虛擬機中，而由於手機內存大小的侷限性，Android系統在設計之初就對每個應用所運行的虛擬機能夠使用的內存進行了嚴格的限制（現在Android正轉向ART的運行環境中，即便是運行環境發生了改變，這樣的內存限制規則還是存在的）。AOSP的現行標準是，以720P的手機來說，若手機自身帶有1G內存，則每個應用可用內存限制在96MB。若有2G內存，則限制爲192MB（Google解釋說這個內存足夠5張800萬像素的位圖了）。一旦某個應用總體使用的內存超過了所在手機的限制，將引發OOM(Out of Memory)錯誤，這個錯誤對於應用程序來說是致命的，能夠直接導致程序崩潰。這正是ImageLoader產生的背景，Android官方的開發指導上邊用很大的章節（http://developer.android.com/intl/zh-cn/training/displaying-bitmaps/index.html）介紹了在開發過程中如何妥善處理Bitmap的加載以防止OOM的發生，亦或是從程序優化角度講也是有必要的。即使你仔細看完了Android官方對於Bitmap的那些指導性文檔，我也強烈建議你使用ImageLoader或Volley進行圖片加載，擁抱開源是最正確的選擇。

所謂陷阱

所謂陷阱其實更應該描述爲開發過程中容易發生的誤會。ImageLoader在之前的版本中對相同的URI並沒有進行過濾，也就是說，對同一個URI進行多次請求，也就能得到多次完成的監聽事件。而這在網絡請求中，有可能造成多餘操作，所以其作者在聽取了使用者建議後在後續版本的更新中對相同URI的請求進行了過濾，也就是說同一個URI的請求，如果只是簡單的使用

ImageLoader.getInstance().loadImage(uri, size, listener)

進行圖片加載的話，無論請求多少次，都只會收到一次listener監聽事件。所以說，如果你的應用中在同一列表或界面中有可能出現同樣URI的圖片，那麼在使用ImageLoader的時候就需要注意了，如果按照默認的用法，那麼最終只會有一個位置能夠正常顯示圖片，其他的會是默認狀態。

解決問題

解決辦法ImageLoader的作者曾在用戶開闢的issue中闡述過，不過隨着版本的變遷，產生了小小的變化（其實就是一個類名的Rename）。

NonViewAware aware = new NonViewAware(size, ViewScaleType.CROP);
ImageLoader.getInstance().displayImage(uri, aware, listener);

這樣，即使對同一個URI進行多次請求，listener監聽事件也不會被過濾，每一個請求都會獲得相應的迴應。