轉(zhuǎn)載來之
http://blog.nimbledroid.com/2016/05/23/memory-leaks-zh.html

像 Java 這樣具有垃圾回收功能的語言的好處之一灭翔，就是程序員無需手動管理內(nèi)存分配涣雕。這減少了段錯誤（segmentation fault）導(dǎo)致的閃退简僧，也減少了內(nèi)存泄漏導(dǎo)致的堆空間膨脹，讓編寫的代碼更加安全。然而，Java 中依然有可能發(fā)生內(nèi)存泄漏。所以你的安卓 APP 依然有可能浪費了大量的內(nèi)存敛纲，甚至由于內(nèi)存耗盡（OOM）導(dǎo)致閃退。
傳統(tǒng)的內(nèi)存泄漏是由忘記釋放分配的內(nèi)存導(dǎo)致的剂癌，而邏輯上的內(nèi)存泄漏則是由于忘記在對象不再被使用的時候釋放對其的引用導(dǎo)致的淤翔。如果一個對象仍然存在強引用，垃圾回收器就無法對其進(jìn)行垃圾回收佩谷。在安卓平臺旁壮，泄漏 Context 對象問題尤其嚴(yán)重辞做。這是因為像 Activity 這樣的 Context 對象會引用大量很占用內(nèi)存的對象，例如 View 層級寡具，以及其他的資源秤茅。如果 Context 對象發(fā)生了內(nèi)存泄漏，那它引用的所有對象都被泄漏了童叠。安卓設(shè)備大多內(nèi)存有限框喳，如果發(fā)生了大量這樣的內(nèi)存泄漏，那內(nèi)存將很快耗盡厦坛。
如果一個對象的合理生命周期沒有清晰的定義五垮，那判斷邏輯上的內(nèi)存泄漏將是一個見仁見智的問題。幸運的是杜秸，activity 有清晰的生命周期定義放仗，使得我們可以很明確地判斷 activity 對象是否被內(nèi)存泄漏。onDestroy() 函數(shù)將在 activity 被銷毀時調(diào)用撬碟，無論是程序員主動銷毀 activity诞挨，還是系統(tǒng)為了回收內(nèi)存而將其銷毀。如果 onDestroy 執(zhí)行完畢之后呢蛤，activity 對象仍被 heap root 強引用惶傻，那垃圾回收器就無法將其回收。所以我們可以把生命周期結(jié)束之后仍被引用的 activity 定義為被泄漏的 activity其障。
Activity 是非常重量級的對象银室，所以我們應(yīng)該極力避免妨礙系統(tǒng)對其進(jìn)行回收。然而有多種方式會讓我們無意間就泄露了 activity 對象励翼。我們把可能導(dǎo)致 activity 泄漏的情況分為兩類蜈敢，一類是使用了進(jìn)程全局（process-global）的靜態(tài)變量，無論 APP 處于什么狀態(tài)汽抚，都會一直存在抓狭，它們持有了對 activity 的強引用進(jìn)而導(dǎo)致內(nèi)存泄漏，另一類是生命周期長于 activity 的線程殊橙，它們忘記釋放對 activity 的強引用進(jìn)而導(dǎo)致內(nèi)存泄漏辐宾。下面我們就來詳細(xì)分析一下這些可能導(dǎo)致 activity 泄漏的情況狱从。

1. 靜態(tài) Activity
   泄漏 activity 最簡單的方法就是在 activity 類中定義一個 static 變量膨蛮，并且將其指向一個運行中的 activity 實例。如果在 activity 的生命周期結(jié)束之前季研，沒有清除這個引用敞葛，那它就會泄漏了。這是因為 activity（例如 MainActivity） 的類對象是靜態(tài)的与涡，一旦加載惹谐，就會在 APP 運行時一直常駐內(nèi)存持偏，因此如果類對象不卸載，其靜態(tài)成員就不會被垃圾回收氨肌。
   void setStaticActivity() { activity = this;}View saButton = findViewById(R.id.sa_button);saButton.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { setStaticActivity(); nextActivity(); }});

內(nèi)存泄漏場景 1 - Static Activity

2. 靜態(tài) View
   另一種類似的情況是對經(jīng)常啟動的 activity 實現(xiàn)一個單例模式鸿秆，讓其常駐內(nèi)存可以使它能夠快速恢復(fù)狀態(tài)。然而怎囚，就像前文所述卿叽，不遵循系統(tǒng)定義的 activity 生命周期是非常危險的，也是沒必要的恳守，所以我們應(yīng)該極力避免考婴。
   但是如果我們有一個創(chuàng)建起來非常耗時的 View，在同一個 activity 不同的生命周期中都保持不變呢催烘？所以讓我們?yōu)樗鼘崿F(xiàn)一個單例模式沥阱，就像這段代碼。現(xiàn)在一旦 activity 被銷毀伊群，那我們就應(yīng)該釋放大部分的內(nèi)存了考杉。
   void setStaticView() { view = findViewById(R.id.sv_button);}View svButton = findViewById(R.id.sv_button);svButton.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { setStaticView(); nextActivity(); }});

內(nèi)存泄漏場景 2 - Static View

內(nèi)存泄漏了！因為一旦 view 被加入到界面中舰始，它就會持有 context 的強引用奔则，也就是我們的 activity。由于我們通過一個靜態(tài)成員引用了這個 view蔽午，所以我們也就引用了 activity易茬，因此 activity 就發(fā)生了泄漏。所以一定不要把加載的 view 賦值給靜態(tài)變量及老，如果你真的需要抽莱，那一定要確保在 activity 銷毀之前將其從 view 層級中移除。

3. 內(nèi)部類
   現(xiàn)在讓我們在 activity 內(nèi)部定義一個類骄恶，也就是內(nèi)部類食铐。這樣做的原因有很多，比如增加封裝性和可讀性僧鲁。如果我們創(chuàng)建了一個內(nèi)部類的對象虐呻，并且通過靜態(tài)變量持有了 activity 的引用，那也會發(fā)生 activity 泄漏寞秃。
   void createInnerClass() { class InnerClass { } inner = new InnerClass();}View icButton = findViewById(R.id.ic_button);icButton.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { createInnerClass(); nextActivity(); }});

內(nèi)存泄漏場景 3 - Inner Class

不幸的是斟叼，內(nèi)部類能夠引用外部類的成員這一優(yōu)勢，就是通過持有外部類的引用來實現(xiàn)的春寿，而這正是 activity 泄漏的原因朗涩。

4. 匿名類
   類似的，匿名類同樣會持有定義它們的對象的引用绑改。因此如果在 activity 內(nèi)定義了一個匿名的 AsyncTask 對象谢床，就有可能發(fā)生內(nèi)存泄漏了兄一。如果 activity 被銷毀之后 AsyncTask 仍然在執(zhí)行，那就會組織垃圾回收器回收 activity 對象识腿，進(jìn)而導(dǎo)致內(nèi)存泄漏出革，直到執(zhí)行結(jié)束才能回收 activity。
   void startAsyncTask() { new AsyncTask<Void, Void, Void>() { @Override protected Void doInBackground(Void... params) { while(true); } }.execute();}super.onCreate(savedInstanceState);setContentView(R.layout.activity_main);View aicButton = findViewById(R.id.at_button);aicButton.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { startAsyncTask(); nextActivity(); }});

內(nèi)存內(nèi)存泄漏場景 4 - AsyncTask

5. Handlers
   同樣的渡讼，定義一個匿名的 Runnable 對象并將其提交到 Handler 上也可能導(dǎo)致 activity 泄漏蹋盆。Runnable 對象間接地引用了定義它的 activity 對象，而它會被提交到 Handler 的 MessageQueue 中硝全，如果它在 activity 銷毀時還沒有被處理栖雾，那就會導(dǎo)致 activity 泄漏了。
   void createHandler() { new Handler() { @Override public void handleMessage(Message message) { super.handleMessage(message); } }.postDelayed(new Runnable() { @Override public void run() { while(true); } }, Long.MAX_VALUE >> 1);}View hButton = findViewById(R.id.h_button);hButton.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { createHandler(); nextActivity(); }});

內(nèi)存泄漏場景 5 - Handler

6. Threads
   同樣的伟众，使用 Thread 和 TimerTask 也可能導(dǎo)致 activity 泄漏析藕。
   void spawnThread() { new Thread() { @Override public void run() { while(true); } }.start();}View tButton = findViewById(R.id.t_button);tButton.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { spawnThread(); nextActivity(); }});

內(nèi)存泄漏場景 6 - Thread

7. Timer Tasks
   只要它們是通過匿名類創(chuàng)建的，盡管它們在單獨的線程被執(zhí)行凳厢，它們也會持有對 activity 的強引用账胧，進(jìn)而導(dǎo)致內(nèi)存泄漏。
   void scheduleTimer() { new Timer().schedule(new TimerTask() { @Override public void run() { while(true); } }, Long.MAX_VALUE >> 1);}View ttButton = findViewById(R.id.tt_button);ttButton.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { scheduleTimer(); nextActivity(); }});

內(nèi)存泄漏場景 7 - TimerTask

8. Sensor Manager
   最后先紫，系統(tǒng)服務(wù)可以通過 context.getSystemService 獲取治泥，它們負(fù)責(zé)執(zhí)行某些后臺任務(wù)，或者為硬件訪問提供接口遮精。如果 context 對象想要在服務(wù)內(nèi)部的事件發(fā)生時被通知居夹，那就需要把自己注冊到服務(wù)的監(jiān)聽器中。然而本冲，這會讓服務(wù)持有 activity 的引用准脂，如果程序員忘記在 activity 銷毀時取消注冊，那就會導(dǎo)致 activity 泄漏了檬洞。
   void registerListener() { SensorManager sensorManager = (SensorManager) getSystemService(SENSOR_SERVICE); Sensor sensor = sensorManager.getDefaultSensor(Sensor.TYPE_ALL); sensorManager.registerListener(this, sensor, SensorManager.SENSOR_DELAY_FASTEST);}View smButton = findViewById(R.id.sm_button);smButton.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { registerListener(); nextActivity(); }});

內(nèi)存泄漏場景 8 - Sensor Manager

現(xiàn)在狸膏，我們展示了八種很容易不經(jīng)意間就泄漏大量內(nèi)存的情景。請記住添怔，最壞的情況下湾戳，你的 APP 可能會由于大量的內(nèi)存泄漏而內(nèi)存耗盡，進(jìn)而閃退广料，但它并不總是這樣砾脑。相反，內(nèi)存泄漏會消耗大量的內(nèi)存性昭，但卻不至于內(nèi)存耗盡拦止，這時县遣，APP 會由于內(nèi)存不夠分配而頻繁進(jìn)行垃圾回收糜颠。垃圾回收是非常耗時的操作汹族，會導(dǎo)致嚴(yán)重的卡頓。在 activity 內(nèi)部創(chuàng)建對象時其兴，一定要格外小心顶瞒，并且要經(jīng)常測試是否存在內(nèi)存泄漏。

SDK內(nèi)存泄漏 :

今天在使用LeakCanary檢查應(yīng)用的內(nèi)存泄露時元旬，報了一個這樣的錯誤榴徐，并且還給出了參考鏈接，原來這是Android輸入法的一個bug匀归，在15<=API<=23中都存在坑资。