Android麵試寶典v3.0

Android麵試寶典3.0，內容：JavaSE 基礎，JavaSE 高級，Android 基礎，Android 高級，Android 項目，項目麵試常見問題，麵試實戰記錄，BAT 麵試題，Android 最新技術。

每次看陽哥的麵試寶典都收貨頗多。無論是代碼質量還是語言修辭的銜接，恐怕即便是站在巨人的肩膀上，要追上技術牛人的腳步也要付出常人難以接受的努力吧。

對於這篇麵試總結，簡直喜歡和崇拜的不行。

說了太多的廢話，占了幾段篇幅，還是直接切入重點吧。

對於性能分析，也經常搜索相關資料，恕我才疏學淺，但還是忍不住發表一下觀點。

從內存泄露說起：

先來看看Square公司給出的在Android中內存泄露的解釋：

> What is a memory leak?
Some objects have a limited lifetime. When their job is done, they are expected to be garbage collected. If a chain of references holds an object in memory after the end of its expected lifetime, this creates a memory leak. When these leaks accumulate, the app runs out of memory.
>
For instance, after Activity.onDestroy() is called, the activity, its view hierarchy and their associated bitmaps should all be garbage collectable. If a thread running in the background holds a reference to the activity, then the corresponding memory cannot be reclaimed. This eventually leads to an OutOfMemoryError crash.

大概翻譯就是：

有些對象有一個有限的生命周期，當他們任務結束的時候，應該被GC回收。如果在該對象生命周期結束的時候，仍然有一係列對象hold住了該對象的引用，就會導致內存泄露。隨著泄露的積累，app將內存將消耗殆盡。、
比如Activity.onDestroy( )被回調之後，view層級樹以及關聯的bitmap都應該被GC回收，如果一個正在運行的後台線程hold住了這個activity的引用，與其相關的內存將不會被回收，最終會導致outOfMemoryError崩潰。
從而可見，OOM一般代表著更深層次的問題：Memory Leak

由此可見，內存泄露指的是程序中一些對象不會被GC回收，而始終占用內存，即在對象的引用鏈中變成了可達不可用。而內存溢出是指程序運行期間無法申請足夠的內存而導致的錯誤，可以說內存泄露是內存溢出的一種誘因，但是不唯一因素。

那麼看一下這個著名的誕生於2009年的static Drawable例子，然後在SDK中查看一下曆代SDK版本號，會發現

/**
* December 2009: Android 2.0.1
*/
public static final int ECLAIR_0_1 = 6;


/**
* January 2010: Android 2.1
*/
public static final int ECLAIR_MR1 = 7;

2009年的最後一個版本是2.0.1。2.1版本才出現在2010年，而且這個年代，貌似國內做Android的人少之甚少。


所以隻需要把這些SDK的版本，翻看一遍，確實會發現這個有內存泄露隱患的強引用鏈：

Drawable->TextView->Context

但是如果看一下劃時代的3.0版本（HONEYCOMB），會發現Google的Android小組貌似已經注意到了這個問題，並且修複了它。

由

public final void setCallback(Callback cb) {
mCallback = cb;
}

替換為

public final void setCallback(Callback cb) {
mCallback = new WeakReference(cb);
}

用弱引用來代替強引用，這樣就避免了Context的泄露。

再來說說Bitmap.recycle()。

這個也可以算是一個曆史遺留問題。在3.0版本之前。

Bitmap.java源碼。

// Note: mNativeBitmap is used by FaceDetector_jni.cpp
// Don't change/rename without updating FaceDetector_jni.cpp
private final int mNativeBitmap;

Bitmap的資源是在底層C中處理的，因此3.0之前的.recycle()，並沒有什麼錯。但是在3.0以及之後。
Bitmap.java源碼。

/**
* Backing buffer for the Bitmap.
*/
private byte[] mBuffer;

圖片數據保存在成員變量mBuffer中，也就是說使用Heap存儲代替了底層C處理。因此不用顯式調用.recycle()。隻需要把bitmap置null或者使用虛引用持有就行了。這樣圖片就能被GC回收了。

另外，由於不同版本的SDK，.recycle()注釋也不同，但是有一句話是始終沒有改變的

>This is an advanced call, and normally need not be called, since the normal GC process will free up this memory when there are no more references to this bitmap.

這是一個高級函數，一般情況下沒必要調用，在沒有引用指向bitmap時，GC會自動釋放內存。

而且我的建議是不要頻繁的調用System.gc();因為這在大多情況下隻能顯式提醒GC回收，究竟什麼時候進行回收操作，還是看VM自身的算法和調度。