在微信听书最新的版本，累死累活的开发中，我还是把 Jetpack Compose 引入了工程中， 在新的原生界面开发中，用 Compose 来写 UI 了， 贼特么舒服，所以说， QMUI Android 要么重做出一个 Compose 版本，要么就该删库跑路了。
QMUI 一般都是新应用引用得多一点，因为是采用主题配置的方式来使用整个各种组件的，所以很多成熟的应用引用是很困难的，有时候配置都走不通，当前，其实可以用一些注入编译插件的方式来避免这些问题，不过一直以来都是只管挖坑不管埋，坑已经足够多了。 也是时候弃坑挖个新的了。 所以新应用不要引入 QMUI 了， 怪怪的玩 Compose 吧。
在升级 Compose 时，遇到最大的障碍就是 gradle 升级 7.0 带来的问题了， 首先就是 tinker 插件跑不过，其次 AndResGuard 插件跑不过， 官方也没更新到 7.0， 所以就只能是 clone 一份源码，哪里编译不过改哪里，让它最终跑起来了，然后就开开心心的写那些注定会被删除的代码了。不得不说，国内的移动端开发， 虽然好像什么都成熟了，没有新的东西做了，实际上大多数人在业务的细节中走不出来，而剩下的人则是都想着做出点虚无而又伟大的东西，结果最后保持框架和技术与时代同步都做不到， 毕竟这些好像对业务眼前的需求没啥帮助，对职场晋升也没啥帮助。
使用 Compose 是一件很节约时间的事情，毕竟现在产品都喜欢把所有的东西装载在同一个界面，期望用户永远能第一时间看到所有他能看到或者产品期望用户看到的。 这就导致一个界面的状态和布局被搞得鬼复杂，开发天天在那儿加班调 UI。 使用 Compose 后这种状态管理会容易很多， 就可以不用一会儿显示这几个 View， 一会儿显示那几个 View。 管理好 ViewModel， 剩下的就可以一口气按产品逻辑写完整个 UI 了， 这写 React、 Flutter 的人早就体验过这种感觉了， Android 原生也是时候体验了。 iOS 好像要等等， 最近写 Recos， SwiftUI 把我们的 iOS 开发小哥气得弃坑了（原本只是想站在巨人的肩上干点伟大的事情，结果这个巨人的肩不是那么平）。
QMUI 终究是做了这么久了， 也有一些精华可以保留、一些坑点可以避免。 之后开发 Compose 版本时，我觉得需要考虑以下几个点:
1.Theme 主题配置的方式，虽然一劳永逸，但是侵入性比较大，是个糟糕的方式。 而且主题多了，管理起来不舒服
2.除了一些独立的功能模块，app 只使用 scheme 跳转， 是一个非常好的方式，这个可以开发出 Compose 友好的版本，值得 app 架构设计时引入
3.SkinManager 可以保留， 系统只提供了跟随主题的夜间模式切换， 不过国内更多的会提供设置项，而且像阅读器类应用，还不止两个。
4.需要考虑手势返回控件是否需要保留， 毕竟android 高版本由于系统左右的返回手势，我们自定义的类iOS 系统的手势返回并没有太多的触发点了。
5.全 kotlin 化， 包括构建脚本也应该用 kts。
6.QMUI 沉淀了很多浮层、 Dialog、沉浸式的使用技巧， 这些是值得保留的
7.读书和听书沉淀了很多键盘输入（输入 + 表情面板管理）的使用技巧， 这些可以提取出来
8.应该开发一个 Compose 版本的图片管理、选择、浏览库，这应该是个非常好的练手项目，但也没看到有学习 Compose 的同学来写这个
9.Fragment 是否在 Compose 的环境下值得保留？
10.除了一些工具类， QMUI 没有更多的值得保留的东西了， 改入土了。 不想考虑新旧版本的兼容性了，最多把现在的 QMUI 打包成一个 qmui-old 库， 让使用人员可以新旧版本一起用。 要想升级的话，还是心一横，加班加点把整个 App 的 UI 全重写了为好， 卷到底。
挖一个大坑，如果填不好，QMUI Android 就真该凉凉了。
