各位 Android 大佬， 2024 年了 Jetpack Compose 现在用的多了吗，有没有什么硬伤？

[monkeylmj]

比如，由于生态问题很难实现某些需求、性能方面体验很差等等。

有没有老哥现在完全切到 compose 开发了，谈谈是什么感觉，有没有从 java 切到 kotlin 的痛快感。

[maokg]

frameworker ，无聊的时候看 https://jetpackcompose.cn/ ，写了一下还是很爽的，但我的 UI 场景不多，自定义 view 都很少写...无法给出具体的槽点

[RightHand]

能用，但， 同时中不能有是能跑就行。藏了太多东西，学习成本有点高。

[location123]

使用 Compose 写过桌面端的小工具 还是很爽的 kotlin 一把梭

[ruzhan123]

画 UI flutter 就挺好的

[monkeylmj]

最好是在生产项目中的使用经验~

[LLLeo]

@monkeylmj 目前有在用，目前遇到最大问题就是数据量大的列表效果不是很好，ViewPager 控件切换体验不好，其他都不错，写 UI 很爽很快。
新项目没有夸端的需要建议使用

[Tlaster]

从 alpha 就开始用到现在了，写了不少纯 Compose 应用，最近的例子： https://github.com/DimensionDev/Flare
新应用可以直接纯 Compose
槽点就是：写 Compose 是完全不同的思维范式，如果之前写 View 的话，很容易用 View 的思维去写 Compose ，然后踩到 Compose 的坑，有一些会导致性能问题，最后怪 Compose 性能差，但实际上 Compose 的性能现在（ 1.7 ）已经完全不差了。
不过 Compose 一定需要开 R8 （ isMinifyEnabled = true ），不开的话性能确实不行

[StinkyTofus]

@location123 #3 资源占用怎么样？ 比 javafx 高吗？

[monkeylmj]

@Tlaster 大佬厉害，学习学习。isMinifyEnabled = true 不就是开代码混淆压缩吗，为啥还会影响到性能。还有楼上说的数量大的时候列表效果不好，大佬遇到过吗？

[winterbells]

本来兴致勃勃把公司 app 往这上面转，UI 都重构了几个页面了。现在 app 半死不活的也没空管它了

踩过但是填了的两个大坑，resource 和 navigation ，这两个最近都加上了（ compose-multiplatform ）。

抽屉（ drawer ）之前有过不同平台样式不一样，只有安卓上点开后阴影正常（可能早期版本，现在修好了吧

还有编译问题、api 乱改（现在不知道改不改了）

lazylist 的性能也不知道怎么样了，自己写着完还可以，我也好奇有没有哪家公司用这个

[Tlaster]

@monkeylmj isMinifyEnabled = true 会开启 R8 代码优化（ https://developer.android.com/build/shrink-code ），因为 Compose 也是用 Kotlin 写的，所以也会享受到 R8 代码优化带来的好处。
数量大的列表性能问题以前踩过坑，现在基本上没有了，有几个原因：1. 列表项目的 Composable 带了太多状态，最好列表项目是不带状态的。2. Composable 里面有耗时操作。举个例子的话，HTML 解析不要在 Compose 里面做，要在 Model 里面就处理掉，Compose 只做富文本渲染。
说白了就是不要在 Compose UI 里面做业务逻辑，这些应该是上层（比如 ViewModel ）的职责，Compose UI 就只要做渲染就行。

[location123]

@StinkyTofus 没用 javafx 写过 我是 mac 系统 做日志分析用的 程序刚启动占用 200Mb 左右 分析日志时占用 300Mb 在接受范围内 毕竟方便了很多

[location123]

@location123 UI 好看

[ChangQin]

我们已经用 Kotlin Multiplatform 来开发跨平台了，用的是 UI+Logic 跨端，各自平台不同的写桥实现。目前就是感觉一些工具类写桥比较麻烦，UI 上大部分都很方便，还有就是 iOS 侧滑返回目前还没官方组件，这个比较坑。

[StinkyTofus]

@ChangQin #14 那就差不多了

[JZen]

用了三个月，大体没什么毛病，只遇到一个比较坑的问题，列表没有滚动条，需要自己手搓一个

[fan123199]

写了几个 App 了，都是 Compose ，确实有一些极限场景有性能问题需要考虑。但是开发体验熟悉后挺舒服的，比写 xml 舒服多了。

[listen6256]

compose 开发真的很爽，开发效率比 xml 高很多。
就是在低端机上性能拉跨，尤其是 compose 的动画在低端机上卡成 ppt ，还有就是 lazy 系列组件，在数据量大时，性能很差。

[JayZXu]

比传统 xml 开发爽，跟现在的前端写法一样一样的
但是学习成本高，教程也少，查个文档也麻烦，很多东西都需要摸索

[monkeylmj]

@listen6256 低端机上性能拉跨的主要原因是什么呢？我理解底层都是用 skia 之类的来渲染的，同样是低端手机用旧的一套和新的 compose 差别很大吗，是 compose 自身优化的问题么。

[kapaseker]

我们公司一个 APP ，当然也是我主导写的，鹿驾旅行，目前在 OV ，小米商城已经上线了，你要是想看看的话，可以试试瞅一瞅。
完全的 Compose 编写，一个字，爽！！！

[laikick]

Compose 写 window 端有没有坑.

[monkeylmj]

@kapaseker 下载体验了一下，很丝滑哈哈

[109021017]

总体上还是不错的, 遇到过一个坑: 部分国产手机的"安全键盘"第一次弹起时输入不了.

[yl20181003]

嵌套滚动是个硬伤，我没找到解决办法。

[monkeylmj]

@yl20181003 不好处理滑动冲突之类的吗？

[murmurkerman]

挺好的，就是一些 ui 组件可能不符合你们自己的要去，要复制官方代码修改。包括 switch ，menu ，tab 之类的。导航组件目前支持了 safeargs ，对话框存在一些显示问题。其它都挺好的包括与 view 系统的集成，嵌套滚动之类的。

[kapaseker]

@monkeylmj 其实 compose 性能还是很好的，不过老机器效果有问题，就像我做的阴影，老机器就是黑块

[kapaseker]

@yl20181003 我现在用的方案就是根布局就用 lazylist 或者 lazygrid 做

[yl20181003]

@monkeylmj #26 是的，典型的 VerticalPager 嵌套一个可滚动的 Column 根本就划不到下一页去。

[yl20181003]

@kapaseker #29 我需要实现抖音那样的上下滑动翻页，并且每一页的高度都是不固定的，用 Pager 组件 根本就实现不了，最后还是换回了 xml ，用 ViewPager2 + RecyclerView

[kapaseker]

@yl20181003 抖音那个我还以为每页高度是一样的呢

[wwalkingg]

@yl20181003 #31 Compose 有 NestedScroll 的特别文档，你可以看看

[yl20181003]

@wwalkingg #33 感谢提醒，之前有简单尝试过用 NestedScroll ，但没达到预期效果，后续再研究研究

[AaronLee01]

@yl20181003 Modifier 的 nestedScorll 解决不了你的问题么

[yl20181003]

@AaronLee01 #35 没解决，可能我对 Compose 了解的不够深入吧，已经换到 xml 布局了。

[Venjer]

还是玩具，生产还是用 flutter ，比较成熟。

[Flyfish233]

现在几乎不会编写 View 了，可以说都忘光了，基本上写的都是 Compose 。
在低端设备上使用 Compose ，和 View 相比，同样的业务，性能会很差，我做 Wear OS ，在只能手表上拥有难以想象的卡顿，各种优化全部上了，没有看到好转。
而且有一些操作系统特色功能无法实现，只要有一个文本框，我就能判断这个应用是否是 Compose 。
如果不考虑这个，那么还是可以的，因为写的爽。

[Flyfish233]

@Flyfish233 只能 -> 智能
判断方法： https://www.reddit.com/r/mAndroidDev/s/4xcoa9VbgP
因为 Compose 是自行实现的，所以会和系统提供的不符，很正常