前言
關(guān)于Android內(nèi)存優(yōu)化劣纲、內(nèi)存泄漏相關(guān)的文章很多压真，不過大部分是給讀者知識(shí)上的準(zhǔn)備氮采。本文將記錄和分享本人在項(xiàng)目中的實(shí)戰(zhàn)經(jīng)驗(yàn)体捏，希望能從另一個(gè)角度寫出價(jià)值~~
知識(shí)儲(chǔ)備
首先，理解一下什么是內(nèi)存泄漏：當(dāng)應(yīng)用不再需要這個(gè)對(duì)象梗摇，但仍未釋放該對(duì)象的所有引用拓哟。這樣解釋有點(diǎn)抽象×媸冢或者這樣說断序，一般情況下流纹，在我們Android開發(fā)中，當(dāng)一個(gè)Activity對(duì)象自身執(zhí)行onDestroy()后违诗，仍被其他對(duì)象持有者捧颅，使JVM不能回收該Activity對(duì)象，就造成了內(nèi)存泄漏（這里讀者必須要對(duì)垃圾回收的可達(dá)性分析法有一定理解较雕，這里不作詳解，可參考Carson的一篇文章：JVM：判斷一個(gè)Java對(duì)象是否存活）挚币。
實(shí)戰(zhàn)紀(jì)錄
通過Leak Canary的監(jiān)測(cè)和翻查GitLab上的Commits記錄亮蒋，大致把內(nèi)存泄漏的成因分為以下幾種情況。
情況一：屬性動(dòng)畫忘記取消
這種錯(cuò)誤在實(shí)戰(zhàn)中出現(xiàn)得比較多妆毕。特別是那種設(shè)置了無限循環(huán)模式的動(dòng)畫慎玖，理論上是一直不會(huì)釋放的，積累多幾個(gè)界面的泄漏就很容易造成OOM笛粘。如果不是無限循環(huán)模式趁怔，理論上等動(dòng)畫播完后就會(huì)在適當(dāng)時(shí)候被回收，危害性還不算大薪前。
為什么動(dòng)畫會(huì)導(dǎo)致內(nèi)存泄漏呢润努？我猜是動(dòng)畫(數(shù)值)的更新肯定也離不開線程間的通訊機(jī)制，而handler肯定得持有界面控件的引用才能更新動(dòng)畫示括，控件又持有Activity實(shí)例铺浇，所以就回收不到Activity了。查看動(dòng)畫的start()方法垛膝，里面有個(gè)AnimationHandler鳍侣，嗯，八九不離十了吼拥。
解決方法：記得在onDestroy()方法中取消掉動(dòng)畫就行倚聚，特別是無限循環(huán)的動(dòng)畫！凿可！
情況二：RxJava的定時(shí)任務(wù)沒有取消
當(dāng)在頁面中通過Observable.interval()執(zhí)行循環(huán)任務(wù)或者delay()延時(shí)任務(wù)等惑折，退出界面忘記執(zhí)行Subscription.unsubscribe()來取消任務(wù)。
泄漏的原因和危害性不用多說矿酵，可參考情況一唬复。
解決方法：記得在onDestroy()方法中取消掉RxJava任務(wù)就行，特別是無限循環(huán)的任務(wù)Ｈ埂敞咧！
情況三：第三方服務(wù)的耗時(shí)操作
在使用到七牛上傳文件的頁面里，當(dāng)上傳任務(wù)還未執(zhí)行完辜腺，用戶就按返回鍵退回上一界面休建，而未為用戶取消上傳任務(wù)乍恐。
因?yàn)樯蟼魅蝿?wù)的回調(diào)是直接引用著該Activity對(duì)象的，所以上傳未完成的話测砂，Activity對(duì)象也回收不了茵烈。
解決方法：在onDestroy()方法中通知第三方服務(wù)取消任務(wù)就行。一般第三方服務(wù)都會(huì)考慮到這個(gè)問題砌些，可以很方便的取消任務(wù)呜投。
情況四：EventBus沒有反注冊(cè)
忘記在onDestroy()方法中執(zhí)行EventBus.getDefault().unregister()方法。
顯然存璃，EventBus會(huì)持有此Activity對(duì)象仑荐，無法回收。
解決方法：在onDestroy()方法中執(zhí)行EventBus.getDefault().unregister()纵东。
關(guān)于handler的處理方法
對(duì)于網(wǎng)上經(jīng)常說的非靜態(tài)Handler導(dǎo)致的內(nèi)存泄漏粘招，我基本沒測(cè)到過，因?yàn)槲乙恢庇性趏nDestroy()方法中執(zhí)行handler.removeCallbacksAndMessages(null);來清空handler對(duì)應(yīng)的消息隊(duì)列偎球。而網(wǎng)上更多文章推薦的靜態(tài)+弱引用洒扎，我覺得從邏輯上來看不夠針對(duì)性，代碼編寫起來也十分繁雜衰絮。因?yàn)槲一径际怯胷emoveCallbacksAndMessages()方法袍冷。具體的測(cè)試和對(duì)比可以參考這篇文章：Handler 造成 Activity 泄漏，用弱引用真的有用么?
總結(jié)
Android的內(nèi)存泄漏的具體場(chǎng)景可以有千種萬種猫牡，但核心只有一個(gè)难裆，就是Activity執(zhí)行onDestroy()后還被其他對(duì)象持有著，導(dǎo)致JVM通過可達(dá)性分析法作出不回收該Activity對(duì)象的判斷镊掖，導(dǎo)致內(nèi)存泄漏（當(dāng)然如果你要說你的Activity在onDestroy()后還有特定的存在價(jià)值乃戈，算不上泄漏；或者你的泄漏對(duì)象不是Activity而是Service這些罕見情況亩进，我也是無力反駁的對(duì)吧??）症虑。
解決Android內(nèi)存泄漏的核心也只有這個(gè)，在onDestroy()確保這個(gè)Activity對(duì)象不再被其他對(duì)象引用著归薛。這樣就確保不會(huì)發(fā)生內(nèi)存泄漏了谍憔，最起碼按Leak Canary對(duì)內(nèi)存泄漏的定義是這樣的。
當(dāng)然以上也只是理論上的理想情況??實(shí)際上國產(chǎn)的安卓機(jī)還有各種坑主籍。我手上的華為Mate习贫，EMUI版本8.0.0，Android版本8.0千元，就經(jīng)常檢測(cè)到一個(gè)什么mLastClickView的內(nèi)存泄漏苫昌，我Google了一下，應(yīng)該是華為系統(tǒng)的bug幸海，其他國產(chǎn)定制手機(jī)也遇到過類似的奇奇怪怪的內(nèi)存泄漏祟身。對(duì)于這種系統(tǒng)級(jí)別的bug導(dǎo)致的內(nèi)存泄漏奥务，我們也無能為力的~我們作為應(yīng)用開發(fā)者，在應(yīng)用層上在自己的項(xiàng)目中確保不產(chǎn)生內(nèi)存泄漏就行袜硫。
