Android性能優化之常見的內存泄漏

時間  2019-11-10
標籤 android 性能 優化 常見的 內存 泄漏 欄目 Android 简体版
原文   原文鏈接

前言

對於內存泄漏，我想你們在開發中確定都遇到過，只不過內存泄漏對咱們來講並非可見的，由於它是在堆中活動，而要想檢測程序中是否有內存泄漏的產生，一般咱們能夠藉助LeakCanary、MAT等工具來檢測應用程序是否存在內存泄漏，MAT是一款強大的內存分析工具，功能繁多而複雜，而LeakCanary則是由Square開源的一款輕量第三方內存泄漏檢測工具，當它檢測到程序中有內存泄漏的產生時，它將以最直觀的方式告訴咱們該內存泄漏是由誰產生的和該內存泄漏致使誰泄漏了而不能回收，供咱們複查。android

最近騰訊bugly也推出了三篇關於Android內存泄漏調優的文章：api

  1. 內存泄露從入門到精通三部曲之基礎知識篇
  2. 內存泄露從入門到精通三部曲之排查方法篇
  3. 內存泄露從入門到精通三部曲之常見緣由與用戶實踐

Realm一樣給出了性能優化文章：性能優化

10條提高Android性能的建議網絡

 

內存泄漏

爲何會產生內存泄漏？

當一個對象已經不須要再使用了，本該被回收時，而有另一個正在使用的對象持有它的引用從而致使它不能被回收，這致使本該被回收的對象不能被回收而停留在堆內存中，這就產生了內存泄漏。app

內存泄漏對程序的影響？

內存泄漏是形成應用程序OOM的主要緣由之一！咱們知道Android系統爲每一個應用程序分配的內存有限，而當一個應用中產生的內存泄漏比較多時，這就不免會致使應用所須要的內存超過這個系統分配的內存限額，這就形成了內存溢出而致使應用Crash。異步

Android中常見的內存泄漏彙總

單例形成的內存泄漏

單例模式很是受開發者的喜好，不過使用的不恰當的話也會形成內存泄漏，因爲單例的靜態特性使得單例的生命週期和應用的生命週期同樣長，這就說明了若是一個對象已經不須要使用了，而單例對象還持有該對象的引用，那麼這個對象將不能被正常回收，這就致使了內存泄漏。ide

以下這個典例：工具

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的生命週期的長短相當重要： oop

  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(mResource == null){
            mResource = 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。

線程形成的內存泄漏

對於線程形成的內存泄漏，也是平時比較常見的，異步任務和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銷燬時及時關閉或者註銷，不然這些資源將不會被回收，形成內存泄漏。

一些建議

  1. 對於生命週期比Activity長的對象若是須要應該使用ApplicationContext
  2. 對於須要在靜態內部類中使用非靜態外部成員變量（如：Context、View )，能夠在靜態內部類中使用弱引用來引用外部類的變量來避免內存泄漏
  3. 對於再也不須要使用的對象，顯示的將其賦值爲null，好比使用完Bitmap後先調用recycle()，再賦爲null
  4. 保持對對象生命週期的敏感，特別注意單例、靜態對象、全局性集合等的生命週期

  5. 對於生命週期比Activity長的內部類對象，而且內部類中使用了外部類的成員變量，能夠這樣作避免內存泄漏：

    1. 將內部類改成靜態內部類
    2. 靜態內部類中使用弱引用來引用外部類的成員變量

  6. 在涉及到Context時先考慮ApplicationContext，固然它並非萬能的，對於有些地方則必須使用Activity的Context，對於Application，Service，Activity三者的Context的應用場景以下：

其中：NO1表示Application和Service能夠啓動一個Activity，不過須要建立一個新的task任務隊列。而對於Dialog而言，只有在Activity中才能建立

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程