Android開發中常見的5大記憶體洩漏問題及解決辦法

        在android開發中，記憶體洩漏是比較常見的問題，有過一些android程式設計經歷的童鞋應該都遇到過，但為什麼會出現記憶體洩漏呢？記憶體洩漏又有什麼影響呢？

在android程式開發中，當一個物件已經不需要再使用了，本該被回收時，而另外一個正在使用的物件持有它的引用從而導致它不能被回收，這就導致本該被回收的物件不能被回收而停留在堆記憶體中，記憶體洩漏就產生了。

      記憶體洩漏有什麼影響呢？它是造成應用程式OOM的主要原因之一。由於android系統為每個應用程式分配的記憶體有限，當一個應用中產生的記憶體洩漏比較多時，就難免會導致應用所需要的記憶體超過這個系統分配的記憶體限額，這就造成了記憶體溢位而導致應用Crash。

      瞭解了記憶體洩漏的原因及影響後，我們需要做的就是掌握常見的記憶體洩漏，並在以後的android程式開發中，儘量避免它。下面小編蒐羅了5個android開發中比較常見的記憶體洩漏問題及解決辦法，分享給大家，一起來看看吧。

 

一、單例造成的記憶體洩漏

Android的單例模式非常受開發者的喜愛，不過使用的不恰當的話也會造成記憶體洩漏。因為單例的靜態特性使得單例的生命週期和應用的生命週期一樣長，這就說明了如果一個物件已經不需要使用了，而單例物件還持有該物件的引用，那麼這個物件將不能被正常回收，這就導致了記憶體洩漏。

如下這個典例：

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的引用。

 

所以正確的單例應該修改為下面這種方式：

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中，為了避免重複建立相同的資料資源，會出現這種寫法：

 

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的使用程式碼編寫一不規範即有可能造成記憶體洩漏，如下示例：

 

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的記憶體資源無法及時回收，引發記憶體洩漏，所以另外一種做法為：

 

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時應該移除訊息佇列中的訊息，更準確的做法如下：

 

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。

 

四、執行緒造成的記憶體洩漏

 

對於執行緒造成的記憶體洩漏，也是平時比較常見的，如下這兩個示例可能每個人都這樣寫過：

 

//——————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的記憶體資源無法回收，造成記憶體洩漏。正確的做法還是使用靜態內部類的方式，如下：

 

    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大記憶體洩漏問題及相應的解決辦法，如果大家在程式設計中遇到了上述洩漏問題，不妨可以試試對應的方法。如果大家還有什麼疑問，可以去“學習問答”版塊直接提出。