個(gè)Android開發(fā)中比較常見的內(nèi)存泄漏問題及解決辦法

1、5個(gè)Android開發(fā)中比較常見的內(nèi)存泄漏問題及解決辦法在Android開發(fā)中，內(nèi)存泄漏是比較常見的問題，有過一些Android編程經(jīng)歷的童鞋應(yīng)該都遇到過，但為什么會(huì)出現(xiàn)內(nèi)存泄漏呢?內(nèi)存泄漏又有什么影響呢?在Android程序開發(fā)中，當(dāng)一個(gè)對(duì)象已經(jīng)不需要再使用了，本該被回收時(shí)，而另外一個(gè)正在使用的對(duì)象持有它的引用從而導(dǎo)致它不能被回收，這就導(dǎo)致本該被回收的對(duì)象不能被回收而停留在堆內(nèi)存中，內(nèi)存泄漏就產(chǎn)生了。內(nèi)存泄漏有什么影響呢?它是造成應(yīng)用程序OOM的主要原因之一。由于Android系統(tǒng)為每個(gè)應(yīng)用程序分配的內(nèi)存有限，當(dāng)一個(gè)應(yīng)用中產(chǎn)生的內(nèi)存泄漏比較多時(shí)，就難免會(huì)導(dǎo)致應(yīng)用所需要的內(nèi)存超過這個(gè)系統(tǒng)分配的

2、內(nèi)存限額，這就造成了內(nèi)存溢出而導(dǎo)致應(yīng)用Crash。了解了內(nèi)存泄漏的原因及影響后，我們需要做的就是掌握常見的內(nèi)存泄漏，并在以后的Android程序開發(fā)中，盡量避免它。下面小編搜羅了5個(gè)Android開發(fā)中比較常見的內(nèi)存泄漏問題及解決辦法，分享給大家，一起來(lái)看看吧。一、單例造成的內(nèi)存泄漏Android的單例模式非常受開發(fā)者的喜愛，不過使用的不恰當(dāng)?shù)脑捯矔?huì)造成內(nèi)存泄漏。因?yàn)閱卫撵o態(tài)特性使得單例的生命周期和應(yīng)用的生命周期一樣長(zhǎng)，這就說明了如果一個(gè)對(duì)象已經(jīng)不需要使用了，而單例對(duì)象還持有該對(duì)象的引用，那么這個(gè)對(duì)象將不能被正?；厥眨@就導(dǎo)致了內(nèi)存泄漏。如下這個(gè)典例：public class

3、60;AppManager     private static AppManager instance;    private Context context;    private AppManager(Context context)         this.context = c

4、ontext;        public static AppManager getInstance(Context context)         if (instance != null)             inst

5、ance = new AppManager(context);                return instance;    這是一個(gè)普通的單例模式，當(dāng)創(chuàng)建這個(gè)單例的時(shí)候，由于需要傳入一個(gè)Context，所以這個(gè)Context的生命周期的長(zhǎng)短至關(guān)重要：1、傳入的是Application的Context：這將沒有任何問題，因?yàn)閱卫纳芷诤虯ppli

6、cation的一樣長(zhǎng) ;2、傳入的是Activity的Context：當(dāng)這個(gè)Context所對(duì)應(yīng)的Activity退出時(shí)，由于該Context和Activity的生命周期一樣長(zhǎng)(Activity間接繼承于Context)，所以當(dāng)前Activity退出時(shí)它的內(nèi)存并不會(huì)被回收，因?yàn)閱卫龑?duì)象持有該Activity的引用。所以正確的單例應(yīng)該修改為下面這種方式：public class AppManager     private static AppManager instance; 

7、0;  private Context context;    private AppManager(Context context)         this.context = context.getApplicationContext();        public static 

8、AppManager getInstance(Context context)         if (instance != null)             instance = new AppManager(context);     

9、60;          return instance;    這樣不管傳入什么Context最終將使用Application的Context，而單例的生命周期和應(yīng)用的一樣長(zhǎng)，這樣就防止了內(nèi)存泄漏。二、非靜態(tài)內(nèi)部類創(chuàng)建靜態(tài)實(shí)例造成的內(nèi)存泄漏有的時(shí)候我們可能會(huì)在啟動(dòng)頻繁的Activity中，為了避免重復(fù)創(chuàng)建相同的數(shù)據(jù)資源，會(huì)出現(xiàn)這種寫法：public class MainActivity extends A

10、ppCompatActivity     private static TestResource mResource = null;    Override    protected void onCreate(Bundle savedInstanceState)         super.onC

11、reate(savedInstanceState);        setContentView(R.layout.activity_main);        if(mManager = null)            mManager = new TestReso

12、urce();                /.        class TestResource         /.    這樣就在Activity內(nèi)部創(chuàng)建了一個(gè)非靜態(tài)內(nèi)部類的單例，每次啟動(dòng)Activity時(shí)都會(huì)

13、使用該單例的數(shù)據(jù)，這樣雖然避免了資源的重復(fù)創(chuàng)建，不過這種寫法卻會(huì)造成內(nèi)存泄漏，因?yàn)榉庆o態(tài)內(nèi)部類默認(rèn)會(huì)持有外部類的引用，而又使用了該非靜態(tài)內(nèi)部類創(chuàng)建了一個(gè)靜態(tài)的實(shí)例，該實(shí)例的生命周期和應(yīng)用的一樣長(zhǎng)，這就導(dǎo)致了該靜態(tài)實(shí)例一直會(huì)持有該Activity的引用，導(dǎo)致Activity的內(nèi)存資源不能正?；厥?。正確的做法為：將該內(nèi)部類設(shè)為靜態(tài)內(nèi)部類或?qū)⒃搩?nèi)部類抽取出來(lái)封裝成一個(gè)單例，如果需要使用Context，請(qǐng)使用ApplicationContext 。三、Handler造成的內(nèi)存泄漏Handler的使用造成的內(nèi)存泄漏問題應(yīng)該說最為常見了，平時(shí)在處理網(wǎng)絡(luò)任務(wù)或者封裝一些請(qǐng)求回調(diào)等api都應(yīng)該會(huì)借助Handl

14、er來(lái)處理，對(duì)于Handler的使用代碼編寫一不規(guī)范即有可能造成內(nèi)存泄漏，如下示例：public class MainActivity extends AppCompatActivity     private Handler mHandler = new Handler()         Override     

15、   public void handleMessage(Message msg)             /.                Override    protected void&#

16、160;onCreate(Bundle savedInstanceState)         super.onCreate(savedInstanceState);        setContentView(R.layout.activity_main);        loadData();   

17、60;    private void loadData()        /.request        Message message = Message.obtain();        mHandler.sendMessage(message); &

18、#160;  這種創(chuàng)建Handler的方式會(huì)造成內(nèi)存泄漏，由于mHandler是Handler的非靜態(tài)匿名內(nèi)部類的實(shí)例，所以它持有外部類Activity的引用，我們知道消息隊(duì)列是在一個(gè)Looper線程中不斷輪詢處理消息，那么當(dāng)這個(gè)Activity退出時(shí)消息隊(duì)列中還有未處理的消息或者正在處理消息，而消息隊(duì)列中的Message持有mHandler實(shí)例的引用，mHandler又持有Activity的引用，所以導(dǎo)致該Activity的內(nèi)存資源無(wú)法及時(shí)回收，引發(fā)內(nèi)存泄漏，所以另外一種做法為：public class MainActivity extend

19、s AppCompatActivity     private MyHandler mHandler = new MyHandler(this);    private TextView mTextView     private static class MyHandler extends Handler  

20、;       private WeakReference<Context> reference;        public MyHandler(Context context)             reference = new 

21、WeakReference<>(context);                Override        public void handleMessage(Message msg)          

22、0;  MainActivity activity = (MainActivity) reference.get();            if(activity != null)                activity.mTex

23、tView.setText("");                              Override    protected void onCreate(Bundle savedInstanceS

24、tate)         super.onCreate(savedInstanceState);        setContentView(R.layout.activity_main);        mTextView = (TextView)findViewById(R.id.textview);  

25、;      loadData();          private void loadData()         /.request        Message message = Message.obtain(

26、);        mHandler.sendMessage(message);    創(chuàng)建一個(gè)靜態(tài)Handler內(nèi)部類，然后對(duì)Handler持有的對(duì)象使用弱引用，這樣在回收時(shí)也可以回收Handler持有的對(duì)象，這樣雖然避免了Activity泄漏，不過Looper線程的消息隊(duì)列中還是可能會(huì)有待處理的消息，所以我們?cè)贏ctivity的Destroy時(shí)或者Stop時(shí)應(yīng)該移除消息隊(duì)列中的消息，更準(zhǔn)確的做法如下：public class MainActivity&

27、#160;extends AppCompatActivity     private MyHandler mHandler = new MyHandler(this);    private TextView mTextView     private static class MyHandler extends Handler

28、         private WeakReference<Context> reference;        public MyHandler(Context context)             reference =

29、0;new WeakReference<>(context);                Override        public void handleMessage(Message msg)         

30、;    MainActivity activity = (MainActivity) reference.get();            if(activity != null)                ac

31、tivity.mTextView.setText("");                            Override    protected void onCreate(Bundle savedInstanceSt

32、ate)         super.onCreate(savedInstanceState);        setContentView(R.layout.activity_main);        mTextView = (TextView)findViewById(R.id.textview);  

33、      loadData();        private void loadData()         /.request        Message message = Message.obtain();  

34、;      mHandler.sendMessage(message);        Override    protected void onDestroy()         super.onDestroy();       

35、60;mHandler.removeCallbacksAndMessages(null);    使用mHandler.removeCallbacksAndMessages(null);是移除消息隊(duì)列中所有消息和所有的Runnable。當(dāng)然也可以使用mHandler.removeCallbacks();或mHandler.removeMessages()；來(lái)移除指定的Runnable和Message。四、線程造成的內(nèi)存泄漏對(duì)于線程造成的內(nèi)存泄漏，也是平時(shí)比較常見的，如下這兩個(gè)示例可能每個(gè)人都這樣寫過：/test1   

36、60;    new AsyncTask<Void, Void, Void>()             Override            protected Void doInBackground(Void. params)

37、60;                SystemClock.sleep(10000);                return null;          

38、60;         .execute();/test2        new Thread(new Runnable()             Override         

39、60;  public void run()                 SystemClock.sleep(10000);                    ).start();上

40、面的異步任務(wù)和Runnable都是一個(gè)匿名內(nèi)部類，因此它們對(duì)當(dāng)前Activity都有一個(gè)隱式引用。如果Activity在銷毀之前，任務(wù)還未完成， 那么將導(dǎo)致Activity的內(nèi)存資源無(wú)法回收，造成內(nèi)存泄漏。正確的做法還是使用靜態(tài)內(nèi)部類的方式，如下：static class MyAsyncTask extends AsyncTask<Void, Void, Void>         private WeakReference

41、<Context> weakReference;          public MyAsyncTask(Context context)             weakReference = new WeakReference<>(context);  

42、0;               Override        protected Void doInBackground(Void. params)             SystemClock.sleep(10000);            return null;                  Override        protected void onPostEx