1、建立了一個對象後:
(1)沒有在適當的地方釋放掉
(2)在應該釋放的地方沒有做釋放操作
例如:下面一段程式:
m_progressDlg = ProgressDialog.show(this, getString(R.string.market),getString(R.string.is_visiting), true);
new Thread() {
public void run() {
boolean downloadOver = downloadwidgetInfo();
if (downloadOver) {
if(null != m_progressDlg)
m_progressDlg.dismiss();//該釋放這個對象,如果不釋放,應用會很容易出錯。
if(flag)
startIntent();
finish();
} else {
Message msg = mHandler.obtainMessage(mUphoneMain.Download_Fail);
mHandler.sendMessage(msg);
}
}
}.start();
上面一段代碼的隱患就在於else中沒有釋放progressDlg對象。如果程式一旦出錯,就會導致該progressDlg一直顯示在螢幕上,使應用程式死在這個介面上。
2、邏輯上嚴重錯誤:
(1)如果一個activity是在應用程式中處於過渡的作用,例如主要做一些下載等工作。那麼在這個activity中最好不要用Dialog相關的程式。如果有,這樣會導致一旦此activity在連網或者做某些事情導致異常的時候,就會發出致命錯誤。因為容易出現這樣一種情況:就是在應用程式掛掉的同時,通知了Dialog去在這個activity之上顯示一個Dialog。因為程式掛掉了,所以這個dialog就沒有了activity上下文Context的載體。
例如:有三個activity如下:
activity1:入口
activity2:過渡,負責下載網路資料,如果下載失敗,就跳出dialog報錯。如果成功就進入activity3.
activity3:
上面這個例子就會出現這種情況:activity2由於系統突然的異常但又突然的恢複後,有可能造成的activity2連結網路部分出現致命錯誤而被dalvic虛擬機器kill掉activity2.而此時你的程式有可能捕獲了異常,並將發送訊息來啟動一個異常dialog的提示框。因為dialog的Context上下文事activity2,但是activity2此時被killed了。從而出現應用程式的異常終止。
(2)在new一個Thread的時候,要特別注意這個Thread是否能被控制,或者是否要去控制。特別是在多個線程啟動的時候,在android上很難像寫java應用程式一樣很容易的控制住線程。在多個線程啟動的時候,一定要注意線程之間的邏輯。多個線程內部的程式的運行是否需要依賴其他線程內部的代碼的功能的完成。
例如:
new Thread1(){
public void run(){
Test1();//其中建立了一個類中的一個list資料結構。
}
}.start();
new Thread2(){
public void run(){
Test2();//其中用到了Thread1中建立的list的資料結構
}
}.start();
上面的這個程式就是線程2用到了線程1中建立的一個資料結構,如果第一個線程沒有完成,第二個線程啟動就會報錯。
3.混亂的思路造成混亂的代碼,混亂的代碼造成一個應用的混亂的bug。
(1)放棄很多類都使用到的函數公用化
(2)放棄主線程操作事件而採用多線程混亂執行操作。這樣容易造成線程的不可控以及邏輯的不明朗。為後續整理代碼的過程造成理解上的錯誤。
(3)做應用的邏輯思路不明朗,造成應用開發過程中的解決方案的頻繁修改,從而導致代碼很難維護
(4)產品定義的頻繁改動造成開發人員沒有明確的思路,在工程日前很緊的情況下造成代碼邏輯錯誤的增加
(5)只注重功能性代碼的實現而未考慮異常的捕獲以及對可能出現的錯誤沒有採取措施,這是bug出現最多的方面
(6)把寫damon小執行個體和寫工程代碼分開,最好別在工程代碼中測試你的damon,你的一時懶惰容易造成代碼的累贅和醜陋
4.總結:
(1)明確自己要做的,有目的性的構造自己的應用邏輯。
(2)別懶惰。別為了複製而複製,如果你認為一個類中的部分代碼在另一個類中需要用,別簡單的複製過來,想想第一條。
(3)把能夠功能化的代碼函數化,把能夠複用的代碼公用化,形成功能化的構件化代碼的思想。