前言
對於記憶體洩漏，我想大家在開發中肯定都遇到過，只不過記憶體洩漏對我們來說並不是可見的，因為它是在堆中活動，而要想檢測程式中是否有記憶體洩漏的產生，通常我們可以藉助LeakCanary、MAT等工具來檢測應用程式是否存在記憶體洩漏，MAT是一款強大的記憶體分析工具，功能繁多而複雜，而LeakCanary則是由Square開源的一款輕量第三方記憶體洩漏檢測工具，當它檢測到程式中有記憶體洩漏的產生時，它將以最直觀的方式告訴我們該記憶體洩漏是由誰產生的和該記憶體洩漏導致誰洩漏了而不能回收，供我們複查。
最近騰訊bugly也推出了三篇關於Android記憶體洩漏調優的文章：
1、記憶體洩露從入門到精通三部曲之基礎知識篇
2、記憶體洩露從入門到精通三部曲之排查方法篇
3、記憶體洩露從入門到精通三部曲之常見原因與使用者實踐
關於效能優化的文章，出自Realm.io：
10 條提升 Android 效能的建議
記憶體洩漏
為什麼會產生記憶體洩漏？
當一個物件已經不需要再使用了，本該被回收時，而有另外一個正在使用的物件持有它的引用從而導致它不能被回收，這導致本該被回收的物件不能被回收而停留在堆記憶體中，這就產生了記憶體洩漏。
記憶體洩漏對程式的影響？
記憶體洩漏是造成應用程式OOM的主要原因之一！我們知道Android系統為每個應用程式分配的記憶體有限，而當一個應用中產生的記憶體洩漏比較多時，這就難免會導致應用所需要的記憶體超過這個系統分配的記憶體限額，這就造成了記憶體溢位而導致應用Crash。
Android中常見的記憶體洩漏彙總
單例造成的記憶體洩漏
單例模式非常受開發者的喜愛，不過使用的不恰當的話也會造成記憶體洩漏，由於單例的靜態特性使得單例的生命週期和應用的生命週期一樣長，這就說明了如果一個物件已經不需要使用了，而單例物件還持有該物件的引用，那麼這個物件將不能被正常回收，這就導致了記憶體洩漏。
如下這個典例：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
public class AppManager { private static AppManager instance; private Context context; private AppManager(Context context) { this.context = context; } public static AppManager getInstance(Context context) { if (instance != null) { instance = new AppManager(context); } return instance; } } |
這是一個普通的單例模式，當建立這個單例的時候，由於需要傳入一個Context，所以這個Context的生命週期的長短至關重要：
1、傳入的是Application的Context：這將沒有任何問題，因為單例的生命週期和Application的一樣長
2、傳入的是Activity的Context：當這個Context所對應的Activity退出時，由於該Context和Activity的生命週期一樣長（Activity間接繼承於Context），所以當前Activity退出時它的記憶體並不會被回收，因為單例物件持有該Activity的引用。
所以正確的單例應該修改為下面這種方式：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
public class AppManager { private static AppManager instance; private Context context; private AppManager(Context context) { this.context = context.getApplicationContext(); } public static AppManager getInstance(Context context) { if (instance != null) { instance = new AppManager(context); } return instance; } } |
這樣不管傳入什麼Context最終將使用Application的Context，而單例的生命週期和應用的一樣長，這樣就防止了記憶體洩漏
非靜態內部類建立靜態例項造成的記憶體洩漏
有的時候我們可能會在啟動頻繁的Activity中，為了避免重複建立相同的資料資源，可能會出現這種寫法：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
public class MainActivity extends AppCompatActivity { private static TestResource mResource = null; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); if(mManager == null){ mManager = new TestResource(); } //... } class TestResource { //... } } |
這樣就在Activity內部建立了一個非靜態內部類的單例，每次啟動Activity時都會使用該單例的資料，這樣雖然避免了資源的重複建立，不過這種寫法卻會造成記憶體洩漏，因為非靜態內部類預設會持有外部類的引用，而又使用了該非靜態內部類建立了一個靜態的例項，該例項的生命週期和應用的一樣長，這就導致了該靜態例項一直會持有該Activity的引用，導致Activity的記憶體資源不能正常回收。正確的做法為：
將該內部類設為靜態內部類或將該內部類抽取出來封裝成一個單例，如果需要使用Context，請使用ApplicationContext
Handler造成的記憶體洩漏
Handler的使用造成的記憶體洩漏問題應該說最為常見了，平時在處理網路任務或者封裝一些請求回撥等api都應該會藉助Handler來處理，對於Handler的使用程式碼編寫一不規範即有可能造成記憶體洩漏，如下示例：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
public class MainActivity extends AppCompatActivity { private Handler mHandler = new Handler() { @Override public void handleMessage(Message msg) { //... } }; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); loadData(); } private void loadData(){ //...request Message message = Message.obtain(); mHandler.sendMessage(message); } } |
這種建立Handler的方式會造成記憶體洩漏，由於mHandler是Handler的非靜態匿名內部類的例項，所以它持有外部類Activity的引用，我們知道訊息佇列是在一個Looper執行緒中不斷輪詢處理訊息，那麼當這個Activity退出時訊息佇列中還有未處理的訊息或者正在處理訊息，而訊息佇列中的Message持有mHandler例項的引用，mHandler又持有Activity的引用，所以導致該Activity的記憶體資源無法及時回收，引發記憶體洩漏，所以另外一種做法為：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
public class MainActivity extends AppCompatActivity { private MyHandler mHandler = new MyHandler(this); private TextView mTextView ; private static class MyHandler extends Handler { private WeakReference<Context> reference; public MyHandler(Context context) { reference = new WeakReference<>(context); } @Override public void handleMessage(Message msg) { MainActivity activity = (MainActivity) reference.get(); if(activity != null){ activity.mTextView.setText(""); } } } @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); mTextView = (TextView)findViewById(R.id.textview); loadData(); } private void loadData() { //...request Message message = Message.obtain(); mHandler.sendMessage(message); } } |
建立一個靜態Handler內部類，然後對Handler持有的物件使用弱引用，這樣在回收時也可以回收Handler持有的物件，這樣雖然避免了Activity洩漏，不過Looper執行緒的訊息佇列中還是可能會有待處理的訊息，所以我們在Activity的Destroy時或者Stop時應該移除訊息佇列中的訊息，更準確的做法如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 |
public class MainActivity extends AppCompatActivity { private MyHandler mHandler = new MyHandler(this); private TextView mTextView ; private static class MyHandler extends Handler { private WeakReference<Context> reference; public MyHandler(Context context) { reference = new WeakReference<>(context); } @Override public void handleMessage(Message msg) { MainActivity activity = (MainActivity) reference.get(); if(activity != null){ activity.mTextView.setText(""); } } } @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); mTextView = (TextView)findViewById(R.id.textview); loadData(); } private void loadData() { //...request Message message = Message.obtain(); mHandler.sendMessage(message); } @Override protected void onDestroy() { super.onDestroy(); mHandler.removeCallbacksAndMessages(null); } } |
使用mHandler.removeCallbacksAndMessages(null);是移除訊息佇列中所有訊息和所有的Runnable。當然也可以使用mHandler.removeCallbacks();或mHandler.removeMessages();來移除指定的Runnable和Message。
執行緒造成的記憶體洩漏
對於執行緒造成的記憶體洩漏，也是平時比較常見的，如下這兩個示例可能每個人都這樣寫過：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 |
public class MainActivity extends AppCompatActivity { private MyHandler mHandler = new MyHandler(this); private TextView mTextView ; private static class MyHandler extends Handler { private WeakReference<Context> reference; public MyHandler(Context context) { reference = new WeakReference<>(context); } @Override public void handleMessage(Message msg) { MainActivity activity = (MainActivity) reference.get(); if(activity != null){ activity.mTextView.setText(""); } } } @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); mTextView = (TextView)findViewById(R.id.textview); loadData(); } private void loadData() { //...request Message message = Message.obtain(); mHandler.sendMessage(message); } @Override protected void onDestroy() { super.onDestroy(); mHandler.removeCallbacksAndMessages(null); } } |
上面的非同步任務和Runnable都是一個匿名內部類，因此它們對當前Activity都有一個隱式引用。如果Activity在銷燬之前，任務還未完成，
那麼將導致Activity的記憶體資源無法回收，造成記憶體洩漏。正確的做法還是使用靜態內部類的方式，如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
static class MyAsyncTask extends AsyncTask<Void, Void, Void> { private WeakReference<Context> weakReference; public MyAsyncTask(Context context) { weakReference = new WeakReference<>(context); } @Override protected Void doInBackground(Void... params) { SystemClock.sleep(10000); return null; } @Override protected void onPostExecute(Void aVoid) { super.onPostExecute(aVoid); MainActivity activity = (MainActivity) weakReference.get(); if (activity != null) { //... } } } static class MyRunnable implements Runnable{ @Override public void run() { SystemClock.sleep(10000); } } //—————— new Thread(new MyRunnable()).start(); new MyAsyncTask(this).execute(); |
這樣就避免了Activity的記憶體資源洩漏，當然在Activity銷燬時候也應該取消相應的任務AsyncTask::cancel()，避免任務在後臺執行浪費資源。
資源未關閉造成的記憶體洩漏
對於使用了BraodcastReceiver，ContentObserver，File，Cursor，Stream，Bitmap等資源的使用，應該在Activity銷燬時及時關閉或者登出，否則這些資源將不會被回收，造成記憶體洩漏。
一些建議
1、對於生命週期比Activity長的物件如果需要應該使用ApplicationContext
2、在涉及到Context時先考慮ApplicationContext，當然它並不是萬能的，對於有些地方則必須使用Activity的Context，對於Application，Service，Activity三者的Context的應用場景如下：
**其中：**NO1表示Application和Service可以啟動一個Activity，不過需要建立一個新的task任務佇列。而對於Dialog而言，只有在Activity中才能建立
3、對於需要在靜態內部類中使用非靜態外部成員變數（如：Context、View )，可以在靜態內部類中使用弱引用來引用外部類的變數來避免記憶體洩漏
4、對於生命週期比Activity長的內部類物件，並且內部類中使用了外部類的成員變數，可以這樣做避免記憶體洩漏：
- 將內部類改為靜態內部類
- 靜態內部類中使用弱引用來引用外部類的成員變數
5、對於不再需要使用的物件，顯示的將其賦值為null，比如使用完Bitmap後先呼叫recycle()，再賦為null
6、保持對物件生命週期的敏感，特別注意單例、靜態物件、全域性性集合等的生命週期
打賞支援我寫出更多好文章，謝謝！
打賞作者
打賞支援我寫出更多好文章，謝謝！
任選一種支付方式
