~關於內存溢出的一些想法（Android）

最近看了一些資料，對android的程序的內存有一些想法，我提出來，請你們指正,目的是拋磚引玉。

   首先提幾個有意思的問題：

1，若是activty destroy掉的話，那麼這個activty內的view所引用的bitmap回收掉了嗎？

 2，若是activty destroy掉的話，那麼這個acitity所佔用的內存被GC回收了嗎？

   我覺的一個程序中佔用內存的地方有兩個方面：一個是bimap。一個是context(activity).

   一，先說bitmap：這個引發內存溢出比較廣泛。有2個解決方法：

   1，用bitmap的recycle方法，在咱們確認這個bitmap不被使用的時候調用這個方法能夠直接把bitmap所佔用的內存回收掉。不過這個方法的使用的弱點是：若是這個方法調用的時間點不合理，很容易引發 use a recycle bitmap的異常。

   2，用弱引用來管理你的bitmap。具體方法，是把程序裏全部的bitmap對象放到一個靜態的hasmap中，用弱引用來保   存。若是再用到這個bitmap的時候，根據相應的key直接取出來，至關於一個高速緩存池。保證這個程序不會重複建立過多的bitmap對象。此外弱引用對象能夠在系統內存不足的時候自動被系統回收。

   3，設置壓縮參數，對bitmap進行壓縮。以及用反射設置一下bitmap所佔內存的位置（聽說能夠不算到heap中）。

  二， 再說說context： TextView label = new TextView(this); 你們常常這樣建立view，這意味着，TextView 擁有對整個Activity的引用以及Activity自身擁有的全部內容；通常是整個的View層次和它的全部資源。所以，若是你「泄露」了Context（「泄露」指你保留了一個引用，阻止了GC的垃圾回收），，你將泄露不少的內存。若是你不夠仔細的話，很容易就能泄露一個Activity 。    當一個Drawable附加到一個View上時，View會將其做爲一個callback設定到Drawable上。 因此：用activity這個context傳到view的setbackground中，其實就把這個acitity 「泄漏」了，因此有時候咱們destroy掉了這個activity，可是咱們用內存分析工具查看內存的時候，奇怪的發現這個activity並無沒gc回收掉。要避免這個問題有兩個解決方法：

   1，不用activity的context 而是用application的context，這樣acitity能夠適時的被系統回收掉。

   2，在acitity destroy 方法中 解除activity和biamap（drawble）  的綁定關係。去除bitmap對activity 引用的保留，讓系統適時的去回收。

   具體代碼爲

@Override

protected void onDestroy() {

    super.onDestroy();

 

    unbindDrawables(findViewById(R.id.RootView));

    //System.gc();

}

 

private void unbindDrawables(View view) {

    if (view.getBackground() != null) {

        view.getBackground().setCallback(null);

    }

    if (view instanceof ViewGroup) {

        for (int i = 0; i < ((ViewGroup) view).getChildCount(); i++) {

            unbindDrawables(((ViewGroup) view).getChildAt(i));

        }

        ((ViewGroup) view).removeAllViews();

    }

}

說了這麼多哈哈，你覺的我說的對不？

參考資料：http://developer.android.com/resources/articles/avoiding-memory-leaks.html 

          http://www.alonsoruibal.com/bitmap-size-exceeds-vm-budget/