這段時間在研究如何處理內(nèi)存泄漏問題和防止OOM（內(nèi)存溢出）

首先是內(nèi)存泄漏：（這個是摘抄，加入了自己的理解）

說完這句話我都笑了。

在android應(yīng)用開發(fā)中，當(dāng)一個對象已經(jīng)不需要再使用了，本該被回收時，而另外一個正在使用的對象持有它的引用從而導(dǎo)致它不能被回收，這就導(dǎo)致本該被回收的對象不能被回收而停留在堆內(nèi)存中，內(nèi)存泄漏就產(chǎn)生了。
內(nèi)存泄漏有什么影響呢？它是造成應(yīng)用程序OOM的主要原因之一。由于android系統(tǒng)為每個應(yīng)用程序分配的內(nèi)存有限，當(dāng)一個應(yīng)用中產(chǎn)生的內(nèi)存泄漏比較多時，會導(dǎo)致應(yīng)用所需要的內(nèi)存超過這個系統(tǒng)分配的內(nèi)存限額，這就造成了內(nèi)存溢出而導(dǎo)致應(yīng)用Crash。
了解了內(nèi)存泄漏的原因及影響后，我們需要做的就是掌握常見的內(nèi)存泄漏，并在以后的android程序開發(fā)中，盡量避免它。下面是5個android開發(fā)中比較常見的內(nèi)存泄漏問題及解決辦法，分享給大家，一起來看看吧。

一、 單例造成的內(nèi)存泄漏

Android的單例模式非常受開發(fā)者的喜愛，不過使用的不恰當(dāng)?shù)脑捯矔斐蓛?nèi)存泄漏。因為單例的靜態(tài)特性使得單例的生命周期和應(yīng)用的生命周期一樣長，這就說明了如果一個對象已經(jīng)不需要使用了，而單例對象還持有該對象的引用，那么這個對象將不能被正常回收，這就導(dǎo)致了內(nèi)存泄漏。

如下這個典例：

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;
        }
    }

這是一個普通的單例模式，當(dāng)創(chuàng)建這個單例的時候，由于需要傳入一個Context，所以這個Context的生命周期的長短至關(guān)重要：

1、傳入的是Application的Context：這將沒有任何問題，因為單例的生命周期和Application的一樣長 ；

2、傳入的是Activity的Context：當(dāng)這個Context所對應(yīng)的Activity退出時，由于該Context和Activity的生命周期一樣長（Activity間接繼承 于Context），所以當(dāng)前Activity退出時它的內(nèi)存并不會被回收，因為單例對象持有該Activity的引用。

所以正確的單例應(yīng)該修改為下面這種方式：

  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，而單例的生命周期和應(yīng)用的一樣長，這樣就防止了內(nèi)存泄漏。

二、非靜態(tài)內(nèi)部類創(chuàng)建靜態(tài)實例造成的內(nèi)存泄漏

有的時候我們可能會在啟動頻繁的Activity中，為了避免重復(fù)創(chuàng)建相同的數(shù)據(jù)資源，會出現(xiàn)這種寫法：

   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內(nèi)部創(chuàng)建了一個非靜態(tài)內(nèi)部類的單例，每次啟動Activity時都會使用該單例的數(shù)據(jù)，這樣雖然避免了資源的重復(fù)創(chuàng)建，不過這種寫法卻會造成內(nèi)存泄漏，因為非靜態(tài)內(nèi)部類默認(rèn)會持有外部類的引用，而又使用了該非靜態(tài)內(nèi)部類創(chuàng)建了一個靜態(tài)的實例，該實例的生命周期和應(yīng)用的一樣長，這就導(dǎo)致了該靜態(tài)實例一直會持有該Activity的引用，導(dǎo)致Activity的內(nèi)存資源不能正常回收。

正確的做法為：將該內(nèi)部類設(shè)為靜態(tài)內(nèi)部類或?qū)⒃搩?nèi)部類抽取出來****封裝成一個單例，如果需要使用Context，請使用ApplicationContext。

三、Handler造成的內(nèi)存泄漏

Handler的使用造成的內(nèi)存泄漏問題應(yīng)該說最為常見了，平時在處理網(wǎng)絡(luò)任務(wù)或者封裝一些請求回調(diào)等api都應(yīng)該會借助Handler來處理，對于Handler的使用代碼編寫一不規(guī)范即有可能造成內(nèi)存泄漏，如下示例：

    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);
        }

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

所以另外一種做法為：

創(chuàng)建一個靜態(tài)Handler內(nèi)部類，然后對Handler持有的對象使用弱引用，這樣在回收時也可以回收Handler持有的對象，這樣雖然避免了Activity泄漏，不過Looper線程的消息隊列中還是可能會有待處理的消息，所以我們在Activity的Destroy時或者Stop時應(yīng)該移除消息隊列中的消息（小司機(jī)我建議在ondestroy里面移除），做法如下：

     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("");//更新界面UI，在靜態(tài)內(nèi)部類中有時會出現(xiàn)一些引用問題，
                 //必須將引用的外部一些變量或者Adapter設(shè)置為static 。
             }
          }
        }
 
     @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。
        /*
         * 也可以使用mHandler.removeCallbacks();或mHandler.removeMessages();來移除指定的Runnable和Message。
         *
         */
       }

四、線程造成的內(nèi)存泄漏

對于線程造成的內(nèi)存泄漏，也是平時比較常見的，如下這兩個示例可能每個人都寫過：

   //——————你寫的代碼 1
        new AsyncTask<Void, Void, Void>() {
            @Override
            protected Void doInBackground(Void... params) {
                SystemClock.sleep(10000);
                return null;
            }
        }.execute();
     //——————你寫的代碼 2
        new Thread(new Runnable() {
            @Override
            public void run() {
                SystemClock.sleep(10000);
            }
        }).start();

上面的異步任務(wù)和Runnable都是一個匿名內(nèi)部類，因此它們對當(dāng)前Activity都有一個隱式引用。如果Activity在銷毀之前，任務(wù)還未完成， 那么將導(dǎo)致Activity的內(nèi)存資源無法回收，造成內(nèi)存泄漏。

正確的做法還是使用靜態(tài)內(nèi)部類的方式，如下：

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的內(nèi)存資源泄漏，當(dāng)然在Activity銷毀時候也應(yīng)該取消相應(yīng)的任務(wù)AsyncTask::cancel()，避免任務(wù)在后臺執(zhí)行浪費資源。

五、資源未關(guān)閉造成的內(nèi)存泄漏

對于使用了BraodcastReceiver，ContentObserver，F(xiàn)ile，Cursor，Stream，Bitmap等資源的使用，應(yīng)該在Activity銷毀時及時關(guān)閉或者注銷，

請記住尤其是Bitmap這位，

否則這些資源將不會被回收，造成內(nèi)存泄漏。

接下來我們來討論OOM的問題。Android 內(nèi)存泄漏和OOM分析(二)