深入理解gradle框架之一:Plugin,Extension,buildSrc
寫在前面
這篇文章首發在位元組跳動技術團隊公眾號上，可能有的童鞋已經看過了，不過考慮到可能有的童鞋沒關注那個公眾號，所以這裡再發一遍。
另外，最近創建了一個知識星球，名字跟專欄名字一樣，也叫AndroidGeek, 主要是分享gradle框架知識，以及我在愛奇藝和位元組跳動做插件化和熱修復的實踐經驗，大家日常會遇到的編譯問題，以及移動端開發的職業規劃，歡迎感興趣的童鞋加入。日常開發遇到的任何問題，以及職業規劃等，都可以向我提問。
緣起
從2018年下半年開始，因為工作需要，開始深入了解android gradle plugin和gradle框架，在看完android gradle plugin 3.1.x和3.2.x版本的源碼之後，發現目前開源的幾乎所有插件化框架，因為沒有理解android gradle plugin的原理，打包代碼的實現都非常混亂，導致的結果就是很難隨著android gradle plugin的升級而快速升級，所以目前幾乎所有開源的插件化項目都因不適應新的gradle版本問題而不可用。
另一方面，隨著項目的迭代，引入越來越多的gradle plugin, 其中對於Transform的濫用是導致項目編譯速度越來越慢的最重要的一個原因了，然而，實際上，對於Transform的使用是有很大的優化空間的。
加上目前不管是中文還是英文，幾乎所有這方面的文章都停留在基礎使用的階段，真正深入分析原理的幾乎沒有。
所以一直在醞釀寫一個gradle系列的文章，一方面讓大家了解android gradle plugin的原理(儘管各個大版本之間有差別，然而大版本內基本是一脈相承), 另一方面是在介紹原理的過程中，也會加入一些我覺得是Best Practice的Demo. 或許通過這個系列，能夠引導大家都去改進自己實現的Plugin, 最終能夠更快更好地實現自己的編譯時功能。
p.s:因為基礎使用的文章已經有太多了，對於這一塊我基本上就是一筆帶過，不會花太多筆墨。
系列說明
在講解整個系列之前，先看一下gradle的架構是怎樣的，如下圖所示:
- 在最下層的是底層gradle框架，它主要提供一些基礎服務，如task的依賴，有向無環圖的構建等
- 上面的則是google編譯工具團隊的android gradle plugin框架，它主要是在gradle框架的基礎上，創建了很多與android項目打包有關的task及artifacts
- 最上面的則是開發者自定義的Plugin, 一般是在android gradle plugin提供的task的基礎上，插入一些自定義的task, 或者是增加Transform進行編譯時代碼注入
為了簡單起見，我將底層的gradle框架和android gradle plugin框架統稱為gradle框架，整個系列文章其實分析的就是底層gradle框架和android gradle plugin框架的原理，其中側重點在andorid gradle plugin框架，因為這與我們日常編譯息息相關，也是收益最大的部分。
這是深入理解Gradle框架系列的第一篇。整個系列共分為9篇，文章列表如下:
- 第1篇是入門文章，主要講解Gradle Plugin以及Extension的多種用法，以及buildSrc及gradle插件調試的方法。
- 第2篇是從dependencies出發，闡述DependencyHandler的原理
- 第3篇則是關於gradle configuration的預備知識介紹，以及artifacts的發布流程
- 第4篇則是artifacts的獲取流程
- 第5篇是從TaskManager出發，分析如ApplicationTaskManager, LibraryTaskManager中各主要的Task，最後給出當前版本的編譯流程圖
- 第6篇比較3.2.1相比3.1.2中架構的變化
- 第7篇關於Gradle Transform
- 第8篇從打包的角度講解app bundles的原理
- 第9篇分析資源編譯的流程，特別是aapt2的編譯流程
Plugin
語言選擇
其實只要是JVM語言，都可以用來寫插件, 比如Android Gradle Plugin團隊，在3.2.0之前一直是用java編寫gradle插件。
國內很多開源項目都是用groovy編寫的，groovy的優勢是書寫方便，而且其閉包寫法非常靈活，然而groovy的缺點也非常明顯，最大的一點不好就是IDE對其的支持非常不好，不僅僅是語法高亮沒做好，還有導航跳轉都極為有限，比如build.gradle中的方法跳轉不到其定義處。
當然，我自己長期使用groovy下來，也發現了它的一些缺點，比如each這個閉包，在運行時竟然會出現找不到其成員的情況。
以及出現開發者自定義的成員與其默認成員(groovy中會為每個類增加一些默認成員)名稱重合時，不能給出有效的提示，當然，這個問題我不確定是IDE的問題還是groovy自身的編譯器實現不夠完善的問題。
其實到目前為止，使用kotlin進行插件開發是最好的選擇，有如下兩個原因:
- kotlin的語法糖完全不輸於groovy, 可以有效提高開發效率
- kotlin是jetbrain自家的，IDE對其的支持更完善
可能正是這個原因，Google編譯工具組從3.2.0開始，新增的插件全部都是用kotlin編寫的。
插件名與Plugin的關係
比如我們常用的apply plugin: com.android.application, 其實是對應的AppPlugin， 其聲明在源碼的META-INF中，如下圖所示:
可以看到，不僅僅有com.android.appliation, 還有我們經常用到的com.android.library,以及com.android.feature, com.android.dynamic-feature.
以com.android.application.properties為例，其內容如下:
implementation-class=com.android.build.gradle.AppPlugin
其含義很清楚了，就表示com.android.application對應的插件實現類是com.android.build.gradle.AppPlugin這個類。
其他的類似，就不一一列舉了。
定義插件的方法
要定義一個gradle plugin，則要實現Plugin介面，該介面如下:
public interface Plugin<T>{
void apply(T var)
}
以我們經常用的AppPlugin和LibraryPlugin, 其繼承關係如下:
注意，這是3.2.0之前的繼承關係，在3.2.0之後，略微有些調整。
可以看到，LibraryPlugin和AppPlugin都繼承自BasePlugin， 而BasePlugin實現了Plugin介面，如下:
public abstract class BasePlugin<E extends BaseExtension2>
implements Plugin<Project>, ToolingRegistryProvider {
@VisibleForTesting
public static final GradleVersion GRADLE_MIN_VERSION =
GradleVersion.parse(SdkConstants.GRADLE_MINIMUM_VERSION);
private BaseExtension extension;
private VariantManager variantManager;
...
}
這裡繼承的層級多一層的原因是，有很多共同的邏輯可以抽出來放到BasePlugin中，然而大多數時候，我們可能沒有這麼複雜的關係，所以直接實現Plugin這個介面即可。
Extension
Extension其實可以理解成java中的java bean, 它的作用也是類似的，即獲取輸入數據，然後在插件中使用。
最簡單的Extension為例, 比如我定義一個名為Student的Extension,其定義如下:
class Student{
String name
int age
boolean isMale
}
然後在Plugin的apply()方法中，添加這個Extension, 不然編譯時會出現找不到的情形:
project.extensions.create("student",Student.class)
這樣，我們就可以在build.gradle中使用名為student的Extension了，如下:
student{
name Mike
age 18
isMale true
}
注意，這個名稱要與創建Extension時的名稱一致。
而獲取它的方式也很簡單:
Student studen = project.extensions.getByType(Student.class)
嵌套的Extension類似，不再贅述。
如果Extension中要包含固定數量的配置項，那很簡單, 類似下面這樣就可以:
class Fruit{
int count
Fruit(Project project){
project.extensions.create("apple",Apple,"apple")
project.extension.create("banana",Banana,"banana")
}
}
其配置如下:
fruit{
count 3
apple{
name Big Apple
weight 580f
}
banana{
name Yellow Banana
size 19f
}
}
下面要說的是包含不定數量的配置項的Extension, 就需要用到NamedDomainObjectContainer, 比如我們常用的編譯配置中的productFlavors，就是一個典型的包含不定數量的配置項的Extension. 但是，如果我們不進行特殊處理，而是直接使用NamedDomainObjectContainer的話，就會發現這個配置項都要用=賦值，類似下面這樣。
接著使用Student, 如果我需要在某個配置項中添加不定項個Student輸入，其添加方式如下:
NamedDomainObjectContainer<Student>studentContainer = project.container(Student)
project.extensions.add(team,studentContainer)
然而，此時其配置只能如下:
team{
John{
age=18
isMale=true
}
Daisy{
age=17
isMale=false
}
}
注意，這裡不需要name了，因為John和Daisy就是name了。
可是，這不科學呀，groovy的語法不是可以省略么？就比如productFlavors這樣:
要達到這樣的效果其實並不難，只要做好以下兩點:
- item Extension的定義中必須有name這個屬性，因為在Factory中會在創建時為這個名稱的屬性賦值。定義如下:
```groovy class Cat{ String name
String from
float weight
} ```
- 需要定義一個實現了NamedDomainObjectFactory介面的類，這個類的構造方法中必須有instantiator這個參數，如下:
```groovy class CatExtFactory implements NamedDomainObjectFactory{ private Instantiator instantiator
CatExtFactory(Instantiator instantiator){
this.instantiator=instantiator
}
@Override
Cat create(String name){
return instantiator.newInstance(Cat.class, name)
}
} ```
此時，gradle配置文件中就可以類似這樣寫了:
animal{
count 58
dog{
from America
isMale false
}
catConfig{
chinaCat{
from China
weight 2900.8f
}
birman{
from Burma
weight 5600.51f
}
shangHaiCat{
from Shanghai
weight 3900.56f
}
beijingCat{
from Beijing
weight 4500.09f
}
}
}
Plugin Transform
Transform是android gradle plugin團隊提供給開發者使用的一個抽象類，它的作用是提供介面讓開發者可以在源文件編譯成為class文件之後，dex之前進行位元組碼層面的修改。
藉助javaassist, ASM這樣的位元組碼處理工具，可在自定義的Transform中進行代碼的插入，修改，替換，甚至是新建類與方法。
像美團點評的Robust，以及我開源的Andromeda項目中，都有在Transform中插入代碼的示例。
如下是一個自定義Transform實現:
public class AllenCompTransform extends Transform {
private Project project;
private IComponentProvider provider
public AllenCompTransform(Project project,IComponentProvider componentProvider) {
this.project = project;
this.provider=componentProvider
}
@Override
public String getName() {
return "AllenCompTransform";
}
@Override
public Set<QualifiedContent.ContentType> getInputTypes() {
return TransformManager.CONTENT_CLASS;
}
@Override
public Set<? super QualifiedContent.Scope> getScopes() {
return TransformManager.SCOPE_FULL_PROJECT;
}
@Override
public boolean isIncremental() {
return false;
}
@Override
public void transform(TransformInvocation transformInvocation) throws TransformException, InterruptedException, IOException {
long startTime = System.currentTimeMillis();
transformInvocation.getOutputProvider().deleteAll();
File jarFile = transformInvocation.getOutputProvider().getContentLocation("main", getOutputTypes(), getScopes(), Format.JAR);
if (!jarFile.getParentFile().exists()) {
jarFile.getParentFile().mkdirs()
}
if (jarFile.exists()) {
jarFile.delete();
}
ClassPool classPool = new ClassPool()
project.android.bootClasspath.each{
classPool.appendClassPath((String)it.absolutePath)
}
def box=ConvertUtils.toCtClasses(transformInvocation.getInputs(),classPool)
CodeWeaver codeWeaver=new AsmWeaver(provider.getAllActivities(),provider.getAllServices(),provider.getAllReceivers())
codeWeaver.insertCode(box,jarFile)
System.out.println("AllenCompTransform cost "+(System.currentTimeMillis()-startTime)+" ms")
}
}
gradle插件的發布
絕大多數gradle插件，我們可能都是只要在公司內部使用，那麼只要使用公司內部的maven倉庫即可，即配置並運用maven插件，然後執行其upload task即可。這個很簡單，不再贅述。
特殊的buildSrc
前面說過gradle插件的發布，那如果我們在插件的代碼編寫階段，總不能修改一點點代碼，就發布一個版本，然後重新運用吧？
有人可能會說，那就不發布到maven倉庫，而是發布到本地倉庫唄，然而這樣至多發布時節省一點點時間，仍然太麻煩。
幸好有buildSrc!
在buildSrc中定義的插件，可以直接在其他module中運用，而且是類似這種運用方式:
apply plugin: wang.imallen.blog.comp.MainPlugin
即直接apply具體的類，而不是其發布名稱，這樣的話，不管做什麼修改，都能馬上體現，而不需要等到重新發布版本。
gradle插件的調試
以調試:app:assembleRelease這個task為例，其實很簡單，分如下兩步即可:
- 新建remote target
- 在命令行輸入./gradlew --no-daemon -Dorg.gradle.debug=true :app:assembleRelease
- 之後選擇剛剛創建的remote target, 然後點擊調試按鈕即可
推薦閱讀：
