標籤：

Android Studio編譯慢、卡死和狂佔內存怎麼破？

01-11

Google現在最推薦的IDE是Android Studio，可是我用了的體驗是——還能不能讓人好好的寫程序了…

首先是編譯慢，而且不是首次編譯慢，是次次編譯慢，動不動一編譯就是十幾分鐘，想必大家寫程序也沒有誰是一次性寫好、編譯就OK的吧，大部分還是要改改、編譯、看看，然後再改改。這每編譯一次十幾分鐘，還怎麼寫程序？別跟我講網上那些方法，什麼並行，什麼自動編譯，都沒有本質性的改善。

再就是卡死，寫幾個字母就卡一回，比如你要敲一個變數，它自動出列表時要卡，寫一個函數，自動出參數提示時要卡，總之，沒個十幾分鐘你別想敲完一行代碼。而且這種卡死是真正的系統級的卡死，即使你想趁這時間切到瀏覽器去看看網頁都切不過去，好幾分鐘切過去了，再切回來就看到Android Studio給你一個純白的白屏幕……

再就是內存佔用，之前還沒注意，有一回等得無聊打開任務管理器一看，studio.exe的CPU佔用超50%，內存佔用在以每秒增加好幾M的速度一直上漲，而且是只增不減，一會兒就增加到700多M了。我一XP系統，本來系統就只能識別2G內存，你就給我吃掉700多M…如果是個瀏覽器、QQ或者下載工具什麼的大不了關掉就是，可是你是IDE，我總歸還得開發呀，打不得罵不得，只有自己忍著生悶氣。

各位同道們，你們也是這樣么？要怎麼解決啊啊啊

21世紀 20 年代，還在用著 2G 內存的電腦，你可以轉行了。沒有合適的設備，什麼招都沒用。Android Studio 本就占內存，設備爛卡死是必然的，要解決卡死的問題，一定要升級硬體設備。其他人說的答案迷惑性還都挺強的，然而都是一定程度上加快編譯速度，並不能解決卡死的問題，也沒有人能夠解釋為什麼那樣做可以加快編譯速度。

至於加快編譯速度，有一句說一句，我覺著一些答主的答案適用性都並不強，其實還是應該從 gradle 入手，講的有什麼不合適的地方，還請輕噴，有什麼問題也可以留言。

以下我講到的所有步驟，推薦都在終端里執行。在終端里執行編譯有很多好處：

  1. 可以觀察到整個編譯過程，有助於理解 gradle 構建流程；
  2. 可以看到編譯過程中哪些任務比較耗時，可以對編譯慢的問題對症下藥；
  3. 可以隨時終止編譯，如果被卡在某個階段，ctrl + c 可以隨時終止編譯，在 Android Studio 里也終止編譯，但是基本上十次有九次都會失敗；
  4. 因為是在終端里，對 Android Studio 影響極小，基本不會造成 Android Studio 卡頓；
  5. 不會遇到 Android Studio 的各種 bug 。

先說一下 gradle 的生命周期吧，gradle 構建一個工程主要分為三部分（完全掌握了下面這張圖，整個 gradle 的構建過程能了解個十之七八了）：

  1. 初始化階段：主要是解析 setting.gradle 文件（因此有人提到減少 setting.gradle 的 module 數量，是很有道理的，但是實際操作過程限制頗多，原因最後會大致說一下）；
  2. 讀取配置階段：主要是解析所有的 projects 下的 build.gradle 文件，包括 rootProject 和其他的 subprojects（子項目），檢查語法，確定 tasks 依賴以建立 task 的有向無循環圖，檢查 task 里引用的文件目錄是否存在等（這一步也進一步驗證了減少 setting.gradle 里的 module 數量可以加快編譯速度，因為減少一個 module ，需要解析的 build.gradle 文件就減少一個，第 3 步里就不會執行本屬於這個 module 的任務了，但是還是 1 裡面說的問題，限制頗多）；
  3. 執行階段：按照 2 中建立的有向無循環圖來執行每一個 task ，整個編譯過程中，這一步基本會佔去 9 成以上的時間，尤其是對於 Android 項目來講，將 java 轉為 class

    compileDebugJavaWithJavac/compileReleaseJavaWithJavac

    和 將 class 合併成 dex

    transformClassesWithDexForDebug/transformClassesWithDexForRelease

    這兩步很耗時，第一步還好，第二步會耗時非常久。首先在 gradle.properties 里設置

    org.gradle.jvmargs=-Xmx4096m //越大越好

    ，然後在工程的 build.gradle 里的 android 結點下增加 dexOptions 配置，如下：

dexOptions {
dexInProcess true
preDexLibraries true
javaMaxHeapSize "4g"//越大越好
incremental true
}

明確了 gradle 的生命周期，那麼就可以看到加快編譯速度的關鍵就是從第三步入手，當然，減少 setting.gradle 里的 modules 數量這一步也是必須的。下面說說我們公司的實踐吧。

  1. 項目插件化改造，每位業務上的同學只需要編譯一個模塊即可，這一點基本上從根本上解決了編譯慢的問題（對於大多數沒有插件化需求的朋友們可以看下面的一些實踐），首先 setting.gradle 里的 module 只有自己開發的模塊了，而對應的執行階段的任務也只有這一個 module 的任務了。
  2. 執行一次 gradle build ，我們就會發現，在這個過程中，其實是執行了多次打包任務的，在 buildTypes 里配置了多個編譯打包類型，默認有 debug 和 release ，我們還可以手動配置其他的類型，而且還有 productFlavor 里的多渠道，這樣就會執行多次編譯打包，而正常開發過程中，只需要打 debug 包去調試，因此使用 gradle assembleDebug 即可，等發版的時候使用其他方式去打多渠道的包（如美團的方案http://tech.meituan.com/mt-apk-packaging.html）；
  3. 既然編譯主要時間都集中在 gradle 生命周期的第三步執行 task 任務里，那麼我們就可以把一些無關緊要的任務給禁用掉，比如各種 Test ，各種 lint 等，剛好在 gradle 里有這樣的指令 -x lint 可以臨時禁掉 lint 任務，-x test 可以禁掉 test 任務，事實上對於一個稍微大一點的項目，lint 也是很耗時的，當然也可以通過 gradle 腳本徹底禁用 lint 和 test 任務，我也在一些微信群里分享過相關代碼，但是不太建議這麼做，因為有時候 lint 和 test 也是挺有用的；
  4. gradle 本身提供了一些指令參數可以加快編譯，比如 --daemon ，開啟守護進程，--parallel ，開啟並行編譯等，這個也可以在 gradle.propertites 里配置（編譯使用的 jvm 內存也可以在這裡配置）。
  5. 定製 gradle 編譯流程，利用官方提供的 API 完全可以定製一個適合自己的編譯流程，可以參考一下攜程的 DynamicAPK/sub-project-build.gradle at master · CtripMobile/DynamicAPK · GitHub，裡面有攜程他們自己整個完整的編譯流程，腳本本身很簡單，一共只有兩三百行代碼。

上面講到的幾點，現有環境就可以做到的大概是這樣（有一點要特別注意，如果工程里有交叉依賴，一定不要使用 --parallel 參數）：

gradle assembleDebug --daemon --parallel -x lint -x test

，如果是要直接安裝到設備上的話，就把 assembleDebug 換成 installDebug ，assembleDebug 可以簡寫為 asD ，installDebug 可以簡寫為 iD 。

最後講一下，為什麼減少 setting.gradle 里的 module 數量，確實可以加快編譯，但是卻限制頗多呢？

首先，我們想一下整個編譯過程，先去解析 gradle 配置，建立 tasks 依賴有向圖，然後再去執行每一個 module 的 task ，如果我們通過 maven 依賴，使用 aar 替掉了 module（單指 android library），如果我們要改這個 module 里的文件，豈不是每次都要修改上傳再下載，這其實還好，但是有一個致命的問題：不修改版本號的話，SNAPSHOT 在 IDEA 里經常會不好使。這樣就導致修改的東西會不生效，去解決這個問題是非常耗費時間的。不過有一種方式，可以一定程度上解決問題，增加下面的腳本：

project.configurations.all(new Action&() {
@Override
void execute(Configuration files) {
files.resolutionStrategy.cacheDynamicVersionsFor(5, TimeUnit.MINUTES)
files.resolutionStrategy.cacheChangingModulesFor(0, TimeUnit.SECONDS)
}
})

那有人會問，插件化里，每個人開發一個模塊，對於每個模塊的維護不也是要打包上傳到 maven ，每次一有修改，哪怕是非常微小的修改，也要做一次上傳，同樣會遇到 SNAPSHOT 不好使的問題。嘿嘿，這個問題嘛，我司自己維護了一個 gradle 插件，已經解決了，至於解決方案，是公司機密，我是不會講的。

然後，還有一點，我相信大部分開發者平常開發都是單 module 的，多 module 的情況並不多，因此大多數依賴基本也都是 aar 或者 jar ，根本就不存在所謂的將 library 轉成 aar 上傳的情況，因此一些答主說的根本毫無意義，這也是為什麼我會說影響編譯速度的情況主要集中在 gradle 生命周期的第三個階段，至於第三個階段的優化，看我上面的答案就好了。

網上說了許多的方法，比如設置內存空間，修改gradle配置，離線模式使用緩存的庫等等，其實實測效果並不明顯。減少依賴工程，把依賴工程打包成aar是一種相對效果較好的方案。然而在實際開發中，那些需要經常修改的依賴工程打包成aar就比較麻煩，曾經想通過自己的maven私服來做中轉 實際也用不上。應為我們一次run之後，依賴工程編譯生成的aar已經copy到主工程的build某某目錄下。如果依賴工程沒有修改，再次run的時候是不重複編譯的 實際符合我們的開發需求。建議，果斷時間清理下as的緩存。但是對於大項目，你怎麼倒都沒有，還可以一種做法，將項目分拆，對於一些調試比較多的開發，比如調個動畫，完全可以寫個Demo，調好了挪過去就好啦，很多功能不是非得在主工程裡邊跑，但是這對軟體的設計要求就比較高，最近在研究這一塊。

工程盡量減少對module的直接依賴，將不需要頻繁改動的module從setting.gradle中去掉，直接引用module對應的aar文件。工程中有多個module時，會先編譯每一個module之後再編譯主工程，盡量少的module依賴肯定會加快編譯速度。

你這個配置,我感覺想要流暢也就是筆記本了

我看到了XP......題主在學校機房上AndroidStudio？

少年，你這個配置，搞開發，開發什麼也會卡啊，

先換電腦。rmbp i7 256g固態，編譯的時候也慢，JRebel for android 曲線救國

2G的內存還是用eclipse吧……不過好像不支持aar,你可以找找看有沒有支持aar的插件…建議還是換電腦，台式機i5以上，8G內存以上，就可以了。

這個問題只能靠硬體解決，當年用Macbook Air開發時滾動代碼都會卡，那酸爽。

後來換了MacbookPro 16G後，基本能鎮壓主Android Studio。建議硬體配置內存16G以上，CPU 最好上i7。

硬體配置上來後使用Studio就愉悅了。

首先，你用xp，這是一個早已經過時的系統，不僅本身有問題，而且各種軟體都不在針對其進行優化。

其次，你只有2G ram，放在手機上也只是勉強，竟然用作開發。 這是哪個坑爹的公司？敢報名字嗎？

第三，xp系統32位的最大支持接近4G的ram，對於一個使用xp系統又為內存困擾的程序員來說，這難道不是常識？

解決方法：把電腦砸地上，狠狠的跺上幾腳，對著坑爹老闆高喊我要用Mac！

You can speed up your Eclipse or Android Studio work, you just follow these:

  1. Use/open single project at a time
  2. clean your project after running your app in emulator every time
  3. use mobile/external device instead of emulator
  4. don"t close emulator after using once, use same emulator for running app each time
  5. Disable VCS by using File-&>Settings-&>Plugins and disable the following things :
    CVS Integration,
    Git Integration,
    GitHub,
    Google Cloud Tools for Android Studio, and
    Subversion Integration.

16g 也卡，準備換32g

依照你現在開發環境不建議你用Android Studio的，我們的主要目的在於開發軟體，如果as讓你開發受阻你還是用回Eclipse，等以後電腦配置好了，或者有時間閑下來了再去折騰不晚~

Google的軟體從來都不考慮低配性能問題

開發...你用2G我也是醉了

Android Studio裝在4G內存的電腦上我都嫌不行換到8G

你還是砸了吧 2G沒救

我之前安裝studio的時候總是一運行就卡死，後來看了很多博客，解決了。但是我也不太明白，可以看看的博客。

安裝android studio 卡死的解決方案

2G……內存，好古典，那就不要用Android Studio。 換ubuntu ，vim code,手動編輯編譯腳本, 敲命令編譯。用到虛擬機的話，ubuntu 下跑x86 img 。

樓主推薦你看一篇文章,深入講解android apk的構建過程，並在重要節點做優化 http://www.jianshu.com/p/53923d8f241c

開發的話，建議用安卓手機上跑測試，而不是用模擬器，那個東西啟動慢，佔用資源多，

其次，現在谷歌官方的AS已經更新到2.2.x版了。好歹把電腦升級為i5處理器，8GB以上內存，120GB以上SSD。

我的剛開始也是卡，就是第一次編譯時卡（14分鐘左右），我看了下buid情況，每次編譯時我的內存只剩下300多M,cpu100%利用(cpu是i5的對於開發還行吧)，然後我加了一個4G(原來是8G的)內存每次編譯6-7分鐘，速度明顯提高了50%，我又把4G內存換成8G的現在就是16G,感覺沒變化，你的電腦是不是配置太低了，加一下內存看看？？

1. 編譯慢的問題：Android工程編譯加速

2. 電腦卡死的問題：

方案一：使用編輯器，例如Vim、Atom、Sublime，使用命令行編譯安裝，這樣你就脫離了AndroidStudio；

方案二：換高配置電腦

推薦閱讀：

※為什麼就算配置很高的 Android 手機玩遊戲感覺畫面也沒有 iPhone 流暢，而且觸屏感覺比較遲鈍？
※如何在android面試中把Activity的生命周期說的很有逼格？
※如何成為一名合格的 Android 開發工程師？
※4個月寫了4萬行iOS代碼，算多還是少呢？

TAG:Android開發 |