一、Volley框架簡介
在這之前，我們在法度榜樣中須要和收集通信的時刻，大年夜體應用的器械莫過于AsyncTaskLoader，HttpURLConnection，AsyncTask，HTTPClient（Apache）等，Google 在2013年的I/O大年夜會 上，宣布了Volley。Volley是Android平滔喔贍收集通信庫，能使收集通信更快，更簡單，更結實。
Volley供給了JsonObjectRequest、JsonArrayRequestStringRequest等Request情勢
public class SingleRequestQueue {
JsonObjectRequest：返回JSON對象
JsonArrayRequest：返回JsonArray。
別的可以持續(xù)自定義Request。
二、VOlley引起的OOM項目頂用到Volley下載收集圖片，在回調(diào)中獲取到bitmap做響應地操作。
       ImageRequest imageRequest = new ImageRequest(url+"--"+ bmWidth+"x"+bmWidth+".png",                new Response.Listener<Bitmap>() {                    @Override                    public void onResponse(Bitmap response) {                        initViewWithBitmap(response);                    }                }, 0, 0, Bitmap.Config.RGB_565, getImageError);        mQueue.add(imageRequest);
起先發(fā)明在這個界面操作偶先強關問題，抓到log看下是 outofmemory引起的。
因為該界面用到bitmap的處所比較多，所以在onDestoy()辦法中手動釋放bitmap。
用內(nèi)存查看器不雅察該界面的內(nèi)存情況，發(fā)明每次進入退出后，內(nèi)存并沒有完全釋放，大年夜概每次都來6M閣下
經(jīng)由過程這個問題的分析解決，加深了內(nèi)存泄漏的分析思路，同時也鞏固了MAT內(nèi)存分析對象的應用辦法。
三、問題分析
對象：MAT內(nèi)存分析對象
用MAT內(nèi)存分析對象，找出引起內(nèi)存沒有釋放的原因

    private static RequestQueue mQueue;

    private SingleRequestQueue(Context context) {
        mQueue = Volley.newRequestQueue(context);
    }

    public static synchronized RequestQueue getRequestQueue(Context context){
        if (mQueue == null){
            new SingleRequestQueue(context.getApplicationContext());
        }
        return mQueue;
    }
}

[img]http://img.blog.csdn.net/20150106150626576?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvaGxnbGluZ2xvbmc=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center

發(fā)明是context沒有釋放，導致內(nèi)存泄漏，持續(xù)分析，找到?jīng)]有引起GC的保持該引用的處所
[img]http://img.blog.csdn.net/20150106150629375?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvaGxnbGluZ2xvbmc=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center

找到最短的GC path，發(fā)明是Volley中德CacheDispacher保持了context的引用，導致沒有引起GC釋放內(nèi)存。
[img]http://img.blog.csdn.net/20150106150728109?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvaGxnbGluZ2xvbmc=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center
在同一一個類中處理收集請求。

然則volley框架內(nèi)的器械怎么會引起這種問題？
起首想到在onDestroy中撤消掉落沒有加載完的request。然則沒有效不雅
google 了半天，終于在stackoverflow上找到了謎底，大年夜概的意思就是說，初始化RequestQueue的時刻盡量應用全局的Context也就是ApplicationContext。
不然的話沒有Activity都要保護一個volley請求隊列以及分發(fā)線程、請求線程懈弛存線程。
如許就會導致，在volley框架的內(nèi)部保持了一個Activity的context引用，也就是說，當我們的Activity的生命周期停止了之后，volley中可能還有沒走完的子線程中依然保存該context的引用，導致無法內(nèi)存收受接收。
四、解決辦法
StringRequest：返回String，如許可以本身處理數(shù)據(jù)，加倍靈活
起首，我們要保持項目中獨一一個Volley的RequestQueue，應用單例模式來實現(xiàn)

別的，看到網(wǎng)上評論說當加載大年夜的收集圖片的時刻不建議應用Volley，我用的是UniversalImageLoader。
推薦一篇文┞仿講解Android 中Context。點這里
總結：
之前一向沒有碰到context高低文內(nèi)存泄漏的問題，這個問題很好地彌補了這方面的空白