ActivityがOndestroy()メソッドを呼び出した後、メモリマネージャがなぜ占有リソースを解放しなかったのかについて

最近activityがfinishを実行した後、なぜ多くのリソースが解放されていないのかという問題を研究しています.この原因の発生について、最も直接的な考えはactivityの中に多くのリソースが手動で解放されていないことです.なぜなら、activityは高度に抽象的なUIコンポーネントにすぎません.彼はコントロールインタフェースの機能にすぎません.touchの配布時間を含めて、いくつかの列の役割を果たしています.インタフェースを表示する作業はDecorViewの下にあるすべてのviewおよびview Groupに渡されるので、activityは彼の内部でバインドされたすべてのviewの参照を持っていると考えられますが、これらのviewはactivityの参照だけでなく、他の参照(具体的には他のどの参照があるか、最近も研究されています)もあります.したがって、この原理によれば、activityがondestroyメソッドを実行すると、activityというオブジェクトは確かに回収されますが、オブジェクトバインドのviewは回収されていません.手動で回収する必要があります.

@Override
protected void onDestroy() {
    super.onDestroy();
    fruitList = null ;
    layout_bottom= null ;
    }

例えば、ondestoryメソッドでコントロールを解放する操作を行うと、メモリを占有する比較的大きな空間を解放することができます.これについてはddmsやmatでcause gcでactivityを繰り返し開くときのappのメモリ占有状況を確認することができます.
これだけでは足りません.メモリを見ると、まだ0.数Mのメモリが解放されていないことに気づきました.そこで、多くの資料を調べてみると、contentViewに問題があることに気づきました.ContentViewのバインドXMLメカニズムの内容については「老羅のAndroidの旅」(私も見終わっていないので、問題を解決してくれるところを見ただけでブログを書きに来ました.恥ずかしいです.)を見に行くことができます.そこでネット上で検索して答えを得て、Ondestroyの時setContentView(null)を呼び出すことができなくて、このように異常を報告しやすくて、解決方法は空のlayoutファイルを書いて、それからバインドします.変更後のondestryメソッドは次のとおりです.

@Override
protected void onDestroy() {
    super.onDestroy();
    this.setContentView(R.layout.empty_view);
    fruitList = null ;
    layout_bottom= null ;
    }

また、毎回バインドされたviewを解放するのが面倒なので、遍歴ですべてのviewを直接解放できるかどうかを尋ねる人もいますが、この方法は試したことがありますが、成功しませんでした.次に、これらのviewの引用を持っているオブジェクトを研究して、別の方法で解放します.
自分の記憶だけに供する.間違いがあれば指摘を歓迎します.△皆さん、態度がいいですね...