升級到 Android studio 3.0版本會使多Module工程的構建速度加快很多。不幸的是，這也帶來了Gradle 插件版本API的較大變化。本文將會詳細指出這個變化帶來的好處，并且指導讀者怎么去升級。
ps: Android plugin 3.0.0搭配Gradle 3.4版本以上
問題現狀
為了理解老版本Gradle plugin 2.0構建系統的限制，這里假設有個工程使用了多層module依賴方式。請看下圖。
對于最底部的基礎module，其將會有兩種可能的變化：
1. Implementation 變化：不會改動本module對外暴露的接口。
2. Application binary interface (ABI) 變化：將會改變本module對外暴露的接口
本module指的是調用dependency的module
注意，所有需要重新編譯的module將會用紅色標出。
Implementation 變化
當本module依賴的ib(也可以是module)發生變化時，由于本module對外暴露的接口并不發生變化，在構建工程時gradle將會只重新編譯本module，所有依賴于本module的module并不會發生編譯。這種情況是沒什么問題的。如圖所示。
ABI變化
當本module依賴的ib(也可以是module)發生變化時，本module向外暴露的接口發生了變化，那么所有直接依賴于本module的module將不得不重新編譯。
接下來，這些上層module可能通過其本身的接口對外暴露了底層module的部分內容，即意味著本module暴露的接口也發生了變化，這會使得依賴于上層module的上上層module也需要重新編譯。這就導致了一個連鎖效應，因此，為了絕對的安全起見，gradle將不得不重新編譯整個工程，使得編譯時間變得較長。如圖所示。
那么重點來了：一點代碼的改動可能會引起整個工程的重新編譯，這將是多么悲催，而實際上我們之前的gradle插件2.0版本系列的確如此，根本原因就是gradle壓根不知道暴露的接口可以通過一個接一個的依賴傳遞影響整個工程。
Android Gradle plugin 3.0帶來了解決方案
最新版的Gradle plugin需要你指出一個module的接口是否對外暴露其依賴lib的接口。基于此，可以讓項目構建時，gradle可以判斷哪個需要重新編譯。因此，老版本的構建關鍵字compile被廢棄了，而是改成了這兩個：
api：同compile作用一樣，即認為本module將會泄露其依賴的module的內容。
implementation：本module不會通過自身的接口向外部暴露其依賴module的內容。
由此，我們可以明確的告訴gradle去重新編譯一個module，若是這個使用的module的接口發生變化的話。
dependencies {
//當legofy接口發生變化時，需要重新編譯本module以及所有使用本module的module
api project(':legofy')
// 僅當landscapevideocamera發生變化時，重新編譯本module
implementation project(':landscapevideocamera:1.0.0')
}
遷移指南
理論上，你可以將原來工程中的compile完全替換為現在的api，但是一旦依賴發生變化，將會使所有的module重新編譯，造成編譯過長。
所以更好的方式就是使用implementation來進行依賴，這會大大改善工程的構建時間。只有你明確要向外部暴露所依賴lib的接口時，才需要使用api依賴，整體來說，會減少很多重新編譯。這一點，在官方指南中說的比較明確。
其它的變化
既然有了比較大的改變，索性官方團隊利用此機會改了更多配置屬性的名字，
比如provided改成了compileOnly，apk改成了runtimeOnly
大體如上，詳情可參考官方遷移指南
