轉載於:http://blog.csdn.net/q178266871/article/details/50719144
在Android開發中,內存泄漏是比較常見的問題,有過一些Android編程經歷的童鞋應該都遇到過,但爲什麼會出現內存泄漏呢?內存泄漏又有什麼影響呢?
在Android程序開發中,當一個對象已經不需要再使用了,本該被回收時,而另外一個正在使用的對象持有它的引用從而導致它不能被回收,這就導致本該被回收的對象不能被回收而停留在堆內存中,內存泄漏就產生了。
內存泄漏有什麼影響呢?它是造成應用程序OOM的主要原因之一。由於Android系統爲每個應用程序分配的內存有限,當一個應用中產生的內存泄漏比較多時,就難免會導致應用所需要的內存超過這個系統分配的內存限額,這就造成了內存溢出而導致應用Crash。
瞭解了內存泄漏的原因及影響後,我們需要做的就是掌握常見的內存泄漏,並在以後的Android程序開發中,儘量避免它。下面小編蒐羅了5個Android開發中比較常見的內存泄漏問題及解決辦法,分享給大家,一起來看看吧。
一、單例造成的內存泄漏
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
|
//——————test1 new AsyncTask<Void, Void, Void>() { @Override protected Void doInBackground(Void... params) { SystemClock.sleep( 10000 ); return null ; } }.execute(); //——————test2 new Thread( new Runnable() { @Override public void run() { SystemClock.sleep( 10000 ); } }).start(); |
上面的異步任務和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銷燬時及時關閉或者註銷,否則這些資源將不會被回收,造成內存泄漏。
以上就是android編程中,常見的5大內存泄漏問題及相應的解決辦法,如果大家在編程中遇到了上述泄漏問題,不妨可以試試對應的方法。如果大家還有什麼疑問,可以去“學習問答”版塊直接提出。