·# 內(nèi)存
對(duì)用戶體驗(yàn)影響
- 可能oom
- 內(nèi)存過大被LMK機(jī)制殺死。
- 內(nèi)存抖動(dòng)造成程序卡頓
原理
內(nèi)存分配策略
首先我們來(lái)了解程序運(yùn)行時(shí)，所需內(nèi)存的分配策略：
按照編譯原理的觀點(diǎn),程序運(yùn)行時(shí)的內(nèi)存分配有三種策略,分別是靜態(tài)的,棧式的,和堆式的，對(duì)應(yīng)的际看，三種存儲(chǔ)策略使用的內(nèi)存空間主要分別是靜態(tài)存儲(chǔ)區(qū)（也稱方法區(qū)）拼卵、堆區(qū)和棧區(qū)额衙。他們的功能不同史汗，對(duì)他們使用方式也就不同琼掠。
靜態(tài)存儲(chǔ)區(qū)（方法區(qū)）：內(nèi)存在程序編譯的時(shí)候就已經(jīng)分配好，這塊內(nèi)存在程序整個(gè)運(yùn)行期間都存在停撞。它主要存放靜態(tài)數(shù)據(jù)瓷蛙、全局static數(shù)據(jù)和常量。
棧區(qū)：在執(zhí)行函數(shù)時(shí)怜森，函數(shù)內(nèi)局部變量的存儲(chǔ)單元都可以在棧上創(chuàng)建速挑，函數(shù)執(zhí)行結(jié)束時(shí)這些存儲(chǔ)單元自動(dòng)被釋放。棧內(nèi)存分配運(yùn)算內(nèi)置于處理器的指令集中副硅，效率很高姥宝，但是分配的內(nèi)存容量有限。
堆區(qū)：亦稱動(dòng)態(tài)內(nèi)存分配恐疲。程序在運(yùn)行的時(shí)候用malloc或new申請(qǐng)任意大小的內(nèi)存腊满，程序員自己負(fù)責(zé)在適當(dāng)?shù)臅r(shí)候用free或delete釋放內(nèi)存（Java則依賴?yán)厥掌鳎?dòng)態(tài)內(nèi)存的生存期可以由我們決定培己，如果我們不釋放內(nèi)存碳蛋，程序?qū)⒃谧詈蟛裴尫诺魟?dòng)態(tài)內(nèi)存。 但是省咨，良好的編程習(xí)慣是：如果某動(dòng)態(tài)內(nèi)存不再使用肃弟，需要將其釋放掉。
在函數(shù)中（說明是局部變量）定義的一些基本類型的變量和對(duì)象的引用變量都是在函數(shù)的棧內(nèi)存中分配零蓉。當(dāng)在一段代碼塊中定義一個(gè)變量時(shí)笤受，java就在棧中為這個(gè)變量分配內(nèi)存空間，當(dāng)超過變量的作用域后敌蜂，java會(huì)自動(dòng)釋放掉為該變量分配的內(nèi)存空間箩兽，該內(nèi)存空間可以立刻被另作他用。
堆內(nèi)存用于存放所有由new創(chuàng)建的對(duì)象（內(nèi)容包括該對(duì)象其中的所有成員變量）和數(shù)組章喉。在堆中分配的內(nèi)存汗贫，由java虛擬機(jī)自動(dòng)垃圾回收器來(lái)管理。在堆中產(chǎn)生了一個(gè)數(shù)組或者對(duì)象后秸脱，還可以在棧中定義一個(gè)特殊的變量落包，這個(gè)變量的取值等于數(shù)組或者對(duì)象在堆內(nèi)存中的首地址，在棧中的這個(gè)特殊的變量就變成了數(shù)組或者對(duì)象的引用變量撞反，以后就可以在程序中使用棧內(nèi)存中的引用變量來(lái)訪問堆中的數(shù)組或者對(duì)象妥色，引用變量相當(dāng)于為數(shù)組或者對(duì)象起的一個(gè)別名，或者代號(hào)遏片。
堆是不連續(xù)的內(nèi)存區(qū)域（因?yàn)橄到y(tǒng)是用鏈表來(lái)存儲(chǔ)空閑內(nèi)存地址嘹害，自然不是連續(xù)的），堆大小受限于計(jì)算機(jī)系統(tǒng)中有效的虛擬內(nèi)存（32bit系統(tǒng)理論上是4G）吮便，所以堆的空間比較靈活笔呀，比較大。棧是一塊連續(xù)的內(nèi)存區(qū)域髓需，大小是操作系統(tǒng)預(yù)定好的许师，windows下棧大小是2M（也有是1M，在編譯時(shí)確定僚匆，VC中可設(shè)置）微渠。
為什么內(nèi)存泄漏
為了判斷Java中是否有內(nèi)存泄露，我們首先必須了解Java是如何管理（堆）內(nèi)存的咧擂。Java的內(nèi)存管理就是對(duì)象的分配和釋放問題逞盆。在Java中，內(nèi)存的分配是由程序完成的松申，而內(nèi)存的釋放是由垃圾收集器(Garbage Collection云芦，GC)完成的，程序員不需要通過調(diào)用函數(shù)來(lái)釋放內(nèi)存贸桶，但它只能回收無(wú)用并且不再被其它對(duì)象引用的那些對(duì)象所占用的空間舅逸。
Java的內(nèi)存垃圾回收機(jī)制是從程序的主要運(yùn)行對(duì)象(如靜態(tài)對(duì)象/寄存器/棧上指向的堆內(nèi)存對(duì)象等)開始檢查引用鏈，當(dāng)遍歷一遍后得到上述這些無(wú)法回收的對(duì)象和他們所引用的對(duì)象鏈皇筛，組成無(wú)法回收的對(duì)象集合琉历，而其他孤立對(duì)象（集）就作為垃圾回收。GC為了能夠正確釋放對(duì)象水醋，必須監(jiān)控每一個(gè)對(duì)象的運(yùn)行狀態(tài)旗笔，包括對(duì)象的申請(qǐng)、引用离例、被引用换团、賦值等，GC都需要進(jìn)行監(jiān)控宫蛆。監(jiān)視對(duì)象狀態(tài)是為了更加準(zhǔn)確地艘包、及時(shí)地釋放對(duì)象，而釋放對(duì)象的根本原則就是該對(duì)象不再被引用耀盗。
在Java中想虎，這些無(wú)用的對(duì)象都由GC負(fù)責(zé)回收，因此程序員不需要考慮這部分的內(nèi)存泄露叛拷。雖然舌厨，我們有幾個(gè)函數(shù)可以訪問GC，例如運(yùn)行GC的函數(shù)System.gc()忿薇，但是根據(jù)Java語(yǔ)言規(guī)范定義裙椭，該函數(shù)不保證JVM的垃圾收集器一定會(huì)執(zhí)行躏哩。因?yàn)椴煌腏VM實(shí)現(xiàn)者可能使用不同的算法管理GC。通常GC的線程的優(yōu)先級(jí)別較低揉燃。JVM調(diào)用GC的策略也有很多種扫尺，有的是內(nèi)存使用到達(dá)一定程度時(shí)，GC才開始工作炊汤，也有定時(shí)執(zhí)行的正驻，有的是平緩執(zhí)行GC，有的是中斷式執(zhí)行GC抢腐。但通常來(lái)說姑曙，我們不需要關(guān)心這些。
堆內(nèi)存中的長(zhǎng)生命周期的對(duì)象持有短生命周期對(duì)象的強(qiáng)/軟引用迈倍，盡管短生命周期對(duì)象已經(jīng)不再需要伤靠，但是因?yàn)殚L(zhǎng)生命周期對(duì)象持有它的引用而導(dǎo)致不能被回收，這就是Java中內(nèi)存泄露的根本原因`授瘦。
內(nèi)存泄漏常見原因
集合類
集合類如果僅僅有添加元素的方法醋界，而沒有相應(yīng)的刪除機(jī)制，導(dǎo)致內(nèi)存被占用提完。如果這個(gè)集合類是全局性的變量 (比如類中的靜態(tài)屬性形纺，全局性的 map 等即有靜態(tài)引用或 final 一直指向它)，那么沒有相應(yīng)的刪除機(jī)制徒欣，很可能導(dǎo)致集合所占用的內(nèi)存只增不減逐样。
Android 組件或特殊集合對(duì)象的使用
BroadcastReceiver，ContentObserver打肝，F(xiàn)ileObserver脂新，Cursor，Callback等在 Activity onDestroy 或者某類生命周期結(jié)束之后一定要 unregister 或者 close 掉粗梭，否則這個(gè) Activity 類會(huì)被 system 強(qiáng)引用争便，不會(huì)被內(nèi)存回收。
不要直接對(duì) Activity 進(jìn)行直接引用作為成員變量断医，如果不得不這么做滞乙，請(qǐng)用 private WeakReference mActivity 來(lái)做，相同的鉴嗤，對(duì)于Service 等其他有自己聲明周期的對(duì)象來(lái)說斩启，直接引用都需要謹(jǐn)慎考慮是否會(huì)存在內(nèi)存泄露的可能。
Handler
要知道醉锅，只要 Handler 發(fā)送的 Message 尚未被處理兔簇，則該 Message 及發(fā)送它的 Handler 對(duì)象將被線程 MessageQueue 一直持有。由于 Handler 屬于 TLS(Thread Local Storage) 變量, 生命周期和 Activity 是不一致的。因此這種實(shí)現(xiàn)方式一般很難保證跟 View 或者 Activity 的生命周期保持一致垄琐，故很容易導(dǎo)致無(wú)法正確釋放边酒。如上所述，Handler 的使用要尤為小心此虑，否則將很容易導(dǎo)致內(nèi)存泄露的發(fā)生甚纲。
Thread 內(nèi)存泄露
線程也是造成內(nèi)存泄露的一個(gè)重要的源頭口锭。線程產(chǎn)生內(nèi)存泄露的主要原因在于線程生命周期的不可控朦前。比如線程是 Activity 的內(nèi)部類，則線程對(duì)象中保存了 Activity 的一個(gè)引用鹃操，當(dāng)線程的 run 函數(shù)耗時(shí)較長(zhǎng)沒有結(jié)束時(shí)韭寸，線程對(duì)象是不會(huì)被銷毀的，因此它所引用的老的 Activity 也不會(huì)被銷毀荆隘，因此就出現(xiàn)了內(nèi)存泄露的問題恩伺。
異步線程未完成前退出 Activity 等組件，可能會(huì)導(dǎo)致界面資源無(wú)法釋放椰拒。
這種情況是典型的線程對(duì)象導(dǎo)致的內(nèi)存泄露晶渠。原因也很簡(jiǎn)單，線程 Thread 對(duì)象的 run 任務(wù)未執(zhí)行完之前燃观，對(duì)象本身是不會(huì)釋放的褒脯。因此 Activity 等組件對(duì)象內(nèi)的線程對(duì)象成員如果有耗時(shí)任務(wù)（一般也都是耗時(shí)任務(wù)），就會(huì)導(dǎo)致一直持有組件本身的引用內(nèi)存泄露缆毁！
本文部分內(nèi)容和經(jīng)驗(yàn)摘自網(wǎng)絡(luò)番川，結(jié)合本次內(nèi)存泄露的排查總結(jié)予以歸納
工具
AS的Memory窗口
可以圖表的方式顯示內(nèi)存情況 － 空閑內(nèi)存 & 已使用內(nèi)存.
adb shell dumpsys meminfo com.mogujie
非常好的工具 可以顯示java heap 、 native heap脊框、共享內(nèi)存颁督、堆棧信息。
MAT
Eclipse Memory Analysis Tools（點(diǎn)我下載）是一個(gè)專門分析Java堆數(shù)據(jù)內(nèi)存引用的工具浇雹，我們可以使用它方便的定位內(nèi)存泄露原因沉御，核心任務(wù)就是找到GC ROOT位置即可，哎呀昭灵，關(guān)于這個(gè)工具的使用我是真的不想說了吠裆，自己搜索吧，實(shí)在簡(jiǎn)單虎锚、傳統(tǒng)的不行了硫痰。
PS：這是開發(fā)中使用頻率非常高的一個(gè)工具之一，麻煩務(wù)必掌握其核心使用技巧
DDMS-Heap
DDMS 自帶的內(nèi)存分析工具 比較簡(jiǎn)單 使用頻度不高
leakcanary
leakcanary是一個(gè)開源項(xiàng)目窜护，一個(gè)內(nèi)存泄露自動(dòng)檢測(cè)工具效斑，是著名的GitHub開源組織Square貢獻(xiàn)的，它的主要優(yōu)勢(shì)就在于自動(dòng)化過早的發(fā)覺內(nèi)存泄露柱徙、配置簡(jiǎn)單缓屠、抓取貼心奇昙，缺點(diǎn)在于還存在一些bug，不過正常使用百分之九十情況是OK的敌完，其核心原理與MAT工具類似储耐。
監(jiān)控
目前沒有對(duì)內(nèi)存進(jìn)行有效的監(jiān)控。
線上oom 統(tǒng)計(jì)
對(duì)線上所有發(fā)生的oom進(jìn)行統(tǒng)計(jì)滨溉，同時(shí)記錄所有的activity的調(diào)用周期 和 可能的內(nèi)存泄漏場(chǎng)景
線上內(nèi)存統(tǒng)計(jì)
統(tǒng)計(jì)每個(gè)ativity的內(nèi)存使用情況
其他
優(yōu)化點(diǎn)
兜底回收內(nèi)存
Activity泄漏會(huì)導(dǎo)致該Activity引用到的Bitmap什湘、DrawingCache等無(wú)法釋放，對(duì)內(nèi)存造成大的壓力晦攒，兜底回收是指對(duì)于已泄漏Activity闽撤，嘗試回收其持有的資源，泄漏的僅僅是一個(gè)Activity空殼脯颜，從而降低對(duì)內(nèi)存的壓力哟旗。
做法也非常簡(jiǎn)單，在Activity onDestory時(shí)候從view的rootview開始栋操，遞歸釋放所有子view涉及的圖片闸餐，背景，DrawingCache矾芙，監(jiān)聽器等等資源舍沙，讓Activity成為一個(gè)不占資源的空殼，泄露了也不會(huì)導(dǎo)致圖片資源被持有蠕啄。
fresco
使用fresco场勤，圖片信息保存到共享內(nèi)存上。減少java heap使用
圖片按需加載
即圖片的大小不應(yīng)該超過view的大小歼跟。在把圖片載入內(nèi)存之前和媳，我們需要先計(jì)算出一個(gè)合適的inSampleSize縮放比例，避免不必要的大圖載入哈街。對(duì)此留瞳，我們可以重載drawable與ImageView，例如在Activity ondestroy時(shí)骚秦，檢測(cè)圖片大小與View的大小她倘，若超過可以上報(bào)或提示。
oom處理
我們可以在加載bitmap時(shí)作箍，若發(fā)生OOM(try catch方式)硬梁，可以通過清除cache，降低bitmap format(ARGB8888/RBG565/ARGB4444/ALPHA8)等方式胞得，重新嘗試荧止。
低內(nèi)存處理
對(duì)于系統(tǒng)函數(shù)onLowMemory等函數(shù)是針對(duì)整個(gè)系統(tǒng)而已的，對(duì)于本進(jìn)程來(lái)說，其dalvik內(nèi)存距離OOM的差值并沒有體現(xiàn)跃巡，也沒有回調(diào)函數(shù)供我們及時(shí)釋放內(nèi)存危号。假若能有那么一套機(jī)制，可以實(shí)時(shí)監(jiān)控進(jìn)程的堆內(nèi)存使用率素邪，達(dá)到設(shè)定值即關(guān)于通知相關(guān)模塊進(jìn)行內(nèi)存釋放外莲，這會(huì)大大的降低OOM。
? 實(shí)現(xiàn)原理
這個(gè)其實(shí)比較簡(jiǎn)單兔朦，通過Runtime獲得maxMemory,而totalMemory-freeMemory即為當(dāng)前真正使用的dalvik內(nèi)存偷线。
Runtime.getRuntime().maxMemory();
Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory()；
? 操作方式
我們可以定期(前臺(tái)每隔3分鐘)去得到這個(gè)值烘绽，當(dāng)我們這個(gè)值達(dá)到危險(xiǎn)值時(shí)(例如80%)淋昭，我們應(yīng)當(dāng)主要去釋放我們的各種cache資源(bitmap的cache為大頭)，同時(shí)顯示的去Trim應(yīng)用的memory,加速內(nèi)存收集安接。
WindowManagerGlobal.getInstance().startTrimMemory(TRIM_MEMORY_COMPLETE);
多進(jìn)程
對(duì)于webview，圖庫(kù)等英融，由于存在內(nèi)存系統(tǒng)泄露或者占用內(nèi)存過多的問題盏檐，我們可以采用單獨(dú)的進(jìn)程。微信當(dāng)前也會(huì)把它們放在單獨(dú)的tools進(jìn)程中
代碼實(shí)踐
對(duì) Activity 等組件的引用應(yīng)該控制在 Activity 的生命周期之內(nèi)驶悟； 如果不能就考慮使用 getApplicationContext 或者 getApplication胡野，以避免 Activity 被外部長(zhǎng)生命周期的對(duì)象引用而泄露
警惕線程未終止造成的內(nèi)存泄露；譬如在Activity中關(guān)聯(lián)了一個(gè)生命周期超過Activity的Thread痕鳍，在退出Activity時(shí)切記結(jié)束線程硫豆。一個(gè)典型的例子就是HandlerThread的run方法是一個(gè)死循環(huán)，它不會(huì)自己結(jié)束笼呆，線程的生命周期超過了Activity生命周期熊响，我們必須手動(dòng)在Activity的銷毀方法中中調(diào)運(yùn)thread.getLooper().quit();才不會(huì)泄露。
對(duì)象的注冊(cè)與反注冊(cè)沒有成對(duì)出現(xiàn)造成的內(nèi)存泄露诗赌；譬如注冊(cè)廣播接收器汗茄、注冊(cè)觀察者（典型的譬如數(shù)據(jù)庫(kù)的監(jiān)聽）等。
創(chuàng)建與關(guān)閉沒有成對(duì)出現(xiàn)造成的泄露铭若；譬如Cursor資源必須手動(dòng)關(guān)閉洪碳，WebView必須手動(dòng)銷毀，流等對(duì)象必須手動(dòng)關(guān)閉等叼屠。
在代碼復(fù)審的時(shí)候關(guān)注長(zhǎng)生命周期對(duì)象：全局性的集合瞳腌、單例模式的使用、類的 static 變量等等镜雨。
線程 Runnable 執(zhí)行耗時(shí)操作嫂侍，注意在頁(yè)面返回時(shí)及時(shí)取消或者把 Runnable 寫成靜態(tài)類。
a) 如果線程類是內(nèi)部類，改為靜態(tài)內(nèi)部類吵冒。
b) 線程內(nèi)如果需要引用外部類對(duì)象如 context纯命，需要使用弱引用
Handler 的持有的引用對(duì)象最好使用弱引用，資源釋放時(shí)也可以清空 Handler 里面的消息痹栖。比如在 Activity onStop 或者 onDestroy 的時(shí)候亿汞，取消掉該 Handler 對(duì)象的 Message和 Runnable.
總結(jié)
我們并不能將內(nèi)存優(yōu)化中用到的所有技巧都一一說明，而且隨著Android版本的更替揪阿，可能很多方法都會(huì)變的過時(shí)疗我。我在想更重要的是我們能持續(xù)的發(fā)現(xiàn)問題，精細(xì)化的監(jiān)控南捂，而不是一直處于"哪個(gè)有坑填哪里的"的窘?jīng)r吴裤。在這里給大家的建議有：
1 率先考慮采用已有的工具；中國(guó)人喜歡重復(fù)造輪子溺健，我們更推薦花精力去優(yōu)化已有工具麦牺，為廣大碼農(nóng)做貢獻(xiàn)。生活已不易鞭缭，碼農(nóng)何為為難碼農(nóng)剖膳！
2 不拘泥于點(diǎn)，更重要在于如何建立合理的框架避免發(fā)生問題岭辣，或者是能及時(shí)的發(fā)現(xiàn)問題吱晒。
