圖片加載框架用了不少，從afinal框架的afinalBitmap，Xutils的BitmapUtils，老牌框架universalImageLoader,著名開源組織square的picasso,google推薦的glide到FaceBook推出的fresco。這些我前前後後都體驗過，那麼面對這麼多的框架，該如何選擇呢？下面簡單分析下我的看法。
afinal和Xuils在github上作者已經停止維護了，開源社區最新的框架要屬KJFramework，不過這種快速開發框架看似很好用，功能也應有盡有，小型項目也罷，大型項目我不是很推薦，這樣做項目的耦合度太高，一旦出現停止維護，而新的問題不斷增加，沒人處理就麻煩了。
在glide和fresco還未出來的時候，當時最火的莫過於universalImageLoader和picasso了，當時覺得universalImageLoader配置相對picasso麻煩，雖然提供了各種配置，但是沒有實踐過，根本不知道如何配置，還不如都採用默認配置，就選擇了picasso作爲圖片加載框架，用了近一年的時間，沒有太大的問題，且使用簡單，或許是因爲之前的項目太過於簡單，週期也並不是很長，還有使用eclipse開發，一個很大的問題一直都沒有暴露出來，換上了最新的Android Studio可以清晰的看到各種性能相關的監控，如cpu還有內存監控，終於知道了之前做的項目都那麼的卡頓的罪魁禍首，picasso加載稍微大一點的圖片就特別耗內存，通常一個listView或者頂部滑動廣告欄都含有多張圖片，這使得做出的頁面只要含圖片較多就異常卡頓（之前的時候還把它歸結爲測試機不好），知道這一點後我就有點想把picasso給替換掉，但這一次我不能那麼粗心。
測試了picasso，glide，universalImageLoader，fresco這四個框架，測試內容大概有以下幾項，內存測試，大圖片測試，小圖片測試，本地圖片，網絡圖片當然還結合官方文檔體驗其特色功能，內存測試中，glide，universalImageLoader，fresco表現都非常優秀，picasso這一點上實在是太糟糕了，小圖片差別也不是很大，稍微大點圖片內存消耗就要比其他高出幾倍，這一點上證明了我的猜想，picasso不能再用了，下面一項項分析其他框架，在高於2M左右大圖測試中fresco的表現則和picasso一樣直接神馬都不顯示，項目中要實現大圖預覽功能，這點上是不行的，接着看universalImageLoader和glide在這幾項測試中成績都很好，到底該如何選擇呢？
因爲我項目之前用的picasso，glide從用法上幾乎就是另一個picasso，從picasso轉移到glide相對改動較少，還有一點就是這個項目是google在維護，我也能給它更多的信任，相比較universalImageLoader，glide可以支持gif和短視頻，後期也需要用到，這裏不得不談一下glide優秀的緩存機制了，glide圖片緩存默認使用RGB565相當於ARGB8888可以節省不少的空間，支持與activity，fragment，application生命週期的聯動，更智能管理圖片請求當然還有其他的擴展更多可以看 glide介紹 當然，glide的方法數量比universalImageLoader多了1000多個，遇到64k問題的會比較關注這個。
剛纔只是掠過fresco，其實我對他的期待還是蠻大的，因爲剛出來還有居多不穩定的地方，裏面存在着大量吸引着我的功能，支持webps格式（和jpg一樣都是有損壓縮格式，webps相同質量圖片更節省空間），支持漸進式jpeg，可以輕鬆的定製image的各種屬性，支持多圖請求和圖片複用，並支持手勢縮放和旋轉等等，更多介紹 fresco，當然，實際用的時候並沒有那麼好，很多功能都有待完善。
還有一點細節的地方要注意的，最好不要直接拿來用，至少經過自己簡單的封裝，而不是直接在項目中使用，一個簡單的例子，後期圖片過多，可能需要另外配置一臺機器單獨存放圖片，主機地址做成可配置，可不要因爲一個簡單的需求又要加班了
