还在用build.gradle吗？试试build.gradle.kts吧

前言

虽然你们都写了不少年的安卓了，我以前一直都有对于build.gradle有点疑惑和不解(这部分其实已经没有了)。就好比为啥android叫android？还有dependencies是啥？apply form和apply plugin有什么区别。

仍是先说下Groovy吧，仍是老生常谈我并不喜欢我Groovy，可是有时候我以为Groovy也仍是很是不错的。

 Groovy是Java虚拟机的敏捷和动态语言，以Java语言的优点为基础，添加了从Python、Ruby和Smalltalk等语言中借鉴的特性。提供流行的编程语言特性，学习成本几乎为零。提供静态类型检查的能力，并静态地编译成java字节码，以得到健壮性和性能，与全部现有的Java类和库无缝集成，能够在任何可使用java的地方使用它。经过其强大的处理原语、OO能力和Ant DSL使编写shell和构建脚本变得容易。在开发Web，GUI，数据库或控制台程序时经过减小框架性的代码大大提升了开发者的效率。支持DSL（Domain Specific Languages领域定义语言）和其它简洁的语法，让代码变得易于阅读和维护。而且支持单元测试，能够简化测试。

build.gradle和咱们的编译息息相关，并且编译相关的对于一个安卓开发其实仍是很是重要，并且也是息息相关的。Groovy的动态化也是有取舍的，下面我略列下我在开发过程当中碰到的问题吧。

1. 由于是一门动态语言并且也没有强类型判断，因此并不会出现编译报错，只会运行到对应代码的时候才出现问题。
2. 没有任何语法提示，不少时候除了系统生成那部分代码，咱们的学习成本和调试成本其实很是高。
3. 只有你足够强足够牛逼的状况下，你能够经过remote的方式调试build.gradle，以后跟踪AGP的源代码，发现有那些能够更改的点。

在写Gradle脚本的时候，最痛苦的莫过于没有任何提示，惟一的调试手段就是使用print方法打印调试日志。若是咱们能使用Kotlin编写Gradle脚本的时候，你会发现一切都变得有趣起来，嘴角开始微微上扬。

Gradle Kotlin DSL 1.0 Gradle官方其实在18年末就已经正式发布了kts的第一个版本了。那么话很少，为何咱们不试试呢。

正文开始

要安利你们学新东西那么就最好先给你们一点甜头，我有糖尿病我先来滋醒你们。

1. 代码提示，kts内全部都是基于kotlin代码规范的，因此强类型语言的好处就是编译没经过的状况下，你根本没法运行。
2. 源代码查看，原来Groovy的block其实在kts都是由拓展函数实现的，因此咱们能直接看到传入的类是什么，以及这个类有哪些参数以及方法。举个例子Android的block块内的参数我就都能看懂了。
3. 混编以及热重载，kts能和gradle能同时编译，这样就可让新的东西往新的架构上迁移，而旧的那部分就能够不动了，这样岂不是美滋滋。

咱们先看一段代码吧

咱们先来对比下两个基本内容相同的配置文件吧。

第一个是我截取的kts相关的，第二个则是我之前的一个项目采用的仍是build.gradle。从第一眼的影像中，咱们能够简单的比对出kts相关的代码提示上真的就会好不少。

举个例子各位大佬之前知道com.android.library中的android所表明的Extension究竟是什么吗？那么和com.android.application下的有什么不一样吗？我想知道他们的源代码在哪里怎么办？

灵魂三问以后我想问下各位有没有啥本身的见解哦，起码我在以前就算使用remote调试插件的时候，我也是靠猜想的方式去定位android所表明的Extension的。因此我在这边想要的出来的结论就是，若是你对安卓的编译感兴趣的状况下，能够先试试从kts开始反向推倒下每一个字段所表明的含义是什么？

从kts中，我发现com.android.application下的android的Extension是BaseAppModuleExtension,咱们全部定义的子属性其实都是在这个实体类上的拓展而已，而com.android.library中的则是另一个实现类LibraryExtension,相对而言他的字段属性就会更少一点，有兴趣的大佬能够自行跟踪翻查源代码。

虽然我在使用kts以前就知道了，由于自定义plugin的时候也会有对这部分的操做和使用。能够参考下逮虾户X，哈哈哈。

这部份内容其实在你编写自定义Plugin的时候仍是有很大几率会使用到的，好比你的插件能够根据applicationId进行不一样的代码生成变化。

这里我小展开下，你们不知道有没有想过implementation内的exclude和禁止依赖传递的transitive究竟是什么？

这里我就给你们买个关子，有兴趣的大佬能够转化下kts，本身跟踪路径，看看其中到底都是些什么东西啊。

可是kts必定就比gradle好吗？我我的见解并非啊，在最新的as中，其实对于gradle的源码跟踪其实就已经很是不错了。还有就是相比较而言，由于groovy是一门动态化语言，因此其中的类型判断也更为简单，并且groovy中的MethodMissing这个机制，能够帮助咱们动态调用不少隐藏的api。

可是偏偏也就是由于这些对应的机制，有时候也会让开发无从入手，由于也不是别的啥，就是菜看不懂呀！！而kts则有一个更有优点的地方就是代码提示了！！！

还有一点就是kts，对于ext的支持简直堪称地狱，若是你有定义在全局的相似dep配置相关的，这部分改动真的可能要了你的老命。

这部分是真的彻底比不上groovy,若是有除了用buildSrc这种方式解决了的大佬，能够告诉我下，让我学习一下啊！！！

那么还有必要学习吗？

我最近的感受就是开发仍是能够多尝试一些新鲜的东西的，特别是这种东西若是不会破坏当前既有结构，并且能完美并存的东西，其实均可以去尝试下。

毕竟如今这个状况吧，你比别人多会一点相对来讲仍是有些好处的。并且我我的见解就是稍微多掌握点这个能帮助各位老哥更好的了解和学习编译流程相关的内容。

另外事先声明，今天这篇文章吧，我以为也就是一篇水文，就是给你们安利下我以为有意思的东西，并无实际太多的干货内容。