自从字节码操作技术在移动端普及之后，各种 app 的架构中都采用了这一技术，最典型的例子便是采用 Service Locator 模式实现的 IoC 框架，这类框架都有着相同的实现思路，挫一点的则是通过反射来实例化对象，好一点的会用 apt 来生成 Factory 代码来解决实例化的问题，但都会存在一个问题，就是需要一个静态的映射（注册表）来解决根据接口查找实现的问题，而这个静态的映射（注册表）一般都是通过字节码操作技术在编译期间自动生成。

Booster 又双叒叕发布了新的版本—— v4.1.0，本次更新内容如下：

• Fix issue #258

很早就想写一篇关于两种不同的做事哲学的文章，一直有些纠结标题是「两个世界，两种哲学」还是「两种哲学，两个世界」，前者在于从结果的角度出发，后者则是从原因的角度出发，以佛教的观点一看，因即是果，果即是因，其实都是一样，但其实我们从解决问题的角度来说，一般还是由果及因，找到了根本原因，才能真正的解决问题。

最近用 KAPT 来生成 Kotlin 代码，遇到了一个头疼的问题，生成的 Kotlin 代码需要调用源 Kotlin 代码中被 Annotation 标注的属性，理论上讲，直接用 . 操作符来调用属性不就行了吗？然而，事情并没有想象的那么简单。

是个 Java/Android 工程师都知道，用 == 比较其实是比较的两个对象是否是同一个实例，比较实例其实就是比较内存地址是否相等，当我们在打印一个 Object 的时候，默认就会输出 java.lang.Object@xxxxxx 这样的字符串，@ 后面的这一串，则是 Object 实例在内存中的地址。众所周知，由于 JVM 的垃圾回收机制，会导致实例在运行时内存中的位置被垃圾回收器移动，那么问题来了，当实例被移动位置后，Object 的 hashCode() 会变吗？

发布过开源库的同学肯定深有感触，想要将一个开源库发布到 Maven Central 对于开发者来说并不简单，尤其是通过 Sonatype 来发布，需要满足一系列的条件，而且对于 Gradle 工程来说，尽管都是用 maven-publish 插件来进行发布，但不同的类型的工程，其发布所需的配置还有些不太一样，比如：Gradle Plugin__，__Androdi Library 和 __Java Library__，尤其是多模块的 Gradle 工程，要为每个模块写一堆看起来相似又不完全相同的 DSL 很是麻烦，而且 Gradle 的 DSL 对于新手来说，简直是一脸懵逼。