使用Android Studio 遇到的坑爹問題及解決方法（持續更新中）

Android Studio（以下均簡稱為AS）是Google在2013年5月16日的I/0大會上推出的Android開發環境。

從最初的AS 1.5（我是從這個版本開始使用） 到現在的AS 2.1，這款開發工具有了很大的進步，而且更新頻率也是非常高。相較於Eclipse+ADT的開發環境；在某些方面，對開發者來說的確是方便了許多。

我待AS如初戀，AS虐我千百遍

但是，這樣一個開發環境，畢竟還很“年輕”，所以自身也會存在很多或大或小的bug,加上我們對它不是很熟悉（尤其是Gradle語法），給我們日常開發帶來了很多坑爹的問題，在此做個記錄，方便以後遇到時可以快速找到解決方法，同時分享給遇到同樣問題的同學一些解決思路。

操作環境：Windows10 + Android Studio 2.1

這裡只列舉解決方有共性的問題，有時候會遇到一種AS重啟（或者電腦重啟）之後就沒有問題的問題，這裡不再列出。重啟大法，真是時時刻刻都有用啊。

Gradle sync/building/refreshing 很長時間##

相信大部分人和我一樣，第一次使用AS的體驗並不是很好，一方面它很佔記憶體，導致自己電腦特別卡，尤其是在構建過程中，另一方面，對Gradle構建方式及其語法的陌生，導致初次用AS建立工程費了很大勁，所以對他並不是很看好。

我們選擇的AS的原因無非就是幾乎所有的人都開始用了，你在Github或者是一些論壇上找到的原始碼，幾乎都是AS版本的。而且有些很棒的三方庫，在AS上引入也許就是一行程式碼的事情，可是在Eclipse上幾乎是無法實現的，即便實現也得費很大的功夫。

有時候，我們從github上clone了一份大神的原始碼，想去解讀一下，結果匯入AS後就一直在哪裡building，也許等待很長一段時間後，可以building完成，但是我們完全可以省下這部分時間。

AS長時間的building，一般來說是去下載gradle檔案，也許你會說，我電腦檔案裡有gradle啊，就在下面這個目錄。

C:\Users\username\.gradle\wrapper\dists

的確，如果我們用AS正常的構建並編譯執行過一個工程的話，那麼這個資料夾下至少會有一個gradle-xx-all或gradle-xx-bin的資料夾，這個檔案下的內容其實就是AS用來構建工程所用到的東西。

所以，當我們clone到一份AS版本的原始碼時，不應該急著開啟，而是應該先去預覽一下兩個檔案：

build.gradle（這個是整個專案的gradle檔案）####

這個檔案裡有一行很重要的配置程式碼：

dependencies {

        classpath 'com.android.tools.build:gradle:2.1.2'

        // NOTE: Do not place your application dependencies here; they belong
        // in the individual module build.gradle files
    }

這個指定了我們整個專案要構建所需的Android Plugin版本。

這個地方我的經驗是，如果你clone到的原始碼裡所使用到的版本比這裡低，建議改成當前最新的版本。當然，如果你使用AS2.0及以上版本，它會自動提示你將Plugin版本升級為最新的。

gradle-wrapper.properties####

這個檔案，位於你所建立專案

XXApplication\gradle\wrapper

這個目錄下，我們可以看一下這個檔案

distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists
distributionUrl=https\://services.gradle.org/distributions/gradle-2.10-all.zip

最重要的就是最後一行配置，他決定了你整個專案構建時所需要用到的gradle檔案的版本，到這裡你應該明白了，當我們使用AS開啟clone到的原始碼時，他會按照這裡的配置gradle-2.10-all.zip，去之前所說的

C:\Users\username\.gradle\wrapper\dists

這個目錄下尋找gradle檔案，如果剛好找到了，那麼很幸運，你的專案不會build很長時間。如果沒有找到，那麼就得去下載gradle-wrapper.properties裡所配置的gradle版本了，這就解釋了我們第一次用AS建立Hello Wrold時為什麼等待了那麼長時間，因為要去下載一個檔案（而且得是翻牆）。

明白這些，這個問題就很好解決了。第一種辦法，很簡單，提前從這裡下載gradle-wrapper.properties裡所指定的gradle版本檔案，解壓後放在\dists\目錄下；這也是一種比較乖的方法，因為大神總是走在我們之前，他們當時寫下這些原始碼時候，所使用的gradle檔案版本可能比較老，所以為了保持原始碼不被更改，只能這樣做了。

第二種，比較討巧，你可以修改gradle-wrapper.properties的配置內容，將最後一行gradle版本修改為.gradle\wrapper\dists這個目錄下包含的版本，或者是你可以開啟你手頭正常執行的專案檔案，看看它的這個gradle-wrapper.properties是如何配置的，可做參考。

對於gradle-wrapper.properties裡所用到的gradle檔案和build.gradle中所依賴的gradle版本是否有嚴格的對於關係，尚不明確。

關於Instant Run的使用##

Instant Run 是AS 2.0之後提供的一種一邊修改程式碼，一邊在模擬器或者實際裝置上看到 修改程式碼後的結果的高大上功能。

說白了，就是Activity可以不用重新啟動，而你程式碼修改的內容就可以直接呈現出來，就是最近很火的熱更新。關於他的執行原理，可以看看這篇文章，已經做了很詳細的解釋。

其實，對於這個功能來說真是又愛又恨。愛是因為，這種Instant Run的確是可以節省一點時間，畢竟AS 編譯執行速度還是有點長，即便你的電腦是8G記憶體，i5處理器也是枉然。而恨，也恰恰是因為這種所謂的Instant Run，在剛開始使用AS 2.0的那段時間，常常有這樣一種體驗，程式碼明明改了為什麼不生效，TextView的顏色明明程式碼裡已經改成了綠色，為什麼一執行還是黑色。甚至，有時候導致我們開始懷疑自己程式碼的邏輯性，所以在很長一段時間裡都不能適應這個所謂的Instant Run，覺得完全就是添亂的。

但是，用的時間久了，當你漸漸熟悉了他的規律，理解了他的原理，你還是會覺得這個功能挺好的。

你可以通過設定，開啟或者關閉這個功能

佈局檔案無法預覽Exception raised during rendering##

有時候，我們會遇到layout下xml 佈局檔案無法檢視的情況，而出現的提示也是很簡單，就是一句話Exception raised during rendering。

這種AS無法渲染出檢視，而且xml程式碼沒有錯誤，無論怎樣修改，就是繪製不出佈局檔案的檢視。
這個一般是由於選擇的Android SDK 版本不穩定所導致的問題 ，切換成低版本即可。

Element layer-list must be declared問題##

這個問題的解決方法源自網路

專案從Eclipse轉到Android Studio。專案中使用了環信demo中的一些xml資源，轉換後發現color資原始檔夾下諸如layer-list或者shape等標籤報Element xxx must be declared錯誤，大意就是layer-list或者shape這些標籤沒有定義。
layer-list或者shape等這些標籤是常用的標籤，Android Studio居然報沒有定義錯誤，在Eclipse中卻沒有這個問題。網上不少人說這是Android Studio的一個bug，事實正相反，這是Android Studio的優點。

對於這個問題，首先要了解layer-list、shape等這些標籤是什麼東西。每一種標籤都有對應的資源類，layer-list、shape等等標籤代表的其實是個drawable資源。layer-list最終會解析為LayerDrawable，shape會解析為ShapeDrawable，其它的標籤類似。由此可以看出layer-list或者shape等資源是drawable資源，應該放到drawable資原始檔夾下。color資源不包括drawable資源，當然沒有定義drawable型別的標籤。
Eclipse不像Android Studio，對資源型別的檢查沒有那麼嚴格，所以沒有報錯誤。我覺得這倒是Android Studio的優點，是什麼資源就應該放到什麼位置，不容易讓人產生疑惑。

所以在Android Studio下的解決方法就是把這些資原始檔移動到drawable資原始檔夾下

Duplicate file copy in apk##

出現這個問題，一般是由於引用了重複的jar包，而且會在報錯日誌中提示兩個重複類的路徑。這種情況在引用了外部工程（在Android Studio中就是新建了Module），或者是匯入的第三方（如友盟）的SDK時很容易出現，因為外部引用的工程，一般是Github 上大神們寫的一些庫，方便我們使用。不同的外部工程中，使用了相同的jar包，這個情況時很有肯能發生的，列如support-v4的jar包，這個jar包幾乎成了應用的標配，這個時候我們只需刪掉其中的一個工程中的jar包即可。

Error:failed to find Build Tools revision xx.x.x##

我們從網路上clone一份原始碼，Sync時會提示這種問題。這個問題，其實很簡單就是app的
build.gradle 所宣告的編譯專案的SDK 版本我們沒有通過SDK Manager 下載，這個時候，你當然可以按照他給出的提示
Install Build Tools xx.x. and sync project 安裝所需的SDK版本，進行下載安裝，但這樣一般都會耗時，所以最簡單的方法就是修改app的build.gradle 中的buildToolsVersion 的內容，改成我們已經安裝過的SDK版本，如果不知道怎麼寫具體的版本號，完全可以參考電腦裡可以正常執行專案的這個配置資訊。

或者是如圖所示，在Project Structure 選單中選擇可用的SDK.

2016年7月27日更新

SSL peer shut down incorrectly##

這個問題的原因也很簡單，和之前提到的第一種情況是一樣的，就是下載gradle.xxx.zip檔案失敗了，這個時候，如果條件允許的話，就直接翻牆下載，如果條件不允許，可以考慮之前的辦法，從這裡手動下載gradle-wrapper.properties裡所指定的gradle版本檔案，解壓後放在\dists\目錄下，或者是直接修改gradle-wrapper.properties的內容。