Google I/O 2013已經結束，它讓我們對Android將來的發展有了更大的期待。今年I/O大會上展示的令人激動的創新之一是名為Volley庫。Volley是一個處理并緩存網絡請求的庫，它把開發者從不同的應用中編寫相同代碼的泥潭中拯救出來。編寫相同代碼從來都不是有趣的，還會增加開發者的錯誤幾率。正式考慮了這一點，Google創造了Volley。

如果你沒有看?Google I/O 上介紹Volley的視頻，我建議你先去看一下，在對它有了基本了解后再繼續后面的文章。

通過Google I/O介紹，Ficus Kirpatrick談論了許多Volley如何有助于加載圖片的內容。當使用Volley作為你的圖片加載解決方案時，你會發現，盡管它自己處理L2緩存，它請求但不包含一個內存不足的L1圖片緩存。很多人已經使用過例如Universal Image Loader或Square’s newer Picasso library來處理圖片緩存；然而，這些庫通常只處理圖片的加載和緩存。那么，我們如何使用Volley替代它們來加載和緩存圖片呢？首先，讓我們看看Volley提供的加載功能，緩存功能稍后再講。

ImageLoader

ImageLoader類需要一個請求的實例以及一個ImageCache類的實現。圖片通過傳遞一個URL和一個ImageListener實例到get()方法進行加載。從那里，ImageLoader檢查ImageCache，如果圖像不是在緩存中，就從網絡中加載圖片。

NetworkImageView

這個類代替布局中的ImageViews類而且使用ImageLoader類。NetworkImageView類的setUrl()方法需要一個URL路徑字符串和一個ImageLoader實例。然后，它使用ImageLoder的get()方法來取回圖片數據。

Java

1

2

3

4

5

6

7

8

android:id="@+id/twitterUserImage"

android:layout_alignParentLeft="true"

android:layout_alignParentTop="true"

android:layout_width="40dp"

android:layout_height="40dp"

android:padding="5dp"

/>

ImageCache

Volley庫的ImageCache接口允許你使用你喜好的L1緩存實現。不幸的是，Volley的缺點之一，沒有默認的緩存實現。I/O大會上演示了一個BitmapLruCache的代碼片段，但庫本身沒有包含任何實現。

ImageCache接口有兩個方法，getBitmap(String url)和putBitmap(String url, Bitmap bitmap)。這些樁是非常簡單的，它們可以添加到任何緩存實現里。

填補空白：向Volley增加一個圖片緩存

例如，我已經創建了一個簡單的應用，該應用通過Twitter搜索”CapTech”，并在一個列表視圖中顯示搜索到的結果，每一列包含用戶名和圖片。當向下滑動時，這個列表會自動加載舊的記錄，還會從緩存中獲取圖片。

CapTech

有兩種可用的緩存實現。推薦的方法是在內存中使用一個基礎的LRU緩存。對于硬盤的緩存實現，我選擇使用Jack Wharton編寫的DiskLruCache。我選擇這個實現是因為它在Android社區中被頻繁的使用，并且有人提供了一個改造自己的應用來適配Volley的用例。使用一個基于磁盤的L1緩存可能導致阻塞I/O問題。Volley已經有一個隱式的硬盤L2緩存。硬盤L1緩存已經被包含在內了，因為我最初并沒有察覺Volley如果處理圖片請求緩存。

以下是這個實現的主要組件：

RequestManager

RequestManager維護我們的RequestQueue的一個引用。Volley使用ResuestQueue來處理我們對Twitter數據和圖片加載的請求。

GsonRequest

GsonRequest與圖片加載沒有直接聯系，但它代表了如何擴展Volley請求類來處理JSON解析。該類用于對Twitter的GET請求和TwitterData對象的結果。

BitmapLruImageCache

該類是一個基本的“最近最少使用（LRU）”內存緩存實現。它速度快但不會阻塞I/O。這是推薦的方法。

DiskLruImageCache

DiskLruImageCache是一個位圖版本的DiskLruCache封裝。它從DiskLruCache中增加并檢索位圖，還處理緩存的實例化。硬盤緩存可能阻塞I/O。

ImageCacheManager

ImageCacheManager持有ImageCache和Volley ImageLoader引用。

在ImageCacheManager中，你可能注意到一點就是我們使用URL字符串的hashCode()作為緩存的鍵值。這是由于URL中的某些字符不能作為緩存的鍵值。

BuzzArrayAdapter

該適配器比較簡單的。這里只需要注意一點，我們要實現Volley的Listener和ErrorListener接口，并且把該適配器作為Listener參數傳遞給了NetworkImageView 的?setUrl(String string , Listener listener, ErrorListener errorListener)?方法。這個適配器包含了一些額外代碼用于滾動時加載舊的tweets。

Java

1

2

3

4

5

6

7

8

Tweet tweet = mData.get(position);

if(tweet != null){

viewHolder.twitterUserImage.setImageUrl(tweet.getUserImageUrl(), ImageCacheManager.getInstance().getImageLoader());

viewHolder.userNameTextView.setText("@" + tweet.getUsername());

viewHolder.messageTextView.setText(tweet.getMessage());

viewHolder.tweetTimeTextView.setText(formatDisplayDate(tweet.getCreatedDate()));

viewHolder.destinationUrl = tweet.getDestinationUrl();

}

信息匯總

有了所有這些部分，圖像加載和緩存現在變得非常簡單。啟動時，應用程序在MainApplication類中初始化RequestManager和ImageCacheManager類。這里你可以聲明你期望的L1緩存類型。默認實現是內存緩存。

在MainActivity中，我們首次調用TwitterManager并加載初始數據。一旦我們接收到返回數據，我們將它傳遞給BuzzArrayAdapter，并且把BuzzArrayAdapter設置到ListView中。

在以上的BuzzArrayAdapter代碼中，NetworkImageView承擔了所有繁重的圖片加載操作，我們只需要將從ImageCacheManager得到的實例傳達給圖片加載器就可以了。

ImageCacheManager檢查我們的LRU緩存實現，并返回可用的圖片。如果圖片不在緩存中，它就會到網絡中獲取。

當你滾動ListView時，BuzzArrayAdapter會加載更多的tweets和相應的圖片，并重用已經在緩存中的圖片。

結束時的思考

盡管Volley是用處大、速度快、容易實現；但現在還不是使用它的時候，原因如下：

這個庫缺少任何說明文檔和使用用例。

例如緩存配置組件，還不具有我期望的高可配置性。

如上所見，排除基本圖片緩存實現看起來很奇怪。可能包含一個NoImageCache實現也許更加有用，或者使緩存變得可配置以滿足只從網絡上獲取所有信息的需求。

在開發者社區有很多與Volley而令人激動的消息。給人的感覺是這個庫應當已經被作為Android API，并且被引入了很長時間了。就像在I/O大會上宣布的新的Location API 那樣。很顯然，Google正在致力于通過移除一些對app開發的阻礙，從而使得開發者的生活變得更加輕松。

?