Android下如何偵錯工具？

文章目錄

• 使用Eclipse開發平台調試
• 結合Android SDK調試
• 使用JUnit調試

寫代碼是每個程式員最樂意做的事，然而在開發中也會遇到很多令程式員很頭疼的事情。如果說讓程式員最頭疼的事情是看到無數bug、軟體的發布遙遙無期，那麼讓程式員最最頭疼的事情是程式在調試狀態下沒有問題然而在實際運行中確有問題。偵錯工具是每個程式員工作中必不可少的部分，而且可以毫不誇張地說偵錯工具暫用了程式員50%的工作時間。由此可見，偵錯工具是每個程式員必不可少的技術，調試水平的高低決定了程式員水平的高低。在開發Android程式前，有必要總結下如何調試Android程式。目前就開發過程中，常用偵錯工具的方法總結如下：

1. 使用Eclipse開發平台調試；
2. 結合Android SDK調試；
3. 使用JUnit調試；

使用Eclipse開發平台調試

這是使用Eclipse工具開發Android必須熟練掌握的調試技術，主要包括：設定斷點、查看變數值、查看當前堆棧等。開啟Eclipse工具，單擊“Run”

以及在調試的過程中，開啟其他調試面板，相信只要使用一次就完全明白了。不要小瞧這些調試工具，只要你細心，說不定其他同事好幾天沒有解決的bug，你通過這些工具就發現了。所以熟練使用這些工具，是開發人員必須的，在有些時候甚至可以事半功倍的效果。

結合Android SDK調試

在複雜的程式運行過程中，如何偵錯工具了？把程式運行過程的資訊儲存為檔案或者輸出到IDE中，這樣就可以知道程式是否是正常運行了。

在Android中可以使用Log類，Log類在android.util包中，可以使用它將運行過程的資訊輸出到IDE中，直接查看程式啟動並執行過程。Log 類提供了若干靜態方法 ：
Log.v(String tag, String msg);
Log.d(String tag, String msg);
Log.i(String tag, String msg);
Log.w(String tag, String msg);
Log.e(String tag, String msg);

分別對應 Verbose，Debug，Info，Warning，Error。 tag是一個標識,可以是任一字元串，通常可以使用類名+方法名，主要是用來在查看日誌時提供一個篩選條件。程式運行後，在show view中選擇Locat就可以直接看到輸出了。也可以在程式運行後，可以通過DDMS 查看程式的運行過程記錄，並可以通過String tag來過濾輸出的資訊，關於Android DDMS如何使用，請閱讀Android
DDMS使用詳細說明。

除了以上方法外，我們也可以把程式運行過程資訊的輸出當作程式啟動並執行一部分，比如使用Toast Notificatio將輸出資訊顯示在介面中，當然這些只是些調試代碼，在發布程式時需要去掉。

最後一種方法，也是最有效一種方法，直接將運行過程的資訊以檔案的方式儲存，在程式運行後開啟檔案，查看輸出的資訊。在一些複雜的工具中，都是用這種記錄檔的方法來記錄檔案啟動並執行過程。如何在Android中讀寫檔案，請閱讀Android資料存放區（總結篇）。

看了以上2種方法是否覺得：以上只是在發現問題後找到問題的原因，解決問題，是不是有些被動的、消極的，有沒有其他有效方法來避免bug？看到這裡，有些“牛”人就說了：我寫的代碼幾乎沒有bug，My Code好幾年都沒有發生過崩潰現象了。從我個人的觀點說：的確牛。至少我自己，感覺自己的代碼似乎很脆弱，要想寫一個完全正確的代碼真的不容易。自己考慮了很多，為什麼會這樣，難道是自己寫的代碼的確很差？至少我自己在寫代碼的過程中都是很仔細的，盡量把問題考慮清楚了在寫的，每次修改都是小心翼翼的！後來發現，每段代碼在寫的時候都是有一些“運行環境”的，在後來使用的過程中，這個環境逐漸被破壞，以致最後修改的亂七八糟。如果你也有同受，建議你仔細閱讀以下說明！

使用JUnit調試

Android增加了對JUnit的支援，這對程式員來說，是個很好訊息。

首先說明下JUnit是用來解決什麼問題的？JUnit是採用測試驅動開發的方式，也就是說在開發前先寫好測試代碼，主要用來說明被測試的代碼會被如何使用，錯誤處理等；然後開始寫代碼，並在測試代碼中逐步測試這些代碼，直到最後在測試代碼中完全通過。

看了是否感覺有些不符合程式員的思維習慣（先寫代碼然後在調試），的確這也是JUnit是對程式員思維的“顛覆”。在這裡我自己也感覺，好像很難做到，為什嗎？在一匹“馬”沒有完全設計好前，怎麼規定這匹“馬”將來會如何跑？而且即使把“馬”將來會如何“跑”定義好了，在實現的時候“馬”被改變了怎麼辦？說到底還是：一個人不能同時具有2個角色，否則自己有時候就不知道當前是哪個角色！

說到這裡，我就說明下，我自己對JUnit “錯誤”的使用方法，這也許與JUnit測試驅動開發的目的相矛盾，但是的確可以有效地減少bug。JUnit從核心來說就是將原始碼與測試代碼完全分開，將測試代碼作為一個單獨的程式。前面介紹的方法，都將原始碼與測試代碼合為一體，由於原始碼的重要性大於測試代碼的重要性，所以測試代碼經常有不完整、結構不清晰等問題，這樣程式員的單元測試也就不完整。JUnit就是被我用來做完整的單元測試，對當前的部分代碼，測試其在每種“環境”下的運行結果。
現簡要說下JUnit的幾個主要功能：

1. JUnit首先有管理測試案例的功能。修改了哪些代碼，這些代碼的修改會對哪些部分有影響，通過JUnit將這次的修改做個完整測試。這也就JUnit中所謂的TestSuite。
2. 如何定義需要測試的代碼？這也就是JUnit中所謂的TestCase，根據原始碼的測試需要定義每個TestCase，並將TestCase添加到相應的TestSuite方便管理。
3. 如何定義測試的“環境”？在TestCase測試前會先調用“環境”配置，在測試中使用，當然也可以在直接測試案例中定義測試“環境”。
4. 最為重要的部分，測試結果的檢測。對於每種正常、異常情況下的測試，運行結果是什麼、結果是否是我們預期的等都需要有個明確的定義，JUnit在這方面提供了強大的功能。

以上部分與我們平常使用IDE調試的過程是完全一樣的，只不過是增加了測試案例管理、測試結果檢測等功能，提高了單元的效率，保證了單元測試的完整性，明確了單元測試的目標。帶著以上4個問題，簡要舉例並分析如下：
原始碼如下：
public class SampleCalculator
{
public int add(int augend , int addend)
{return augend + addend ;}
public int subtration(int minuend , int subtrahend)
{return minuend – subtrahend ;}
}
測試代碼（TestCase）如下：
import junit.framework.TestCase;
public class TestSample extends TestCase
{
public void testAdd()
{
SampleCalculator calculator = new SampleCalculator();
int result = calculator.add(50 , 20);
assertEquals(70 , result);
}
public void testSubtration()
{
SampleCalculator calculator = new SampleCalculator();
int result = calculator.subtration(50 , 20);
assertEquals(30 , result);
}
}
以上TestSample測試案例中就對SampleCalculator進行了完整的單元測試，並對測試結果做了預期說明。當然還需要將TestSample增加到TestCase中方便管理。
import junit.framework.Test;
import junit.framework.TestSuite;
public class TestAll{
public static Test suite(){
TestSuite suite = new TestSuite(“TestSuite Test”);
suite.addTestSuite( TestSample.class);
return suite;
}
}

以上就將TestSample增加到”TestSuite Test”中，將來在選擇測試案例的過程中只要選擇了TestSuite Test，TestSample就將加入當前測試中。如果將來SampleCalculator增加了其他功能，只需要在TestSample增加相應的測試，就可以對TestSample進行完整單元測試。

看到這裡對上面4個問題，應該都有了大致的瞭解。最後需要說明的：對TestCase的管理，是完全介面化的，只需要按照JUnit的要求實現會自動產生UI介面，這個不必擔心，還需要下載JUint packeage，根據需求選擇自己需要的。大膽嘗試下，你會發現編程真的可以如此“美好”。

複製搜尋

複製搜尋