Android教程網
設為首頁|加入收藏
  1. 首頁
  2. Android 技術
  3. Android 手機
  4. Android 系統教程
  5. Android 游戲
 Android教程網 >> Android技術 >> Android開發 >> 關於android開發 >> Android性能優化之常見的內存洩漏

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

編輯：關於android開發

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


前言

對於內存洩漏，我想大家在開發中肯定都遇到過，只不過內存洩漏對我們來說並不是可見的，因為它是在堆中活動，而要想檢測程序中是否有內存洩漏的產生，通常我們可以借助LeakCanary、MAT等工具來檢測應用程序是否存在內存洩漏，MAT是一款強大的內存分析工具，功能繁多而復雜，而LeakCanary則是由Square開源的一款輕量第三方內存洩漏檢測工具，當它檢測到程序中有內存洩漏的產生時，它將以最直觀的方式告訴我們該內存洩漏是由誰產生的和該內存洩漏導致誰洩漏了而不能回收，供我們復查。

最近騰訊bugly也推出了三篇關於Android內存洩漏調優的文章：
1、內存洩露從入門到精通三部曲之基礎知識篇
2、內存洩露從入門到精通三部曲之排查方法篇
3、內存洩露從入門到精通三部曲之常見原因與用戶實踐

關於性能優化的文章，出自Realm.io：
10 條提升 Android 性能的建議

內存洩漏

為什麼會產生內存洩漏？

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

內存洩漏對程序的影響？

內存洩漏是造成應用程序OOM的主要原因之一！我們知道Android系統為每個應用程序分配的內存有限，而當一個應用中產生的內存洩漏比較多時，這就難免會導致應用所需要的內存超過這個系統分配的內存限額，這就造成了內存溢出而導致應用Crash。

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 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 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() {
            @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 {
        private WeakReference 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時先考慮ApplicationContext，當然它並不是萬能的，對於有些地方則必須使用Activity的Context，對於Application，Service，Activity三者的Context的應用場景如下：
這裡寫圖片描述
**其中：**NO1表示Application和Service可以啟動一個Activity，不過需要創建一個新的task任務隊列。而對於Dialog而言，只有在Activity中才能創建
3、對於需要在靜態內部類中使用非靜態外部成員變量（如：Context、View )，可以在靜態內部類中使用弱引用來引用外部類的變量來避免內存洩漏
4、對於生命周期比Activity長的內部類對象，並且內部類中使用了外部類的成員變量，可以這樣做避免內存洩漏：

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

5、對於不再需要使用的對象，顯示的將其賦值為null，比如使用完Bitmap後先調用recycle()，再賦為null
6、保持對對象生命周期的敏感，特別注意單例、靜態對象、全局性集合等的生命周期

  1. 上一頁:
  2. 下一頁:
關於android開發
開發入門初級開發中級開發高級開發關於android開發
相關文章
熱門文章
自用工程教程（一）建立開發環境與HelloWorld，自用helloworld Android Picasso 獲取遠程圖片並顯示， Android應用開發教程之二：最全的自定義View界面用法匯總 View事件分發機制，view事件分發 Android自定義dialog中的EditText無法彈出鍵盤的解決 Setting 之dashboard 點擊跳轉流程，settingdashboard
Android Gradle Build Error:Some file crunching failed, see logs for details解決辦法，gradlecrunching

Android Gradle Build Error:Some file
會話失效和PullToRefreshListView，pullrefreshlistview

會話失效和PullToRefreshListView，pullrefre
Android 手機衛士--實現設置界面的一個條目布局結構，android條目

Android 手機衛士--實現設置界面的一個條目布局結構，androi
Android中使用RecyclerView和CardView實現瀑布流效果(StaggeredGrid)

Android中使用RecyclerView和CardView實現瀑布流
閱讀排行版
Copyright © Android教程網 All Rights Reserved