Kotlin 填坑记之 Metadata
最近用 KAPT 来生成 Kotlin 代码,遇到了一个头疼的问题,生成的 Kotlin 代码需要调用源 Kotlin 代码中被 Annotation
标注的属性,理论上讲,直接用 .
操作符来调用属性不就行了吗?然而,事情并没有想象的那么简单。
最近用 KAPT 来生成 Kotlin 代码,遇到了一个头疼的问题,生成的 Kotlin 代码需要调用源 Kotlin 代码中被 Annotation
标注的属性,理论上讲,直接用 .
操作符来调用属性不就行了吗?然而,事情并没有想象的那么简单。
是个 Java/Android 工程师都知道,用 ==
比较其实是比较的两个对象是否是同一个实例,比较实例其实就是比较内存地址是否相等,当我们在打印一个 Object
的时候,默认就会输出 [email protected]
这样的字符串,@
后面的这一串,则是 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
?…”,由于开着车,实在没功夫回信息,过了一会儿,又收到一条微信:“森哥,字节码大神,说下原理呗?[捂脸表情]”
正静坐思考人生,突然意识到加入 Coupang 已经一年了,从头到尾捋了一遍,脑海里冒出来一个词 —— 度日如年,此「度日如年」并非彼「度日如年」,一切都是相对的,这儿正好相反。在 Coupang 这短短的一年的收获已远远超过之前几年,也不知道是因为运气好,还是自己的决策对,用我老板的话说 —— 你们想要知道下次是哪家公司上市,就看 Johnson 去哪儿 😁 恐怕我也是为数不多的连续经历三次 IPO 的人之一,不过回想当初的决定,还真是无比的坚难。
Booster 又双叒叕发布了新的版本—— v3.5.0,本次更新内容如下:
ServiceLoader
性能优化,使用方法: 1 | val services = ServiceLoader.load(Service::class.java).iterator() // iterator() 是必要的 |
Booster 又双叒叕发布了新的版本—— v3.4.0,本次更新内容如下:
ClassParser
,开发者可以选择使用 ASM 或者 Javassist 或者其它的 class 文件解析器