Gradle版本
distributionUrl=https\://services.gradle.org/distributions/gradle-5.1.*-all.zip
目標文件名稱
gradle.properties
目標文件內容
# Project-wide Gradle settings. # IDE (e.g. Android Studio) users: # Gradle settings configured through the IDE *will override* # any settings specified in this file. # For more details on how to configure your build environment visit # http://www.gradle.org/docs/current/userguide/build_environment.html # Specifies the JVM arguments used for the daemon process. # The setting is particularly useful for tweaking memory settings. org.gradle.jvmargs=-Xmx2816m # When configured, Gradle will run in incubating parallel mode. # This option should only be used with decoupled projects. More details, visit # http://www.gradle.org/docs/current/userguide/multi_project_builds.html#sec:decoupled_projects # org.gradle.parallel=true android.useAndroidX=true android.enableJetifier=true
IDE--Android Studio版本及運行環境，包括OS操作系統、JVM版本
Android Studio 3.4.x
Build #AI-***.*************, built on May 2, 2019
JRE: 1.8.0_*** ****** **** amd64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Windows 10 10.0
這裏試驗的是目標文件中 “org.gradle.jvmargs=-Xmx2816m”對Android Studio的build編譯效率的影響。也即是gradle對jvm虛擬機內存允許的最大內存限制對Android Studio編譯效率的作用。多餘的話不說，現在就開始實驗吧。接下來，筆者會測試各個內存限制值下，對同一項目編譯（Build）和清理（Clean）完成時長的對比。
假設 G==1GB==1024MB，
1. org.gradle.jvmargs=-Xmx[0.25G]
Clean
Make
2. org.gradle.jvmargs=-Xmx[0.375G]
Clean
Make
3. org.gradle.jvmargs=-Xmx[0.5G]
Clean
Make
4. org.gradle.jvmargs=-Xmx[0.75G]
Clean
Make
5. org.gradle.jvmargs=-Xmx[1G]
Clean
Make
6. org.gradle.jvmargs=-Xmx[1.25G]
Clean
Make
7. org.gradle.jvmargs=-Xmx[1.375G]
Clean
Make
8. org.gradle.jvmargs=-Xmx[1.5G]
Clean
Make
9. org.gradle.jvmargs=-Xmx[1.75G]
Clean
Make
10. org.gradle.jvmargs=-Xmx[2G]
Clean
Make
11. org.gradle.jvmargs=-Xmx[2.25G]
Clean
Make
12. org.gradle.jvmargs=-Xmx[2.5G]
Clean
Make
13. org.gradle.jvmargs=-Xmx[2.75G]
Clean
Make
“超長”的圖文終於傳完。試驗到這裏也告一段落。到目前爲止，JVM最大內存限制爲2.75GB，爲何不一鼓作氣繼續下去？
我們先來看看以下數據：
測試進行到 org.gradle.jvmargs=-Xmx[2.5GB] 完成時：
測試進行到 org.gradle.jvmargs=-Xmx[2.75GB] 完成時：
大概幾分鐘後：
圖示中，OpenJDK開啓了8個內存佔用相近的進程process，Android Studio下亦啓動6個相關進程process。在[2.5GB]時，系統內存負載率達到了82%，[2.75G]時則是87%，幾分鐘後回落至84%！這也意味着，下一項測試完成時，筆者的系統內存負載率極有可能超過90%！如果一味冒進，很有可能宕機。由此可猜測，OpenJDK的JVM的內存回收機制不是即時的，而是緩慢逐步進行的。如果是短時間內進行連續多次編譯，OpenJDK運行JVM虛擬機會保持較高的內存佔用。這樣就容易解釋某種莫名其妙的Build編譯失敗，而降低JVM最大內存限制後編譯再次通過的情況Case：https://blog.csdn.net/qq_21264377/article/details/80588657
最後彙總得出實驗的相關數據：
單位：秒Second / GB 注：Clean=Clean Project Make=Make Project
|
Act/T/JVMArgs |
.25 | .375 | .5 | .75 | 1 | 1.25 | 1.375 | 1.5 | 1.75 | 2 | 2.25 | 2.5 | 2.75 | SUM | AVG |
| Clean | 6.582↑ | 6.647↑ | 5.300↓ | 7.207↑ | 6.254↑ | 5.820↓ | 6.167↓ | 6.206↓ | 5.177↓ | 5.295↓ | 6.060↓ | 7.363↑ | 6.883↑ | 80.961 | 6.22777 |
| Make | 44.295↑ | 25.187↓ | 30.127↓ | 28.226↓ | 41.926↑ | 42.097↑ | 36.806↓ | 42.750↑ | 41.661↑ | 37.232↓ | 43.715↑ | 42.315↑ | 37.618↓ | 493.9550 | 37.9965 |
簡單的從以上表格數據中，可以看出：JVMArgs在0.25~1GB 1.25~1.5 1.75~2.25 2.5~3區間(不包含邊界)Make效率是比較高的，在30.375~0.75 1~2.5區間(不包含邊界)Clean的效率比較高。
假設Best(x)函數表示最優時間，BestTrend(x)函數表示最優趨勢，那麼：
1）Best(Clean)=JVMArgs(1.75)；
2）Best(Make)=JVMArgs(.375)；
3）Best(Clean+Make)=JVMArgs(.375)；
4）BestTrend(Clean+Make)=JVMArgs(.5)。
綜合上述，Clean操作比重較大選擇1），Make操作比重較大選擇2），Clean和Make操作比較均衡則選擇3）；而4）則作爲趨勢參考，因爲上述表格中三組數據均出現時間同步下降的趨勢，而4）是其中最優。
注：以上數據均來自實際實驗，僅作參考。本版本的IDE對較新的硬件設備優化，可能沒有出現在對筆者所使用的硬件設備中。並且，實驗當中，僅以時間爲理想化考量對象，忽略PC各項負載數據的問題，已達到簡化實驗的環境的目的。