Booster 4.2.0 版本发布
Booster 又双叒叕发布了新的版本—— v4.2.0，本次更新内容如下：
- 增加对运行时字节码注入的支持，开发者可以使用 Booster 提供的
TransformerClassLoader实用类在运行时自动发现Transformer并进行字节码注入，使Transformer能够完全复用
Booster 又双叒叕发布了新的版本—— v4.2.0，本次更新内容如下：
TransformerClassLoader 实用类在运行时自动发现 Transformer 并进行字节码注入，使 Transformer 能够完全复用自从字节码操作技术在移动端普及之后，各种 app 的架构中都采用了这一技术，最典型的例子便是采用 Service Locator 模式实现的 IoC 框架，这类框架都有着相同的实现思路，挫一点的则是通过反射来实例化对象，好一点的会用 apt 来生成 Factory 代码来解决实例化的问题，但都会存在一个问题，就是需要一个静态的映射（注册表）来解决根据接口查找实现的问题，而这个静态的映射（注册表）一般都是通过字节码操作技术在编译期间自动生成。
很早就想写一篇关于两种不同的做事哲学的文章，一直有些纠结标题是「两个世界，两种哲学」还是「两种哲学，两个世界」，前者在于从结果的角度出发，后者则是从原因的角度出发，以佛教的观点一看，因即是果，果即是因，其实都是一样，但其实我们从解决问题的角度来说，一般还是由果及因，找到了根本原因，才能真正的解决问题。
最近用 KAPT 来生成 Kotlin 代码，遇到了一个头疼的问题，生成的 Kotlin 代码需要调用源 Kotlin 代码中被 Annotation 标注的属性，理论上讲，直接用 . 操作符来调用属性不就行了吗？然而，事情并没有想象的那么简单。
是个 Java/Android 工程师都知道，用 == 比较其实是比较的两个对象是否是同一个实例，比较实例其实就是比较内存地址是否相等，当我们在打印一个 Object 的时候，默认就会输出 java.lang.Object@xxxxxx 这样的字符串，@ 后面的这一串，则是 Object 实例在内存中的地址。众所周知，由于 JVM 的垃圾回收机制，会导致实例在运行时内存中的位置被垃圾回收器移动，那么问题来了，当实例被移动位置后，Object 的 hashCode() 会变吗？
当开发一个 Android Library 时，如果还同时还要提供相应的 __Gradle Plugin__，对于 Gradle 新手来说，要在一个 Gradle 工程中同时集成 Android Library__，__Gradle Plugin 和 Example App 三个模块，并不是一件很容易的事，主要的问题在于 Android App 模块中无法引用同一个工程中的 Gradle Plugin 模块，这是因为 Gradle Plugin 需要先于所有的工程进行配置和编译，所以，很多工程师都会将 Gradle Plugin 作为一个独立的工程进行开发和发布，这对于频繁地开发和调试 Gradle Plugin 的工程师来说，是非常的痛苦，每次修改了 Gradle Plugin 都要先发布到 __Maven Local__，然后再跨工程进行调试，效率极低，那有什么优雅的解决方案呢？
在移动互联网蓬勃发展的时代，出现了很多现代化的编程语言，Write Once and Run Anywhere 早已不再是 Java 所独有的特性，然而在 Android 系统推出之前，想要在嵌入式 Linux 系统之上比较方便的开发 GUI 程序还真不是一件简单的事情，虽然有 Qt、GTK 等强大的 GUI 开发框架，但是用 C/C++ 语言开发始终不可避免的要面临的一个问题——内存管理，尽管 C++ 有强大的 boost 库（已在 2011 年成为 C++11 的标准库）提供的智能指针能很好的解决内存的问题，但对于采用 C 语言来开发 GUI 的 GTK 来说，就不是那么容易了，尤其是对于要用 C 语言来开发应用程序的开发者来说，如何让内存管理变得更容易便成为了一个经久不衰的话题。
正在开车呢，收到一条微信：“森哥，这段代码为啥输出是 0？…”，由于开着车，实在没功夫回信息，过了一会儿，又收到一条微信：“森哥，字节码大神，说下原理呗？[捂脸表情]”