本人最近開發的app是一款電視機頂盒android app，該app打開後會去向服務器求取各個位置的圖片，圖片內容是服務器後臺事先上傳並配置好的。客戶端哪個頁面，哪個位置放哪張圖片，都是服務端配置的。所以app開啓後的2，3秒內可能要請求十幾、甚至幾十張圖片，並快速顯示出來。通常情況下是沒有問題的，但是有個別情況圖片開始加載到全部加載完畢需要一二十秒，這個問題困擾了我好久。下面是我們的解決過程。
- 首先懷疑網絡問題
服務器開發人員反覆實驗多次，無論請求十張還是上百張，服務器都是快速返回圖片數據，絕不至於要一二十秒；
- 懷疑圖片加載引擎出問題
先後用了五種圖片加載引擎都會出現這種問題（用到的加載引擎有， ImageReq， FinalBitmap， facebook的fresco引擎，xutils， Picasso ，共五種，其中fresco 和xutils 在機頂盒上加載效果更好一些）。如果是加載引擎的問題，總不能所有引擎都有問題吧。
所以很可能代碼裏哪裏出錯了，或者圖片請求過程哪裏出錯了。
- 一個一個圖片請求排查
經過給一個個圖片加載請求過程加log並排查，發現只有當最開始請求的圖片鏈接種有“無效鏈接”時纔會有引擎加載慢的問題。
譬如，app開啓時要同時請求十幾張圖片，而最開始的幾張圖片連接時無效的或者客戶端永遠請求不到的，這時候引擎圖片請求就卡在這裏，直到這幾張圖片請求出現網絡報錯或者“timeout”後才繼續執行後面的“鏈接正常”的圖片請求。這幾張無效的圖片請求導致後面十幾張或幾十張圖片請求滯後。
當然若是最後幾張圖片出現“無效鏈接”則不會導致所有圖片加載慢，此時最多是最後幾張圖片加載不出來。
只有最開始幾張圖片無效時纔會出現這個問題。問題終於找到了。
- 解決方法
這種無效鏈接而加載慢的問題，是客戶端的原因嗎？有一部分，圖片請求時timeout時間太長了，所以最好自己能控制timeout時間，而不是全都交給引擎解決。1s內秒獲取不到，就通知timeout。當然還有服務端的原因：因爲客戶端無法識別你這個鏈接是有效還是無效，譬如多加個字母，少加個數字客戶端都無從知曉。所以最好也在服務端排查，爲什麼會傳給客戶端錯誤的鏈接？！
所以最終這個問題的解決是服務端人員完成的： 在返回給客戶端發圖片鏈接的時候嚴格檢查，域名、路徑、圖片名字嚴格對應，保證所有圖片鏈接是有效的，能成功請求到的。
同時客戶端要完善圖片請求過程，請求1秒得不到響應就拋出timeout異常，不至於一直佔用資源等待而影響其他圖片的獲取。
關於網絡請求圖片緩慢的問題真的很令人頭疼， 這僅僅是所有問題中的一個小插曲。記錄該過程，以供參考。