有什麼辦法能加快Android Studio中Gradle build速度？

02-19

最近發現每次寫完代碼跑項目到手機上測試，Gradle build差不多要25-30秒不等才能Gradle build finish，再加上安裝到手機5秒鐘左右，基本上每編譯一次代碼都需要等半分多鐘才能在真機上看到效果，等待時間很是痛苦

之前也試過各種方法，修改各種配置的都不好使，至於加內存這種就不說了，大多數開發者並不是很便利的方式，不能從根本上解決問題。

可以試試一些開源的build加速工具，比如 @nekocode 提到的buckbuild，Facebook開源的build 工具，速度確實提升不少，只是侵入性較強，而且配置有點麻煩，不過微信團隊已經在用了。

我司內部使用的是圖大師和@別鬧騰啊一起開發的LayoutCast。比buckbuild還快，具體可以參考項目中的對比圖。對於代碼的修改，一般build速度在2-3秒，之前的項目build一次項目需要2min多，大大提高了編譯速度，節省了不少寶貴的時間，確實很爽，不過對於資源修改支持的不是很好，還在優化。並且LayoutCast是以插件的方式支持，在代碼里簡單的配置即可。

－－－－－－－－－－－－－－－－－－－－－－

官方替代方案 Instant Run

最近google 發布了AS 2.0 alpha版本，其中最讓人興奮的就是Instant Run，它是幹啥的呢，就是加快代碼編譯和部署的速度，也就是要替代上面提到的第三方build工具。看到Instant Run的第一感覺就是Buck，LayoutCast要歇菜了，Google官方開始注意到開發者的痛點，所以推出了Instant Run。你可以嘗試下，但鑒於是alpha版本，所以請不要直接升級，萬一項目緊要關頭出了點問題，夠吃苦頭的，詳細介紹可以看官方文檔，目前Instant Run還存在不少bug，Google工程師在積極修復，相信以後會越來越好，相信在Instant Run穩定之後，第三方加快build速度的工具可以扔掉了：http://android-developers.blogspot.jp/2015/11/android-studio-20-preview.html?linkId=18972844m=1

可以先對比一下社區中常見的幾款加速編譯的方案：

Instant-Run：https://developer.android.com/studio/run/index.html

Pros

Google官方支持的增量編譯方案，隨著Android Studio的迭代持續優化
相對來說更加穩定，零配置，基本無侵入性影響
幾秒內可以完成編譯，速度非常快

Cons

對於可以修改的地方有局限性，具體可以參考官方文檔：https://developer.android.com/studio/run/index.html
除了資源修改之外，修改 Java 文件會重啟整個應用，從 Launcher Activity 重新進入，如果是在開發一個層級較深的 UI 頁面的話，使用起來不方便（當然，也可以手動關掉 Activity 重啟，不過可能帶來編譯後應用沒有更新的問題，具體方法可以參考官方文檔）
增量過的代碼不支持debug
對於複雜的工程結構支持程度不高
不支持Kotlin

Buck/okbuck：GitHub - facebook/buck: A fast build system that encourages the creation of small, reusable modules over a variety of platforms and languages.

Pros

Facebook出品的構建工具，支持多種語言/平台的構建
okbuck是一個幫助gradle工程快速集成buck的工具，目前轉入uber進行維護
多線程並發編譯，充分利用緩存，近似增量編譯
目前支持了retrolambda與註解（？）

Cons

對於有歷史的大型工程接入成本較高，需要較高的時間成本
構建過程與gradle不同，所以第一次接入可能會存在不少的問題需要解決
同理，因為構建過程與 Gradle 不同，社區上一些新的技術可能沒辦法很快應用上
需要重新安裝 APK 消耗時間較久
不支持Kotlin
不支持win平台

JRebel for Android：JRebel for Android

Pros

在Instant Run之前就已經存在的Android平台上的增量編譯解決方案，zeroturnround有大量JVM上熱部署的實踐積累
零配置，只需安裝Android Studio插件，立刻可以運行
相比Instant Run支持的範圍廣，參考這篇文章：JRebel for Android and Instant Run: Hot Swaps, Warm Swaps, Cold Swaps, all the Swaps!
支持lambda與部分流行註解庫
位元組碼層面的動態載入，理論上支持幾乎所有基於JVM語言，包括Kotlin、Groovy等
付費版提供技術支持

Cons

收費，價格較高，可以參考官網介紹：https://zeroturnaround.com/software/jrebel-for-android/buy/
不支持 databinding
只有收費版才能debug，有專門的debug工具
crash後需要重新全量編譯，單次全量編譯、安裝的速度非常慢

Freeline：GitHub - alibaba/freeline: Freeline is a fast build and deployment tool for Android

Pros

支持大多數場景的增量編譯
支持 Retrolambda 與註解
支持 so 動態替換
支持 DataBinding
支持 Windows/Linux/macOS
App crash後，仍然可以通過增量編譯來修復
大多數情況下增量編譯可以在10s內完成

Cons

初次接入可能存在一定的問題，需要稍微花點時間來解決
在簡單的工程上，與其他構建方案相比，沒有明顯的優勢
不支持刪除帶id的資源
不支持Kotlin

LayoutCast 也是一個常用的加速編譯的方案，不過對多 module 的工程支持不足，所以只能算是一個增量編譯的工具原型，通常都需要改造一下才能在複雜工程上應用起來，沒辦法滿足開箱即用的需求，因此就不加入上面的比較了。

下面再說下如何選擇上面方案的問題。

如果團隊里所有人都是清一色 Mac 配置，而且是剛剛起步或者沒有什麼歷史包袱的項目的話，可以考慮一開始就把構建系統遷移到 buck 上，這樣子隨著工程的膨脹，基本上也不會遇見編譯速度太慢的問題。而對於那些本身已經有一定量級的工程還要遷移到buck上的話，需要考慮時間成本的問題，大工程遷移構建系統就算有 okbuck 的幫助，時間上還是會耗費不少的，甚至可能會需要修改 buck 的源碼來適配自己的項目。另外，在使用 buck 的時候，最好能夠對工程模塊進行合理拆分，拆成更多的小單元，也能夠顯著地提高整體的編譯速度。當然 buck 也存在著明顯的問題，問題的根源在於其是一套獨立的，與 Gradle 完全不一樣的構建系統，這意味著很多可以應用在 Gradle 工程上的 plugins，都需要單獨移植到 buck 上，以及使用 buck 打出來的包跟 Gradle 打出來的包，可能是會存在差異的，不能單純地直接使用 buck 打 debug 包，然後使用 Gradle 構建 release 包。

對於個人開發者的小工程，Instant Run 基本上已經夠用了。不差錢的朋友或者使用了 Kotlin 等基於 JVM 的語言，也可以選擇試試看 JRebel for Android （前提是如果你願意付費的話，否則只有一段時間的免費試用期）。

[硬廣植入]

如果上面的情況無法滿足的話，也很歡迎你來體驗一下 Freeline 看看。Freeline 的優點上面已經提到了，基本上可以覆蓋到日常開發的大多數 case。Freeline 基本上做到了每次編譯都只會去處理有改動的文件，不論是 Java 文件還是資源文件，整個流程是真正意義上的增量編譯。同時，社區內也有第三方開發者提供了 Android Studio 的 IDE 插件，可以無縫結合到日常的開發中。使用了 Freeline 之後，除了全量編譯的時候，基本上告別了發燙的筆記本電腦和狂轉的風扇了，再也不會因為各種編譯情況下 Android Studio 卡的無法正常使用了。

Freeline 開源以後，已經有挺多 Android 應用接入了 Freeline 來加速日常開發的編譯過程。當然，Freeline 也並不是一個完美的解決方案。也存在著從入門到放棄的例子，比如經常需要清理緩存才能開發某功能，而 Freeline 在清理完緩存會只能全量編譯，導致最終放棄了 Freeline。Freeline 從原理的本質來說其實是基於 Gradle 構建系統的一套 hack 方案，因此還會存在著一些兼容性問題，這也是目前它還不夠穩定、不是一套完美的解決方案的根本原因。

不過 Freeline 目前還在持續開發與完善中，下一步還會加入對 databinding 和 NDK 的增量編譯部署的支持。接入過程或者使用過程遇見什麼問題的都可以在 Github 上提 issue，我們會儘快幫助大家解決的。

希望 Freeline 能夠給 Android 開發者們帶來不一樣的開發效率與體驗，如果你喜歡我們的項目的話，也歡迎在 Github 上給我們加個 star：Github - alibaba/freeline: Freeline is a fast build and deployment tool for Android

Updata: Freeline v0.8.0 已加入對 DataBinding 的支持

利益相關：Freeline的作者...

Retina MacBook Pro 15"

換2.4以上的版本

使用守護進程有一定的效果。

步驟：在home目錄.gradle文件夾新建grade.properties文件，加上org.grade.daemon=true這一行即可。

PS:題主的項目編譯才二十多秒算啥。。。公司的project用低配的MBP都是要２分鐘的，後來換了台式機也還是要１分鐘，

固態硬碟

加內存.加內存.加內存

加固態.加固態,加固態

上i7,上i7,上i7.

1.盡量把部分邏輯封裝成android-lib.即可以aar依賴.這樣能nice一些.

2.用gradle2.8試試如何.

可以看看Speed up your build in Android Studio這篇帖子.找點感覺.看看卡在哪一步導致編譯慢的.對其進行優化唄.暫時只能這樣了.現在網上講的增大內存.設置某些選項.基本無效了.看不到優化了多少.坐等google完善好這些問題吧.

在任務後面加參數-t，例如build -t

這樣每次文件有改動都會自動執行build任務，雖然build的時間沒變，但是由於一直在後台build，所以當你最後需要運行程序測試的時候，此時真正需要build的地方就只有一點點，所以就會很快

具體做法就是開啟一個命令行然後運行任務加-t參數，然後你就可以看到每次保存的時候都會編譯，退出命令行就結束自動編譯

具體細節請參考 Gradle User Guide Version 4.2.1

開啟守護線程也有一定的效果，不過現在的版本都是默認開啟了

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

對於dex時特別慢的情況，加上這句讓你的編譯速度瞬間飛起來：

android { dexOptions { incremental true javaMaxHeapSize "4g" } }

試試jrebel

同樓上，寫程序一定要配好電腦。

時間比內存條什麼的值錢多了，一定要FQ。

半分鐘也算慢？那像我這種動不動就三分鐘的怎麼辦，擼代碼，建議還是對自己好點，雖然加內存可能有效果，但效果不大，建議入手一台macbook pro，擼代碼的最佳選擇！

好電腦，或者離線gradle

現在gradle，編譯，調試太慢了。