这是一个创建于 56 天前的主题，其中的信息可能已经有所发展或是发生改变。
请教下 在用 compose 写页面的时候 如果页面比较复杂 逻辑比较多 对比下用以前 xml 的写法来处理 性能上会好些吗
我只了解每个 view 都是会走测量绘制流程的 但是 compose 这种怎么体现出来的 我感觉大量的 compose 组件肯定也会导致这种绘制卡顿的问题吧
这块没接触过 有老哥知道嘛
 |
1
cenbiq 2025 年 11 月 25 日
看你是哪种复杂，我在性能极低的设备上测试过(rk3568)，compose 平铺绘制 10*10 显示 100 个对象状态的的 grid ，和使用 xml/view 绘制，compose 初始渲染需要 0.5s-1s （也可能是我优化问题，但我尽量优化了），xml 布局则完全无延迟。不过这两种性能差距在正经手机上运行几乎没有差异
|
 |
2
shakukansp 2025 年 11 月 25 日
用户有列表有 200 多个项目的
没听用户说卡过 有 lazy column |
 |
3
rcj6056 OP @cenbiq 我也用过 rk 板
你这个是怎么优化的 好奇 感觉老哥你做性能方面的东西的吧 请问下 关于内存泄漏这种问题 一般怎么处理的 比方查到的某个页面存在泄漏 怎么去查看调用链 怎么去处理分析 有做过么 |
 |
4
auhah 2025 年 11 月 25 日
关注一下。。。我用 compose 开发了些复杂列表(横竖列表/pager 嵌套)，实现难度上远低于原生， 能想到的点都优化了一下，release 包流畅性感觉还行
|
|
5
rcj6056 OP @shakukansp 这个我知道 我只是好奇 2 种不同的方式他的原理是啥 既然 compose 是新的东西 肯定有他的优势的地方嘛
|
 |
6
wow0o 2025 年 11 月 25 日
其实这么多年了 xml 所谓的解析耗时, 早都优化了..
|
 |
8
LLLeo 2025 年 11 月 25 日
如果是大数据列表，还是用原生。我自己做的离线播放器项目就是这么处理的。一开始用的是 Compose 的列表视图，效果不是很好。其他的主要是降低重组次数
|
|
9
auhah 2025 年 11 月 25 日
|
 |
10
liuchenx 2025 年 11 月 25 日
原生 xml 多级嵌套，控制不好会导致页面重绘，即 draw 多次执行，compose 组件嵌套可以理解为多个 if else 判断，其实都是在一次 draw 里面处理的，所以嵌套理论上不会影响性能，性能的影响主要在 state
|
 |
11
RightHand 2025 年 11 月 25 日 via Android
理论上高于 xml 的，但是从 xml 转的基本都会有性能问题，要变换思路
|
 |
12
woniu7 2025 年 11 月 25 日
有这种感觉，不知为何，非专业 android 开发。
|
 |
13
gam2046 2025 年 11 月 25 日
如果 compose 出现了性能问题，优先开发人员的原因，他使用 xml 布局也一样会出现性能问题。
|
 |
14
kapaseker 2025 年 11 月 25 日
Compose 没有什么性能问题。
技巧上一个是多用 lazy ，另一个是多用 key 。 大部分时间用 stable 的数据和集合，都不会有什么问题。 |
 |
15
tanranran 2025 年 11 月 25 日
最新版的 Compose release 模式下已经优化的很好了
具体的优化手段可以参考这两篇文章 https://mp.weixin.qq.com/s/cTgzpy6eOryjSl_7fVXvWg https://mp.weixin.qq.com/s/E7aSn-pXCy9U1b3xEqw1-A |
 |
16
XXWHCA 2025 年 11 月 25 日
Compose 的性能问题很大程度取决于状态管理是否合理，需要拆分并管理好每个组件的状态，避免多余的重组。如果状态管理不善，一些简单的页面也会性能拉垮。
|
Select Language