工匠若水

工匠若水可能会迟到，但是从来不会缺席，最终还是觉得将自己的云笔记分享出来吧 ～背景前面《Groovy 本质初探及闭包特性原理总结》文章中我们总结了 Groovy 的本质，可以发现 Groovy 不但增强了 java 的脚本能力，也提供了新的面向对象特性；就像前面看到的，Groovy 对 java 非对象基础类型直接变成了引用类型，引入了闭包，并为对象集合增加了许多简化符号和拓展能力；前面文章也说了，这些特性可以看作是 java 的一种语法糖，但如果 Groovy 的对象仅仅提供 java 的语法糖能力，

工匠若水可能会迟到，但是从来不会缺席，最终还是觉得将自己的云笔记分享出来吧 ～Groovy 语言的本质Groovy 是基于 JVM 的一种语言，也是 Java 的一种升级拓展语言。其具备脚本语言的特性，但又不算脚本，所以其运行有如下两种方式：基于源码直接运行，譬如 groovy Test.groovy。基于预编译模式运行，譬如先 groovyc Test.groovy 然后 java Test。无论上面的哪种运行方式，其本质都是 JVM 字节码，可以理解成和 java 编译运行没啥区别，只是

背景上一篇文章《记录一次 AGP 调研过程中的思考，我从一个事故搞出了一个故事！》发布后有很多小伙伴表示看不懂，本来不想写这篇的，但是恰巧最近大组有同事在做另一个技术需求时他的 R 也炸了，只是他炸的是 javac 阶段，我上篇分析的场景是 ASM 生成字节码阶段，所以我让他将他的R.java文件发我，我尝试编译并与我的字节码做对比发现了一点我以前没意识到的点，所以自己觉得上篇博文还是不够深入，AGP 升级的 R 问题还能继续挖坟考古，所以想来个续集。鉴于有人上篇没看懂，这篇就循序渐进的图文并茂下。所以接

工匠若水可能会迟到，但是从来不会缺席，最终还是觉得将自己的云笔记分享出来吧 ～背景代码各种维度的统计在有些时候是很重要的，这里总结一些常用的牛逼的代码统计工具，着重介绍了个人使用的 Statistic 插件。但是如果你是想统计团队维度的数据，推荐后面介绍的 git_stats 神器工具。Statistic IDEA 插件IDEA 的 Statistic 插件官方地址为 https://plugins.jetbrains.com/plugin/4509-statistic ，大家可以直接通过 IDEA

工匠若水可能会迟到，但是从来不会缺席，最终还是觉得将自己的云笔记分享出来吧 ～背景好的 commit message 是至关重要的，如果随意编写 log，带来的后果可小可大，但是无论大小都影响了开发的效率和回朔的难度，所以有必要进行 log 规范化检查。而检查的入口可以从 git hook 切入，而 git hook 却又有无限的遐想。关于 git commit 问题可以参考下面几个帖子：Augular git commit 提交规范如何写好 Git commit log?跑远了，我们下面先介绍

工匠若水可能会迟到，但是从来不会缺席，最终还是觉得将自己的云笔记分享出来吧 ～背景大家都知道静态代码检查工具有很多，譬如阿里的 p3c、sonar 挂钩的一堆插件等。但是这些东西对于一个已存在的项目不够友好，因为旧代码一扫描会出现一堆问题，修复带来的成本又很高，所以这些工具都比较适合新项目或者初期介入，对于老项目就显得很蛋疼了。因此有必要做到增量检查；一种就是针对版本控制的 changed 进行增量，这种情况会涉及到老文件修改一处全部问责的问题；另一种是针对新增文件进行增量，这种情况保证了从此刻开始新

工匠若水可能会迟到，但是从来不会缺席，最终还是觉得将自己的云笔记分享出来吧 ～背景好的 commit message 是至关重要的，如果随意编写 log，带来的后果可小可大，但是无论大小都影响了开发的效率和回朔的难度，所以有必要进行 log 规范化检查。而检查的入口可以从 git hook 切入，而 git hook 却又有无限的遐想。关于 git commit 问题可以参考下面几个帖子：Augular git commit 提交规范如何写好 Git commit log?跑远了，我们下面先介绍

工匠若水可能会迟到，但是从来不会缺席，最终还是觉得将自己的云笔记分享出来吧 ～缘由相信大家都用过 javadoc 命令或者 IDE 封装命令生成 java api doc 文档吧，但是你有没有反思过 javadoc 命令是怎么解析文件生成的呢？其实 javadoc 在 jdk 目录下只是一个可执行程序，但是这个可执行程序是基于 jdk 的 tools.jar 的一个封装，也就是说 javadoc 实现在 tools.jar 中。很多时候我们可能会有一些奇葩的需求，譬如获取 java 文档注释进行搞事情

工匠若水可能会迟到，但是从来不会缺席，最终还是觉得将自己的云笔记分享出来吧 ～背景项目规模航母级庞大，年代久远，导致很多模块迟迟没有完全 gradle 化，所以浪费了一定的开发效率。由于构建采用了类似 c 语言的宏定义概念控制，加上自定义的拆 dex 构建，对部分大型模块不熟悉，所以整个构建无比复杂，从而对完全 gradle 化带来了一些坑。本文仅以总结记录自己的落地经验，以便后续回忆分析。落地过程中的坑与解决方案整体迁移的思路是先依据各种 ant 构建自定义的 build.xml 翻译成对应规则的

正则表达式使用单个字符串来描述、匹配一系列符合某个句法规则的字符串。在很多文本编辑器里，正则表达式通常被用来检索、替换那些符合某个模式的文本。由于正则表达式主要应用对象是文本，因此它在各种文本编辑器场合都有应用，小到著名编辑器EditPlus，大到Microsoft Word、Visual Studio等大型编辑器，都可以使用正则表达式来处理文本内容。

【工匠若水 http://blog.youkuaiyun.com/yanbober 转载请注明出处。点我开始Android技术交流】1 背景Groovy脚本基于Java且拓展了Java，所以从某种程度来说掌握Java是学习Groovy的前提，故本文适用于不熟悉Groovy却想快速得到Groovy核心基础干货的Java开发者（注意是Java），因为我的目的不是深入学习Groovy语言，所以本文基本都是靠代码来解释

【工匠若水 http://blog.youkuaiyun.com/yanbober 转载请注明出处。点我开始Android技术交流】1 背景在开始Gradle之前请务必保证自己已经初步了解了Groovy脚本，特别是闭包规则，如果还不了解Groovy则可以先看《Groovy脚本基础全攻略》这一篇博客速成一下Groovy基础，然后再看此文即可。关于Gradle速成干货基础详情也请参考Geadle官方网站，不好意思我

上一篇《Gradle 庖丁解牛（构建源头源码浅析）》我们分析了 Gradle 框架自身初始化（非构建生命周期初始化）的核心流程，这一篇我们续着前面的分析继续（如果没看过前一篇的建议先去看前一篇，因为这一系列存在非常高的关联性）。

总是有人问 Gradle 构建，总是发现很多人用 Gradle 是迷糊状态的，于是最近准备来一个“Gradle 庖丁解牛”系列，一方面作为自己的总结，一方面希望真的能达到标题所示效果，同时希望通过该系列达到珍惜彼此时间的目的，因为目前市面上关于 Gradle 的教程都是在教怎么配置和怎么编写插件，很少有说明 Gradle 自己到底是个啥玩意的，还有是如何工作的，本系列以官方 release 3.4 版本为基础。

未经微博私信询问征得同意的情况下本博客所有原创类型文章一律禁止任何复制、转载、商用，对于复制段落的也请麻烦标明引用。为保证博客质量，任何事情都是花时间去做的，本着分享但不开放的态度总结自己的知识点，烦请尊重劳动成果。