編輯:關於Android編程
內存洩漏:是指內存得不到GC的及時回收,從而造成內存占用過多,從而導致程序Crash,也就是常說的OOM。
一、static
先來看下面一段代碼
public class DBHelper { private static DBHelper db= null; private DBHelper() { } public static DBHelper getInstance(Context context) { if (bitmapUtils == null) { synchronized (DBHelper.class) { if (db== null) { db= new db(context,DBNAME); } } } return db; } }
這樣的代碼在項目中很常見,如果大家仔細一點,應該能發現問題在那裡。helper中持有了context的應用,而DBHelper是全局的,也就是說,當在一個Activity中使用了DBHelper,即使這個Activity退出了,這個Activity也沒法被GC回收,從而造成Activity一直駐留在內存中。
這個解決方案也比較簡單,代碼如下
public class DBHelper { private static DBHelper db= null; private DBHelper() { } public static DBHelper getInstance(Context context) { if (bitmapUtils == null) { synchronized (DBHelper.class) { if (db== null) { db= new db(context.getApplicationContext(),DBNAME); } } } return db; } }
只需要把context改成ApplicationContext()即可,因為ApplicationContext本身就是全局的。
二、非靜態內部類、Handler
先來看一段代碼
private Handler handler = new Handler(){ @Override public void dispatchMessage(Message msg) { // 消息處理 } }; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); new Thread(new Runnable() { @Override public void run() { // 耗時操作 handler.sendEmptyMessage(1); } }).start(); }
我們知道非靜態內部類會持有外部類的引用,此時這裡的Handler持有著外部Activity的引用,當我們在Activity的內部類中進行異步耗時操作時,我們的Activity如果此時被finish掉了,而異步任務沒有執行結束,這就會導致我們的Activity對象不能及時的被GC回收,從而導致內存問題。
這樣的問題解決起來也很簡單
內存問題大多數都是因為對對象生命周期的不巧當處理造成的,在使用某個對象時,我們需要仔細研究對象的生命周期,當處理一些占用內存較大並且生命周期較長的對象時,應用使用軟引用對其就行處理,及時關閉不使用的資源。
以上就是本文的全部內容,希望對大家的學習有所幫助。
最近幾個項目的測試結果,Android無法主動通過調用 webview.loadUrl(javascript:+callbackFunction+(+data+)); 這
自定義View一直是自己的短板,趁著公司項目不緊張的時候,多加強這方面的練習。這一系列文章主要記錄自己在自定義View的學習過程中的心得與體會。刷微博的時候,發現微博運動
概述ViewPager是Android開發中使用場景非常頻繁的控件,單一的動畫效果切換已經越來越不能滿足追求個性化的應用中。而ViewPager自身也帶有一個接口來處理頁
(一).前言:這幾天正在更新錄制實戰項目,整體框架是采用仿照QQ5.X側滑效果的。那麼我們一般的做法就是自定義ViewGroup或者采用開源項目MenuDra