Booster 布局转译器
在上一篇文章中已经介绍过 booster 正在做的 Layout Transpiler —— 将 XML 布局文件翻译成 class 的转译器,在实现的过程中发现了 Android 系统在设计上的各种坑,而且是天坑,几乎是绕不过去了,最近 Android 官方发布了 JetPack Compose 让我眼前一亮,这不就是我想要达到的效果么,只不过是换了一种形式罢了。
在上一篇文章中已经介绍过 booster 正在做的 Layout Transpiler —— 将 XML 布局文件翻译成 class 的转译器,在实现的过程中发现了 Android 系统在设计上的各种坑,而且是天坑,几乎是绕不过去了,最近 Android 官方发布了 JetPack Compose 让我眼前一亮,这不就是我想要达到的效果么,只不过是换了一种形式罢了。
做过开发的同学都深有体会,用 XML 来撸 UI 的效率简直是吊打手写代码,在 Anko (Kotlin 库) 还没有流行之前,大家对 XML 还是亲睐有加,虽然性能上偶尔会有卡顿,但是总体来说,还是勉强能接受,但是 Anko 的流行,也让我们开始思考,有没有办法既能享受 XML 撸 UI 的快感,又能享受像 Anko 一样的性能呢?
许多 Android 开发者可能经常遇到这样的情况:测试的时候好好的,一上线,各种系统的 crash 就报上来了,而且很多是偶现的,比如:
WindowManager$BadTokenException
一般 assets 出现大量重复的情况是不多见的,只有多业务线的大体量 APP 才有可能遇到。然而非常不幸的是,我们就遇到了这样的问题,虽然对包体积的影响不是很明显(也就几百 KB),但是几百 KB 对于做包体积优化的同学来说,蚊子肉也是肉啊。
对于开发者来说,线程管理一直是最头疼的问题之一,尤其是业务复杂的 APP,每个业务模块都有着几十甚至上百个线程,而且,作为业务方,都希望本业务的线程优先级最高,能够在调度的过程中获得更多的 CPU 时间片,然而,过多的竞争意味着过多的资源浪费在了线程调度上。
对于一款 APP 来说,卡顿率、ANR 率是衡量这个 APP 质量的两个重要指标,目前已经有很多成熟的 APM 工具和平台来统计 APP 的运行时性能,但是对于实行敏捷开发的产品来说,从 APP 开发,到灰度发布,再到全量,要经历一个漫长的过程,等到收集到上报的卡顿和 ANR,再去修复,又要经历灰度、全量这一漫长的过程。