關於Activity呼叫Ondestroy（）方法之後記憶體管理器為什麼沒有釋放佔用資源
最近在研究activity 執行了finish之後為什麼還有很多資源沒有釋放的問題，關於這個原因的產生，最直接的想法就是activity裡面還有很多資源沒有手動釋放，因為大家知道,activity只不過是一個高度抽象的UI元件，他僅僅只是一個控制介面的功能，包括分發touch時間還有一些列的作用，展示介面的工作是交給DecorView下的所有view以及viewGroup，所以我們可以認為activity持有了所有在他內部繫結的view的引用，但是這些view不僅僅只有activity的引用，還有其他的引用（具體還有其他的哪些引用，最近仍舊在研究。），所以根據這個原理，當activity執行ondestroy方法的時候，activity這個物件確實是被回收了，但是物件繫結的view卻沒有被回收，我們還需要手動去回收他們。
| 1 2 3 4 5 6 |
@Override
protected void onDestroy() {
super.onDestroy();
fruitList = null ;
layout_bottom= null ;
}
|
比如類似這樣的，在ondestory方法裡面做釋放控制元件的操作，這樣我們就可以把佔用記憶體比較大的那些空間都釋放出來，關於這個大家可以通過ddms 或者 mat來 cause gc 檢視 反覆開啟一個activity的時候 app的記憶體佔用情況。
光做到以上這點還是不夠的，因為通過檢視記憶體我發現還有零點幾M的記憶體仍然沒有被釋放，於是又查了很多資料，發現問題出在contentView上面，關於ContentView的繫結XML機制的內容大家可以去看《老羅的Android之旅》(由於我也沒有看完，只是看到了可以給我解決問題的地方就來寫部落格了。。慚愧一個。)，於是網上搜索得到答案，不能在Ondestroy的時候呼叫setContentView（null），這樣很容易報異常的，解決方法是寫一個空的layout檔案，然後繫結。經過修改之後的ondestry方法如下：
| 1 2 3 4 5 6 7 |
@Override
protected void onDestroy() {
super.onDestroy();
this.setContentView(R.layout.empty_view);
fruitList = null ;
layout_bottom= null ;
}
|
另外其實每次都要把繫結的view給釋放掉這樣很麻煩，有人就問能不能直接通過遍歷把所有的view都釋放，這個方法嘗試過，但是沒能成功，接下來我會研究還有哪些物件持有了這些view的引用，然後用另外一種方式釋放。
僅供自己記憶。如有錯誤歡迎指正。（大家態度好一點。。。）