在閱讀這邊文章之前：其實有一個更容易的方法匯入第三方jar包：

直接把jar包下載下來，然後直接拷貝到工程libs目錄下即可，如果是不需要檢視第三方jar包的原始碼，是用的話，僅此而已即可，但是有時候我們需要檢視匯入的第三方jar包的原始碼，以方便我們瞭解實現原始碼，這時候我們就需要把匯入的jar包連結到其原始碼上，這個方法是：首先也是把下載下來的jar包(例如：jsoup-1.72.jar)拷貝到libs下，然後在下載jar包對應的帶原始碼的jar包(jsoup-1.72-sources.jar)，之後再右鍵點選工程->【Build Path】->【Configure Build Path】->【Libraries】->【Android Dependencies】->【Add JARs】->選中libs中的jar包(jsoup-1.72.jar)->【Source attachment: none】->【Eidt】->連結到jsoup-1.72-resources.jar，即可。

最近在學習一個Android技術點時，需要在工程專案中引入第三方jar包，遇到的問題是在編譯的時候能通過，但是在實際執行的時候會出錯。後來經過調研發現，原來是在引入第三方jar包的時候出錯了，現在總結已經成功的兩種方式。

一 使用Build Path中的Order and Export選項卡

1.將例項Android專案（project原始碼）import到Eclipse中，這時由於第三方jar包路徑和原作者的存放路徑不一致，專案會提示紅叉叉，不能進行編譯；

2.下載第三包jar包3rd.jar儲存到本地，然後通過Build Path→Configure Build Path→Libraries

```

```點選“OK”

3.接著，我們到模擬器上Run下這個專案，模擬器啟動是在是太慢了，這個時候，我們可以喝點水，上個廁所，站起來走走。程式設計師，要對自己的身體好一點。我這次就不去廁所了，寫這篇文章呢。模擬器還崩潰了一次，悲劇，只得again......

結果：

到logcat中查錯唄：

4.重新配置Build Path：

繼續Build Path→Configure Build Path→Order and Export，將裡面的3rd.jar

再run一次：

還是報錯？！蝦米情況！！！

別急Project→clean一下當前專案，再run一次就得到正確結果了。

Success！

思考：如果第三方jar包只有一個這樣做還好說，如果在專案中引入的jar包很多，這是可參考第二種方法。

二 建立自己的 Source Folder

1.Build Path→New Source Folder→給第三方jar的資料夾起個名字，例如3rd.jar→將所有的第三方jar包全部複製黏貼到這個包下面：

2.複製黏貼所有第三方jar包：

3.這個時候，僅僅是將這個新建的Folder新增到Build Path中去，複製過來的3rd.jar還是沒有新增進去的，這時，選中3rd jar檔案下面的所有第三方jar包，右鍵→Add to Build Path：

```我們看看這裡發生了什麼變化：

為了區別之前的，我在這裡clean一下。

結果：成功，success！

==================================================================================================================

總結：

其實這個問題的核心是：有沒有將第三方jar包新增至新apk檔案的Build Path中去。

什麼是Build Path？其實在這裡（Android Project最後構建成apk檔案）顧名思義，就是最後apk檔案構建的資源在該專案中存放的路徑。結合這裡的實際情況，在正確的Order and Export選項卡里面，預設勾選了3個路徑：src、gen和我們自定義的3rd jar，這就表示，我們的3rd jar包將會直接構成最後的apk檔案（部分還是全部?）。

我們結合Order and Export選項卡的註釋來看下：構建class檔案路徑的順序和匯出條目，匯出的條目對依賴的專案有效。

我們電腦上的Eclipse IDE開發環境是配置了本地的JDK環境的（環境變數classpath），我們將已經為Eclipse配置好的JDK環境當做第一方，我們為第二方，那麼3rd.jar就是第三方了。（不知道正確與否，我是這麼理解的）

在Eclipse上開發當前專案的時候，我們預設依賴的是本地JDK環境裡面的工程（這裡的工程就是一個個的jar檔案），如果要引入第三方（工程）jar的話，必須要新增額外的jar檔案（工程檔案），保證能通過編譯，也就是當前專案沒有紅叉叉，允許你去run。

噹噹前專案構建好（Build）apk檔案（project）後，我們用模擬器去執行。請注意這時候環境開始發生了微妙的變化，現在當前的執行環境是Android SDK的dalvikvm（而不是為Eclipse配置的本機JRE環境，那是一般的Java專案的執行環境，我們現在是Android Project）。對於dalvikvm來說，apk是它的一個project；同理，在Eclipse開發過程中，當前專案明顯是它的一個project（Android Project），額外引用的3rd.jar包也是它的一個project。在專案的開發階段，我們自己的當前專案依賴了3rd.jar，在專案構建成apk檔案（project）的時候，如果我們不將3rd.jar這個工程設為Exported（讓依賴當前Android Project的apk project也能依賴3rd.jar）。在apk檔案執行時，當apk執行到需要依賴3rd.jar流程的時候，dalvikvm環境無法訪問3rd.jar project中的class檔案，自然就會報錯。

依賴關係分析：

在實際執行的時候：apk project依賴我們開發的Android Project，而Android Project又依賴3rd.jar project，相當於apk project間接依賴3rd.jar project，這種間接關係應該是不能自動傳遞的，需要進行手動設定，也就是在構建apk project的時候，把3rd.jar project設為Exported，讓它可以被apk project間接依賴，當然apk project是直接依賴Android Project的。

第二種方法完全就是將3rd.jar project和Android project一起構建（打包）成apk project，然後部署（安裝）在dalvikvm中執行，其實也是相當於在dalvikvm執行環境中直接添加了一個3rd.jar。

通過檔案的大小分析，我們發現第一種export的方式比第二種直接構建的方式構建成的正常apk檔案要小一些。具體是：第一種方法正常情況下apk檔案大小306KB；第二種方法下正常情況下apk檔案大小334KB。apk異常情況時大小是295KB。3rd.jar的大小是33.7KB。我也不知道具體原因，猜測是進行了“結合編譯”，也就是將Android Project和3rd.jar project在編譯的時候結合起來，比如去掉相同的地方，從而構建成apk project；或者是“有效編譯”，也即是隻將3rd.jar中有效有用的部分整合到Android Project中去，然後構建成apk project。本人也只是菜鳥一隻，只能這樣猜想一下，憑目前的知識水平，還不知道到底是怎麼回事，也不知道如何去驗證，如有高手能賜教一二的話，不勝感激。當然由於本人的水平有限，本文中的語言和詞彙肯定有表述不當的地方，大家自己辨別了，這只是我的個人理解。建議大家無論什麼時候都不要盡心他人言，官方的文件才是你最堅實後盾。