- 相關推薦
Android編碼的常見錯誤及解決方法分享
在android編碼中，會有一些簡便的寫法和編碼習慣，會導致我們的代碼有很多內存泄露的問題，在這里做一個已知錯誤的總結：
1、編寫單例的時候常出現的錯誤。
錯誤方式：
public class Foo{ private static Foo foo; private Context mContext; private Foo(Context mContext){ this.mContext = mContext; } // 普通單例，非線程安全 public static Foo getInstance(Context mContext){ if(foo == null) foo = new Foo(mContext); return foo; } public void otherAction(){ mContext.xxxx(); …. } }
錯誤原因：
如果我們在Activity A中或者其他地方使用Foo.getInstance()時，我們總是會順手寫一個『this』或者『mContext』（這個變量也是指向this）。試想一下，當前我們所用的Foo是單例，意味著被初始化后會一直存在與內存中，以方便我們以后調用的時候不會在此次創建Foo對象。但Foo中的『mContext』變量一直都會持有Activity A中的『Context』，導致Activity A即使執行了onDestroy方法，也不能夠將自己銷毀。但『applicationContext』就不同了，它一直伴隨著我們應用存在（中途也可能會被銷毀，但也會自動reCreate），所以就不用擔心Foo中的『mContext』會持有某Activity的引用，讓其無法銷毀。
正確方式：
public class Foo{ private static Foo foo; private Context mContext; private Foo(Context mContext){ this.mContext = mContext; } // 普通單例，非線程安全 public static Foo getInstance(Context mContext){ if(foo == null) foo = new Foo(mContext.getApplicationContext()); return foo; } public void otherAction(){ mContext.xxxx(); …. } }
2、使用匿名內部類的時候經常出現的錯誤
錯誤方式：
public class FooActivity extends Activity{ private TextView textView; private Handler handler = new Handler(){ @override public void handlerMessage(Message msg){ } }; @override public void onCreate(Bundle bundle){ super.onCreate(bundle); setContextView(R.layout.activity_foo_layout); textView = (TextView)findViewById(R.id.textView); handler.postDelayed(new Runnable(){ @override public void run(){ textView.setText(“ok”); }; },1000 * 60 * 10); } }
錯誤原因：
當我們執行了FooActivity的finish方法，被延遲的消息會在被處理之前存在于主線程消息隊列中10分鐘，而這個消息中又包含了Handler的引用，而Handler是一個匿名內部類的實例，其持有外面的FooActivity的引用，所以這導致了FooActivity無法回收，進而導致FooActivity持有的很多資源都無法回收，所以產生了內存泄露。
注意上面的new Runnable這里也是匿名內部類實現的，同樣也會持有FooActivity的引用，也會阻止FooActivity被回收。
一個靜態的匿名內部類實例不會持有外部類的引用。
正確方式：
public class FooActivity extends Activity{ private TextView textView; private static class MyHandler extends Handler { private final WeakReference
3、在使用handler后，記得在onDestroy里面handler.removeCallbacksAndMessages(object token);
handler.removeCallbacksAndMessages(null); // removeCallbacksAndMessages,當參數為null的時候，可以清除掉所有跟次handler相關的Runnable和Message，我們在onDestroy中調用次方法也就不會發生內存泄漏了。
開發中需要注意的點以免內存泄漏：
1.不要讓生命周期長于Activity的對象持有到Activity的引用 2.盡量使用Application的Context而不是Activity的Context 3.盡量不要在Activity中使用非靜態內部類，因為非靜態內部類會隱式持有外部類實例的引用（具體可以查看細話Java：”失效”的private修飾符了解）。如果使用靜態內部類，將外部實例引用作為弱引用持有。 4.垃圾回收不能解決內存泄露，了解Android中垃圾回收機制
獲取context的方法，以及使用上context和applicationContext的區別：
1.View.getContext,返回當前View對象的Context對象，通常是當前正在展示的Activity對象。 2.Activity.getApplicationContext,獲取當前Activity所在的(應用)進程的Context對象，通常我們使用Context對象時，要優先考慮這個全局的進程Context。 3，ContextWrapper.getBaseContext():用來獲取一個ContextWrapper進行裝飾之前的Context，可以使用這個方法，這個方法在實際開發中使用并不多，也不建議使用。 4.Activity.this 返回當前的Activity實例，如果是UI控件需要使用Activity作為Context對象，但是默認的Toast實際上使用ApplicationContext也可以。
大家注意看到有一些NO上添加了一些數字，其實這些從能力上來說是YES，但是為什么說是NO呢？下面一個一個解釋：
數字1：啟動Activity在這些類中是可以的，但是需要創建一個新的task。一般情況不推薦。
數字2：在這些類中去layout inflate是合法的，但是會使用系統默認的主題樣式，如果你自定義了某些樣式可能不會被使用。
數字3：在receiver為null時允許，在4.2或以上的版本中，用于獲取黏性廣播的當前值。（可以無視）
注：ContentProvider、BroadcastReceiver之所以在上述表格中，是因為在其內部方法中都有一個context用于使用。
好了，這里我們看下表格，重點看Activity和Application，可以看到，和UI相關的方法基本都不建議或者不可使用Application，并且，前三個操作基本不可能在Application中出現。實際上，只要把握住一點，凡是跟UI相關的，都應該使用Activity做為Context來處理；其他的一些操作，Service,Activity,Application等實例都可以，當然了，注意Context引用的持有，防止內存泄漏。
【Android編碼的常見錯誤及解決方法分享】相關文章：
常見的六個IE錯誤與解決方法11-18
android5.0系統奔潰解決方法04-18
寬帶連接錯誤651解決方法08-23
寬帶連接錯誤1717的解決方法12-08
新手開車的駕駛錯誤及解決方法04-14
內存常見故障的解決方法03-11
聲卡常見故障的解決方法11-25
電飯煲常見故障及解決方法11-25
寬帶連接錯誤678解決方法及步驟11-19
跳遠易犯錯誤及解決方法08-25