1

看你是哪种复杂，我在性能极低的设备上测试过(rk3568)，compose 平铺绘制 10*10 显示 100 个对象状态的的 grid ，和使用 xml/view 绘制，compose 初始渲染需要 0.5s-1s （也可能是我优化问题，但我尽量优化了），xml 布局则完全无延迟。不过这两种性能差距在正经手机上运行几乎没有差异

2

3

4

关注一下。。。我用 compose 开发了些复杂列表(横竖列表/pager 嵌套)，实现难度上远低于原生， 能想到的点都优化了一下，release 包流畅性感觉还行

5

@shakukansp 这个我知道 我只是好奇 2 种不同的方式他的原理是啥 既然 compose 是新的东西 肯定有他的优势的地方嘛

6

其实这么多年了 xml 所谓的解析耗时, 早都优化了..

7

@auhah 你是说 实际上在复杂场景上 compose 开发的流畅度上 跟原生区别不大嘛？

8

如果是大数据列表，还是用原生。我自己做的离线播放器项目就是这么处理的。一开始用的是 Compose 的列表视图，效果不是很好。其他的主要是降低重组次数

9

10

原生 xml 多级嵌套，控制不好会导致页面重绘，即 draw 多次执行，compose 组件嵌套可以理解为多个 if else 判断，其实都是在一次 draw 里面处理的，所以嵌套理论上不会影响性能，性能的影响主要在 state

11

理论上高于 xml 的，但是从 xml 转的基本都会有性能问题，要变换思路

12

有这种感觉，不知为何，非专业 android 开发。

13

如果 compose 出现了性能问题，优先开发人员的原因，他使用 xml 布局也一样会出现性能问题。

14

Compose 没有什么性能问题。
技巧上一个是多用 lazy ，另一个是多用 key 。
大部分时间用 stable 的数据和集合，都不会有什么问题。

16

Compose 的性能问题很大程度取决于状态管理是否合理，需要拆分并管理好每个组件的状态，避免多余的重组。如果状态管理不善，一些简单的页面也会性能拉垮。

17

@cenbiq 是不是拿 debug 包对比了，compose 的 debug 包性能会比较差