別忘了常來我的 GitHub 看看，有什么好玩的~
內(nèi)存泄漏對每一位 Android 開發(fā)一定是司空見慣狂魔，大家或多或少都肯定有些許接觸蒜埋。大家都知道，每一個手機都有一定的承載上限最楷，多處的內(nèi)存泄漏堆積一定會堆積如山整份，最終出現(xiàn)內(nèi)存爆炸 OOM。
而這籽孙，也是極有可能在 Android 面試中一道常見的開放題皂林。
內(nèi)存泄漏的根本原因是一個長生命周期的對象持有了一個短生命周期的對象。如果你對垃圾回收機制有所了解蚯撩，我想這個問題基本難不住你，因為知道了原理烛占，自然不會去觸碰這些極易導(dǎo)致內(nèi)存泄漏的雷區(qū)胎挎。
該題重在積累，不需要死記硬背忆家，自己多總結(jié)即可犹菇。
1. 長生命周期對象持有 Activity
這基本是最常見的內(nèi)存泄漏了，比如
- 內(nèi)部類形式使用 Handler 同時發(fā)送延時消息芽卿，或者在 Handler 里面執(zhí)行耗時任務(wù)揭芍，在任務(wù)還沒完成的時候 Activity 需要銷毀。這時候由于 Handler 持有 Activity 的強引用導(dǎo)致 Activity 無法被回收卸例。
- 同理內(nèi)部類形式的使用 AsyncTask 執(zhí)行耗時任務(wù)也會導(dǎo)致內(nèi)存泄漏的發(fā)生称杨。
- 單例作為最長生命周期的對象，自然不應(yīng)該持有 Activity 從而導(dǎo)致內(nèi)存泄漏發(fā)生筷转；
針對上面這種情況姑原，基本不必多說了，不要使用內(nèi)部類或者匿名內(nèi)部類做這樣的處理就好了呜舒，實際上 IDE 也會彈出警告锭汛，我想大家應(yīng)該還是都知道采用靜態(tài)內(nèi)部類或者在銷毀頁面的時候使用相關(guān)方法移除處理的。實際上，使用 Kotlin 或者 Java 8 的 Lambda 表達(dá)式同樣不會導(dǎo)致內(nèi)存泄漏的發(fā)生唤殴，這是因為實際上它也是使用的靜態(tài)內(nèi)部類般婆，沒有持有外部引用。
Activity中匿名使用Handler實際上會導(dǎo)致Handler內(nèi)部類持有外部類的引用朵逝，而SendMessage()的時候Message會持有Handler蔚袍，enqueueMessage機制又會導(dǎo)致MeassageQueue持有Message。所以當(dāng)發(fā)送的是延遲消息那么Message并不會立即的遍歷出來處理而是阻塞到對應(yīng)的Message觸發(fā)時間以后再處理廉侧。那么阻塞的這段時間中頁面銷毀一定會造成內(nèi)存泄漏页响。
2. 各種注冊操作沒有對應(yīng)的反注冊
這一點基本不必多說，相信大家剛剛開始學(xué)習(xí)廣播和 Service 的時候一定對此有所接觸段誊，然后就是比如我們常用的第三方框架 EventBus 也是一樣的闰蚕。平時使用的時候注意在對應(yīng)的生命周期方法中進(jìn)行反注冊。
3. Bitmap 使用完沒有注意 recycle()
Bitmap 作為大對象连舍，在使用完畢一定要注意調(diào)用 recycle() 進(jìn)行回收没陡。TypedArray 、Cursor索赏、各種流同理盼玄，一定要在最后調(diào)用自己的回收關(guān)閉方法處理。
4. WebView 使用不當(dāng)
WebView 是非常常用的控件潜腻，但稍有不注意也會導(dǎo)致內(nèi)存泄漏埃儿。內(nèi)存泄漏的場景： 很多人使用 Webview 都喜歡采用布局引用方式, 這其實也是作為內(nèi)存泄漏的一個隱患。當(dāng) Activity 被關(guān)閉時融涣，Webview 不會被 GC 馬上回收,而是提交給事務(wù)童番，進(jìn)行隊列處理，這樣就造成了內(nèi)存泄漏, 導(dǎo)致 Webview 無法及時回收威鹿。
目前所知的比較安全的方案是：
- 在布局中動態(tài)添加 WebView剃斧。
- 采用下面的方法。
override fun onDestroy() {
webView?.apply {
val parent = parent
if (parent is ViewGroup) {
parent.removeView(this)
}
stopLoading()
// 退出時調(diào)用此方法忽你，移除綁定的服務(wù)幼东，否則某些特定系統(tǒng)會報錯
settings.javaScriptEnabled = false
clearHistory()
removeAllViews()
destroy()
}
}
5. 循環(huán)引用
循環(huán)引用導(dǎo)致內(nèi)存泄漏比較少見，正常來講不會有人寫出 A 持有 B科雳，B 持有 C根蟹，C 又持有A 這樣的代碼，不過總還是需要注意糟秘。
總的來說娜亿，內(nèi)存泄漏很常見，但檢測方式也很多蚌堵。我們的 Android Studio 自帶的 Monitors 就可以幫我們找到大部分內(nèi)存問題买决，當(dāng)然我們也可以采用譬如 LeakCanary 這樣的庫去做檢測沛婴。
參見：https://android.jlelse.eu/9-ways-to-avoid-memory-leaks-in-android-b6d81648e35e
