[Android] Volley源碼分析(一)體系結構

Volley:google出的一個用於異步處理的框架。由於本身的易用性和良好的api,使得它能得以廣泛的應用。我還是一如既往從源碼的方向上來把控它。我們先通過一段簡單的代碼來了解Volley

RequestQueue queue = Volley.newRequestQueue(this);
ImageRequest imagerequest = new ImageRequest(url, new Response.Listener(){

            @Override
            public void onResponse(Bitmap response) {
                // TODO Auto-generated method stub
                System.out.println(">>>bitmap = "+response);
            }}, 300,
                200,
                Config.ARGB_8888,
                new ErrorListener() {

                    @Override
                    public void onErrorResponse(VolleyError error) {
                        // TODO Auto-generated method stub
                        System.out.println("error "+error);
                    }
                });
        queue.add(imagerequest);

俗話說,“對比方顯美”,代碼框架也如此。我們先回想一下我們過去創建bitmapcache的慘痛經歷吧。首先我們使用的cache功能比較單一,往往只是支持內存cache，淘汰策略一般是通過數量或者容量限制。每寫一個app都自成一套。此外,一旦我們脫離了程序,我們將不再獲得我們Bitmap的元數據,比如請求網絡鏈接,資源描述符等等,而且對於同一個網絡請求我們要用單獨的裝飾器來攔截。

當然,我之所以列舉這些出來,是因為在Volley裡面已經很好的解決了這些問題,當你下載了Volley的源碼編譯以後,你會發現,Volley所涵蓋的功能遠比你考慮的要多。而且這些東西,已經被很好的封裝起來。而且Volley的代碼讀起來也非常的順口,並不像Android原生的一些代碼一樣又臭又長。如果說Volley是一種好的開源框架,不如說Volley是一套現在看起來還不錯的設計模式。而且從Volley所提供的有些接口來說,Volley已經將很大部分封裝在框架內部,對於api調用者來說,無疑是個福音。

Volley裡面普遍采用了生產消費者模式,當然你說它是觀察者其實也無可厚非。生產者通過生產產品來通知消費者消費,這種簡單的模型在多種框架中使用到。這裡的消費者是叫Request的類。這個類將分發給CacheDispatcher和NetworkDispatcher來進行消費。從我們寫Cache的經驗來說我們對Cache的處理模式普遍一致,大都是看Cache中是否存在,如果存在,則load from disk.否則請求網絡。其實Volley的處理大同小異。對於允許Cache的請求。Request將被RequestQueue分發到CacheDispatcher消費。如果CacheDispatcher消費不了,那麼就將分發給NetworkDispatcher。這種模式非常像職責鏈。其實在這種分發下,存在一個Volley的亮點之一,就是url攔截。RequestQueue本身維護一個暫存列表，而這種暫存列表能很好的攔截重復的URL請求。由CacheDispatcher處理的請求,如果在disk cache中存在,那麼將通過Request的parseNetworkResponse 接口進行解析,我們看一下對於一個圖片請求他的parse流程:

private Response doParse(NetworkResponse response) {
        byte[] data = response.data;
        BitmapFactory.Options decodeOptions = new BitmapFactory.Options();
        Bitmap bitmap = null;
        if (mMaxWidth == 0 && mMaxHeight == 0) {
            decodeOptions.inPreferredConfig = mDecodeConfig;
            bitmap = BitmapFactory.decodeByteArray(data, 0, data.length, decodeOptions);
        } else {
            // If we have to resize this image, first get the natural bounds.
            decodeOptions.inJustDecodeBounds = true;
            BitmapFactory.decodeByteArray(data, 0, data.length, decodeOptions);
            int actualWidth = decodeOptions.outWidth;
            int actualHeight = decodeOptions.outHeight;

            // Then compute the dimensions we would ideally like to decode to.
            int desiredWidth = getResizedDimension(mMaxWidth, mMaxHeight,
                    actualWidth, actualHeight);
            int desiredHeight = getResizedDimension(mMaxHeight, mMaxWidth,
                    actualHeight, actualWidth);

            // Decode to the nearest power of two scaling factor.
            decodeOptions.inJustDecodeBounds = false;
            // TODO(ficus): Do we need this or is it okay since API 8 doesn't support it?
            // decodeOptions.inPreferQualityOverSpeed = PREFER_QUALITY_OVER_SPEED;
            decodeOptions.inSampleSize =
                findBestSampleSize(actualWidth, actualHeight, desiredWidth, desiredHeight);
            Bitmap tempBitmap =
                BitmapFactory.decodeByteArray(data, 0, data.length, decodeOptions);

            // If necessary, scale down to the maximal acceptable size.
            if (tempBitmap != null && (tempBitmap.getWidth() > desiredWidth ||
                    tempBitmap.getHeight() > desiredHeight)) {
                bitmap = Bitmap.createScaledBitmap(tempBitmap,
                        desiredWidth, desiredHeight, true);
                tempBitmap.recycle();
            } else {
                bitmap = tempBitmap;
            }
        }

        if (bitmap == null) {
            return Response.error(new ParseError(response));
        } else {
            return Response.success(bitmap, HttpHeaderParser.parseCacheHeaders(response));
        }
    }

我們看到,它產生了一個response對象返回給了上層,最後再由Delivery來分發Reponse.其實我們可以看出,整個Volley的Cache設計相對簡單,而且還有很大的改造空間。比如,對於Delivery的分發機制,完全可以用EventBus這類的事件驅動的框架來完成。還有Bitmap的生成,可以采用內存映射文件的方式來減少內存開銷。當然，這些小甜點並不影響Volley做為一個非常優秀的代碼而存在。在Volley裡面Delivery的本質是一個線程池,采用線程池post的方式可以有效的避免Volley的CacheDispatcher和NetWorkDispatcher因為處理reponse而造成的線程阻塞。

我們再回頭看看如果我們在Cache中不存在,我們請求網絡的情況。Volley對平台的請求接口進行了封裝,你可能采用的是HttpClient,當然也有可能是直接使用HttpUrlConnection。對於上層來說,為了屏蔽掉這種平台的差異性,抽象出一個叫做Network的網絡接口,這是一種橋接的模式。而當你使用某種方式網絡獲得數據以後,NetworkDispatcher將數據put到Cache中.通過Delivery分發Request回調以後,調用Request的finish方法將自己從RequestQueue的暫存表中刪除。

好的,是不是覺得Volley代碼設計的是如此的思路清晰,本章我們先介紹Volley的主體結構,下面會通過兩章節來描述Volley的兩大模塊:Cache和Network設計。

thx

非子墨

QQ:1025250620