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，當然，實際用的時候並沒有那麼好，很多功能都有待完善。

還有一點細節的地方要注意的，最好不要直接拿來用，至少經過自己簡單的封裝，而不是直接在專案中使用，一個簡單的例子，後期圖片過多，可能需要另外配置一臺機器單獨存放圖片，主機地址做成可配置，可不要因為一個簡單的需求又要加班了