做了 7 年 Android，实在有点受不了那些别扭 API，于是自己重整了一套开发体验

综合讨论

做了 7 年 Android，实在有点受不了那些别扭 API，于是自己重整了一套开发体验

UNX小Lab · 2026-05-30T06:51:43.270Z

大家好啊。我是个做了 7 年多 Android 原生开发的人，平时会翻 Android Framework 源码，也懂一点逆向 Hook 和 AOP 插桩，比如之前写过 YukiHookAPI（ https://github.com/HighCapable/YukiHookAPI），偶尔也会写点后端（PHP / SpringBoot）折腾下全栈。我一直有个习惯：在实际业务里踩了坑，就想办法通过开源工具库把能力沉淀下来，算是“开源反哺业务”。写 Android 久了，人很容易进入一种奇怪状态：有些需求不是不会写，而是每次碰到那些特别眼熟、又长又臭的 API，往往会在敲键盘前忍不住叹一口气：“怎么又是你？” 我算是重度强迫症患者，对 Android 的很多不满，其实不是因为“它做不到”，而是“它明明能做到，但代码写起来怎么就这么别扭？” 比如一大坨 Builder，比如不知道怎么就被吞掉的 padding，比如永远记不清参数顺序的 dp2px。于是，就有了 BetterAndroid。它不是想颠覆什么架构的新框架，也不是单纯塞一堆没灵魂的 xxxUtils。更像是我对自己这 7 年编码体验的一次“重构”。初衷很简单：在不破坏原生能力、不强行改变项目架构的前提下，把那些重复、繁琐、兼容性像盲盒一样的部分，整理成更顺手的现代 Kotlin 写法。这里面很多功能，都是我在实际业务里被反复折腾之后抠出来的痛点。 1. 系统栏：Android 适配里很容易踩坑的无底洞如果只看文档，状态栏、导航栏好像无非就是调个颜色、设几个 flag。但只要真正在项目里处理过沉浸式、Edge-to-Edge，或者深浅色内容切换，就知道这东西有多烦。不同系统版本表现不一样，不同厂商系统还会有自己的实现。在 BetterAndroid 里，我做了一个 SystemBarsController。它不是简单帮你改个颜色，而是把整个系统栏当成一个独立的“界面控制对象”。很多人遇到的坑是，一开启 Edge-to-Edge，内容就被刘海、水滴或者底部短条挡住了。BetterAndroid 默认会用 safeDrawingIgnoringIme 给根布局垫一层安全 padding；如果你想完全自己控制，也可以直接置空 edgeToEdgeInsets。总之，我不只是想提供方法，更想把布局关系提前处理好。 2. Insets：把 Compose 那种顺手感带回原生 View Insets 是个好东西，但原生写法真的不太好看： WindowInsetsCompat.getInsets(WindowInsetsCompat.Type.systemBars()) 页面稍微复杂一点，这就会变成一坨又长又绕的代码。这里我借鉴了 Jetpack Compose 的思路，把 Insets 独立成 ui-extension 的核心能力。现在可以直接拿： insetsWrapper.systemBars insetsWrapper.ime 甚至还支持 +、-、or、and 运算。应用到 View 上也不用手写一堆 setPadding，直接： view.setInsetsPadding(systemBars) view.updateInsetsPadding(insetsWrapper.ime, bottom = true) 而且一个小细节是：它会保存原本的 padding 作为基线。这样 Insets 刷新时，就不怕把 XML 里辛辛苦苦写好的内边距吃掉了。 3. 发个系统通知，为什么要写得像造火箭高低版本兼容、通知渠道、Android 13 的运行时权限……写到最后，业务代码里混着一大段 Builder，看着就心烦。我对通知做了一整套封装，希望发通知的代码看起来是在描述“我要发一条通知”，而不是在拼一艘飞船： context.createNotification( channel = NotificationChannel("my_channel_id") { name = "My Channel" } ) { smallIconResId = R.drawable.ic_my_notification contentTitle = "My Notification" contentText = "Hello World!" }.post() 第一次 post 自动创建渠道，遇到同 ID 自动复用，权限优先级也变成更友好的枚举，能少掉不少心智负担。 4. 都这个年代了，我真的不想再写 dp2px 了相信我，每个接手过老项目的人，基本都能搜出 3 个以上的 DensityUtils。在 XML 里写 10dp 很自然，一到代码里就要手动转换。 BetterAndroid 给 Kotlin 提供了一套更直觉的扩展： val px = 10.toPx(context) val dp = 36.toDp(context) 如果你在 Fragment / Activity 或者有 Context 的类里，只要实现 DisplayDensity 接口，还可以把这类转换写得更短一点。总体来说，这个库不是为了制造一套新规则，而是想把 Android 开发里那些常见但烦人的细节，尽量变成更顺手、少出错、也更符合直觉的写法。

UNX小LabLv.1

12小时前