內(nèi)存泄漏：對象在內(nèi)存heap堆中中分配的控件幔托，但不再使用或沒有引用指向的情況下票编，仍不能被GC正惩ǎ回收的情況。多數(shù)出現(xiàn)在不合理的編碼情況下兑障，比如在Activity中注冊了一個廣播接收器侄非，但是在頁面關(guān)閉的時候進(jìn)行unRegister（或者說以下一些內(nèi)存泄漏的情況）就會出現(xiàn)內(nèi)存溢出的現(xiàn)象。通常情況下流译，大量的內(nèi)存泄漏會造成OMM.

OOM:即OutOfMemoery,顧名思義就是指內(nèi)存溢出了逞怨。內(nèi)存溢出是指APP向系統(tǒng)申請超過最大閥值的內(nèi)存請求，系統(tǒng)不會再分配多余的空間福澡，就會造成OOM error叠赦。在我們Android平臺下，多數(shù)情況是出現(xiàn)在圖片不當(dāng)處理加載的時候革砸。

內(nèi)存管理之道除秀，無非就是先理解并找出內(nèi)存泄漏的原因，在基于這些反式去合理的編碼算利，去防范進(jìn)而避免內(nèi)存開銷過大的情形册踩。學(xué)習(xí)如何合理的管理內(nèi)存，最好先了解內(nèi)存分配的機(jī)制和原理（效拭？暂吉？？）缎患。只有深層次的理解了內(nèi)部的原理借笙，才能真正避免OOM的發(fā)生。

Android App因?yàn)閍ndroid是開源系統(tǒng)较锡，不同的手機(jī)廠商其實(shí)是具有修改這部分權(quán)限能力的业稼，所以就造成了不同品牌和不同系統(tǒng)的手機(jī)，對于APP的內(nèi)存支持也是不一樣的蚂蕴，和iOS的恒久100MB是不同的低散。一般來說俯邓，手機(jī)內(nèi)存的配置越高，廠商也會調(diào)大手機(jī)支持的內(nèi)存最大閥值熔号，無法保證APP運(yùn)行在何種手機(jī)上稽鞭，只能從編碼角度來優(yōu)化內(nèi)存了。

下面我們來逐條來分析Android內(nèi)存優(yōu)化的關(guān)鍵點(diǎn)引镊。

1朦蕴、萬惡的static
static是個好東西，聲明賦值調(diào)用就是那么簡單方便弟头，但是伴隨而來的還有性能問題吩抓。由于static聲明變量的聲明周期其實(shí)是和APP的生命周期一樣的，有點(diǎn)類似與Application赴恨。如果大量的使用的話疹娶，就會占據(jù)內(nèi)存空間不釋放，積少成多也會造化曾內(nèi)存的不斷開銷伦连，直至掛掉雨饺。static的合理使用一般用來修飾基本數(shù)據(jù)類型或者輕量級對象，盡量避免修復(fù)集合或者大度想惑淳，常用作修飾全局配置項(xiàng)额港、工具類方法、內(nèi)部類歧焦。

2移斩、無關(guān)引用
很多情況下，我們需求用到傳遞引用倚舀，但是我們無法確保引用傳遞出去后能否及時的回收叹哭。比如比較有代表性的Context泄漏，很多情況下當(dāng)Activity結(jié)束掉后痕貌，由于仍被其他的對象指向?qū)е乱恢边t遲不能回收风罩，這就造成了內(nèi)存泄漏。這時可以考慮第三條建議舵稠。

3超升、善用SoftReference/WeakReference/LruCache（？哺徊？室琢？）
Java、Android在中有沒有這樣一種機(jī)制呢落追，當(dāng)內(nèi)存吃緊或者GC掃過的情況下盈滴，就能及時把一些內(nèi)存占用給釋放掉，從而分配給需要分配的地方。答案是肯定的巢钓，java為我們提供了兩個解決方案病苗。如果對內(nèi)存的開銷比較關(guān)注的App，可以考慮使用WeakReference症汹，當(dāng)GC回收掃過這塊內(nèi)存區(qū)域時就會回收硫朦；如果不是那么關(guān)注的話，可以使用SoftReference背镇，它會在內(nèi)存申請不足的情況下自動釋放咬展，同樣也能解決OOM問題。Android自3.0以后也推出了LruCache類瞒斩，使用LRU算法就釋放內(nèi)存破婆，一樣的能解決OOM,如果兼容3.0一下的版本，請導(dǎo)入v4包济瓢。關(guān)于 第二條的無關(guān)引用的問題荠割，我們傳參可以考慮使用WeakReference包裝一下妹卿。

4旺矾、謹(jǐn)慎handler
在處理異步操作的時候哦，handler+thread是個不錯的選擇夺克。但是相信在使用handler的時候箕宙，大家都會遇到警告的情形，這個就是lint為開發(fā)者的體型铺纽。handler運(yùn)行與UI線程柬帕，不斷處理來自MessageQueue的消息，如果handler還有信息需要處理但是Activity頁面已經(jīng)結(jié)束的情況下狡门，Activity的引用其實(shí)并不會被回收陷寝，這就造成了內(nèi)存泄漏。解決方案其馏，一是在Activity的onDestroy方法中調(diào)用
handler.removeCallbacksAndMessages(null);取消所有的消息的處理凤跑，包括待處理的消息，二是聲明handler的內(nèi)部類為static叛复。

5仔引、Bitmap終極殺手
Bitmap的不當(dāng)處理極可能造成OOM，絕大多數(shù)情況都是因這個原因出現(xiàn)的褐奥。Bitmap位圖是Android中當(dāng)之無愧的胖小子咖耘，所以在操作的時候當(dāng)然是十分的小心了。由于Dalivk并不會主動的去回收撬码，需要開發(fā)者在Bitmap不被使用的時候recycle掉儿倒。使用的過程中，及時釋放是非常重要的呜笑。同時如果需求允許夫否，也可以去Bitmap進(jìn)行一定的縮放找筝，通過BitmapFactory.Options的inSampleSize屬性進(jìn)行控制。如果僅僅只想獲得Bitmap的屬性慷吊，其實(shí)并不需要根據(jù)Bitmap的像素去分配內(nèi)存袖裕，只需在解析讀取Bmp的時候使用BitmapFactory.Options的inJustDecodeBounds屬性。隨后建議大家在加載網(wǎng)絡(luò)圖片的時候溉瓶，使用軟引用或者弱引用并進(jìn)行本地緩存急鳄，推薦使用
android-universal-imageloader或者xUtils.

6、Cursor和I/O流及時關(guān)閉堰酿，在查詢SQLite數(shù)據(jù)庫時疾宏，會返回一個Cursor，當(dāng)查詢完畢后触创，及時關(guān)閉坎藐，這樣就可以把查詢的結(jié)果集及時給回收掉，I/O流操作關(guān)閉哼绑，讀取結(jié)束岩馍，記得關(guān)閉。

7抖韩、ListView item的緩存問題

8蛀恩、頁面背景和圖片加載

在布局和代碼中設(shè)置背景和圖片的時候，如果是純色茂浮，盡量使用color双谆，如果是規(guī)則圖形，盡量使用shape畫圖席揽；如果稍微復(fù)雜點(diǎn)顽馋，可以使用9patch圖；如果不能使用9patch的情況下幌羞，針對幾種主流分辨率的機(jī)型進(jìn)行切圖寸谜。
9、BroadCastReceiver新翎、Service
綁定廣播和服務(wù)程帕，一定要記得在不需要的時候給解綁。
10地啰、線程
線程不再需要繼續(xù)執(zhí)行的時候要記得及時關(guān)閉愁拭，開啟線程數(shù)量不易過多，一般和自己機(jī)器內(nèi)核數(shù)一樣最好亏吝，推薦開啟線程的時候岭埠，使用線程池。
11.String/StringBuffer
當(dāng)有較多的字符創(chuàng)需要拼接的時候，推薦使用StringBuffer惜论。