性能优化：重组优化、列表性能与Profile工具

各位同学好，今天我们来聊聊性能优化。说实话，性能优化这个话题，很多开发者觉得是「高阶内容」，其实不然。我刚开始用Compose时也踩过不少坑——界面卡顿、列表滑动掉帧、莫名其妙的重组……嗯，今天我把这些经验都梳理出来，希望能帮你少走弯路。

核心观点：Compose的性能问题，90%出在「不该重组的时候重组了」。剩下的10%，是列表没用好key。

重组优化：remember与derivedStateOf

先说说重组。Compose的核心理念是「状态驱动UI」，状态变了，UI自动更新。但问题是——状态变化太频繁，重组次数太多，性能就崩了。

我遇到过这样一个场景：一个列表项里有个倒计时，每秒更新一次。结果整个列表每秒都重组一次，滑动时卡得不行。后来怎么解决的？用remember把不变的部分缓存起来。

remember：缓存计算结果

remember的作用很简单：把计算结果存起来，下次重组时直接复用。看个例子：

@Composable
fun ExpensiveItem(data: Data) {
    // 错误写法：每次重组都重新计算
    val formatted = formatData(data) 
    
    // 正确写法：只有data变化时才重新计算
    val formatted = remember(data) { formatData(data) }
}

这里有个细节：remember的key参数。如果你不传key，那这个值永远不变；传了key，只有key变化时才重新计算。我个人习惯是：能传key就传，别偷懒。

小技巧：如果你有个计算开销很大的操作（比如字符串拼接、JSON解析），一定要用remember包起来。我在项目中见过有人把SimpleDateFormat放在Composable里，每次重组都new一个对象——这其实没必要。

derivedStateOf：派生状态

再说derivedStateOf。这个API我特别喜欢，它解决了一个很实际的问题：当某个状态是由其他状态计算而来时，没必要每次都重新计算。

举个例子：

@Composable
fun ShoppingCart(items: List<Item>) {
    // 错误写法：每次重组都遍历整个列表
    val totalPrice = items.sumOf { it.price * it.count }
    
    // 正确写法：只有items变化时才计算
    val totalPrice by remember { 
        derivedStateOf { items.sumOf { it.price * it.count } }
    }
}

为什么会这样？因为Compose的重组粒度是「函数级别」。如果你在Composable里直接写计算逻辑，那每次重组都会执行一遍。用derivedStateOf包起来，Compose会帮你做「惰性计算」——只有依赖的状态变了，才重新算。

注意：derivedStateOf不是万能的。如果你的计算逻辑依赖多个状态，而且这些状态变化很频繁，那用derivedStateOf反而可能增加开销。我建议：先测量，再优化。

列表性能：key与contentType

列表性能是另一个重灾区。我记得有一次，一个同事说「我的列表滑动好卡」，我一看代码——LazyColumn没传key。嗯，这问题太典型了。

key：给每个列表项一个身份证

key的作用是告诉Compose：「这个列表项是唯一的」。没有key，Compose只能靠位置来识别列表项——一旦数据顺序变了，整个列表都得重建。

@Composable
fun MessageList(messages: List<Message>) {
    LazyColumn {
        items(
            items = messages,
            key = { it.id }  // 用唯一ID作为key
        ) { message ->
            MessageItem(message)
        }
    }
}

这里有个坑：key必须是稳定的。如果你用index作为key，那跟没传一样。我见过有人用message.hashCode()——这也不靠谱，因为hashCode可能重复。

最佳实践：用数据库主键、UUID或者业务唯一标识作为key。如果实在没有，可以用message.id + "_" + message.timestamp组合一下。

contentType：告诉Compose列表项的类型

contentType是个容易被忽略的参数。它的作用是：当列表项类型不同时，让Compose知道哪些可以复用。

举个例子，一个聊天列表里既有文本消息，又有图片消息，还有系统通知。它们的布局完全不同：

@Composable
fun ChatList(messages: List<Message>) {
    LazyColumn {
        items(
            items = messages,
            key = { it.id },
            contentType = { it.type }  // "text", "image", "system"
        ) { message ->
            when (message.type) {
                "text" -> TextMessage(message)
                "image" -> ImageMessage(message)
                "system" -> SystemMessage(message)
            }
        }
    }
}

加了contentType后，Compose会为每种类型维护独立的「复用池」。这样，文本消息的Composable不会被图片消息「污染」，性能会好很多。

避免过度绘制

过度绘制（Overdraw）是UI性能的隐形杀手。说白了就是：同一个像素点被画了多次。

在Compose里，过度绘制通常由以下原因引起：

  • 多层背景叠加：父容器设了背景色，子容器又设了背景色
  • 不必要的裁剪：用clipToBounds或clip裁剪了不需要裁剪的内容
  • 透明度过高：多个半透明图层叠加，GPU得算半天

我遇到过最夸张的一个案例：一个简单的卡片列表，每个卡片有3层背景——Card的背景、Column的背景、Text的背景。结果GPU每帧要画3遍同一个像素点。去掉多余的背景后，帧率从45fps直接升到60fps。

检查方法：在模拟器或真机上打开「显示过度绘制」选项（开发者选项里）。颜色越红，说明过度绘制越严重。理想状态是蓝色或绿色。

Profile工具使用

说了这么多理论，怎么落地？用Profile工具。Android Studio自带的Profile工具，能帮你定位性能瓶颈。

我常用的几个功能：

工具 用途 我的使用习惯
CPU Profiler 查看函数调用耗时 先跑一遍，看哪个函数耗时最长
Memory Profiler 检查内存泄漏和GC频率 列表滑动时看内存是否持续增长
Layout Inspector 查看Composable的层级和重组次数 看哪些Composable被「过度重组」了

具体怎么用？我一般这么操作：

  1. 打开Profile，选择「CPU」和「Memory」同时记录
  2. 在App里执行有问题的操作（比如快速滑动列表）
  3. 停止记录，看火焰图——哪个函数占用的时间最长
  4. 点进去看代码，找到问题点

举个例子，有一次我发现Text组件的重组次数异常高。点进去一看，原来是我在Text里用了remember但没传key，导致每次重组都重新计算字体样式。加上key后，问题解决了。

注意：Profile工具本身会消耗性能。所以，不要在Profile运行时做「性能对比」。正确的做法是：先不Profile，跑一遍看卡不卡；再Profile，定位问题；修复后，关掉Profile再跑一遍验证。

知识体系总览

最后，我用一张图总结一下本章的核心内容。这张图展示了性能优化的几个关键维度，以及它们之间的关系：

Compose性能优化知识体系 性能优化 重组优化 remember / derivedStateOf 列表性能 key / contentType 避免过度绘制 减少背景叠加 / 裁剪 Profile工具 CPU / Memory / Layout Inspector 核心原则 先测量，再优化 不要过度优化，找到真正的瓶颈

这张图把今天讲的内容串起来了。你可以看到，性能优化不是孤立的技术点，而是一个体系——从重组优化到列表性能，再到避免过度绘制，最后用Profile工具验证。每一步都环环相扣。

好了，今天就到这里。记住一句话：性能优化不是炫技，而是让用户用得更爽。下次遇到卡顿，先别急着改代码，打开Profile看看，找到真正的瓶颈再说。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →