1. 项目背景与性能问题定位
最近在做一个模拟项目，需要把一套基于 Flutter 的信息流垂直列表界面迁移到 OpenHarmony 设备上跑。界面本身不算复杂：顶部一个轮播图，中间是若干图文卡片，底部还有加载更多的状态提示，一个典型的手机端 ListView 场景。本来以为 Flutter 的跨端能力会让我省很多事，结果真机一跑，发现事情远没有想象中那么简单。
最初版本在 OpenHarmony 真机上滑动时，帧率只有 30fps 出头，快速滚动时甚至能明显感觉到列表在“抽搐”。用 profiling 工具抓了 Flutter 引擎的 timeline，发现 UI 线程的 build 耗时和 raster 线程的绘制耗时双双超标。更奇怪的是，内存占用在持续滚动过程中不断攀升，一度逼近设备的低内存阈值，触发了几个不必要的回收周期，进一步加剧了卡顿感。
这篇文章就把我这次优化过程中踩过的坑、用到的方案、以及最终沉淀下来的一套可复用的 ListView 性能调优路径完整写出来。内容会比较偏实战，涉及的工具链和排查思路同样适用于 Flutter 在其他平台上的列表优化，只是 OpenHarmony 这个环境有些特有的注意点。
先说结论：经过三轮针对性优化，列表帧率从 30fps 提升到稳定 58fps 到 60fps，内存峰值下降了约 40%，快速滚动时的掉帧次数从每次滑动上百次降到个位数。后面我会把每一步的原理和操作细节全部拆开讲。
1.1 为什么 Flutter 的 ListView 在 OpenHarmony 上更吃力
很多人会觉得 Flutter 渲染层不依赖原生控件，跨端表现应该一致，这个认知大方向没错，但实际运行环境的影响远比想象中重要。
OpenHarmony 当前对 Flutter 的支撑主要通过 adapter 层把 Flutter 的渲染 surface 桥接到系统的合成器。这个桥接过程会引入额外的纹理拷贝开销，尤其是在设备采用 GPU 共享内存策略不理想的情况下，纹理上传耗时会被明显放大。加上 OpenHarmony 上 Flutter 引擎的 skia 后端跟 Android 上成熟的 GPU 驱动优化生态相比，部分绘制指令的 fallback 路径更多，Raster 线程的负担本来就要重一些。
在这种环境下，ListView 的每一项如果还带着复杂的布局和重复创建的纹理，性能瓶颈就会被进一步放大。所以同样的代码在 Android 上可能只是轻微卡顿，到了 OpenHarmony 上就变成完全不能用的程度。
我最初的原型代码几乎是直接把业务页面从另一个跨端项目里搬过来的，用了大量嵌套的 Column、Row、Padding、Container，卡片内部还有图片加两行文本。每个 item 的 widget 树深度达到八层以上，build 耗时在低端设备上能到 12ms 到 15ms，这就已经超过一帧 16.6ms 的预算中可用的大头了。如果再算上 raster 线程的开销，掉帧是必然的。
1.2 优化前需要明确的核心指标
做性能优化最忌讳漫无目的地瞎试。我给自己定了一套量化指标，每个优化动作前后都跑同一段滑动路径做对比，这样才知道哪个改动真正有效。
第一是 UI 线程 build 耗时，对应 Flutter 的 frame build 阶段，在 timeline 里直接看每个 frame 的耗时；第二是 Raster 线程绘制耗时，核心是 paint 和纹理上传的耗时；第三是帧率与掉帧数，用 profile 模式跑一段标准滚动，统计 60fps 目标下的掉帧总数；第四是内存增长曲线，连续滑动三分钟后观察总内存和 Dart 堆占用变化。
我整理了一张简单的测试基准表，每次优化都拿这组数据说话。
| 指标 | 基线值（优化前） | 优化目标 |
|---|---|---|
| UI 线程 build 平均耗时 | 12ms 到 15ms | 小于 6ms |
| Raster 线程绘制平均耗时 | 10ms 到 13ms | 小于 6ms |
| 快速滚动 3 秒掉帧数 | 100 次以上 | 小于 10 次 |
| 连续滚动内存峰值 | 约 480MB | 小于 300MB |
有了这份基线，后面的每一步优化都能清楚知道是拉了哪个指标，避免做无用功。
2. 优化方案的整体设计思路
2.1 先区分“业务层问题”与“框架层问题”
在对 ListView 本身下手之前，我先花了一些时间确认卡顿到底来自业务代码还是框架适配层。方法很简单：用一个只显示 50 个 Text 的极简单列表项去跑同样的滑动路径，帧率能达到 58fps，说明引擎和 OpenHarmony 适配层的底子是没问题的，瓶颈就在业务 item 的构建和绘制成本上。
这一步非常关键。很多人一上来就调 ListView 的参数，改 cacheExtent、改 itemExtent，结果问题根因是 item 内部的图片加载没有做缓存，或者 widget 嵌套过深导致重建成本高。这样调半天参数也解决不了问题。
在确认业务层是主要瓶颈之后，我的优化路线就很清晰了：第一步是减小 item 构建开销，目标是少做事；第二步是提升复用效率，目标是少创建；第三步是降低绘制开销，目标是少画；第四步是针对 OpenHarmony 特有的纹理和图层问题做专项调优，目标是少拷贝。
这四步不是孤立的，前后有依赖关系。比如说如果你不把 item 的 widget 树压扁，光靠 RepaintBoundary 也不能根治问题，因为 build 阶段的消耗还是在那里。反过来如果你光优化 build，但图片纹理每次都重新上传，raster 线程依然会被拖死。
2.2 ListView 的核心工作机制与关键参数
ListView 本身是懒加载机制，这在 Flutter 里很多人知道，但理解到什么程度差别很大。ListView 只会 build 当前可视区域内以及 cacheExtent 范围内的 item，这个逻辑由 SliverList 内部的 SliverChildBuilderDelegate 控制。
cacheExtent 指的是视口上下各额外预构建多少逻辑像素的内容。默认值是 250 逻辑像素，在 OpenHarmony 的一些低内存设备上，这个值偏保守，快速滚动时会出现还没滚到就看到空白区域的情况。但如果把 cacheExtent 调得过大，比如到 1000，又会让内存和构建耗时显著上升，因为需要提前 build 的 item 数量变多。
另一个关键参数是 itemExtent，它用来告诉列表每个 item 的高度是固定的。如果所有 item 高度一致，强烈建议设置这个参数，因为这样 Flutter 就不需要在 layout 阶段通过实际测量每个 item 来确定滚动范围，而是直接按固定高度计算，能显著减少 layout 耗时。
但实际业务里 item 高度往往不完全一致，比如我的轮播图和普通卡片高度就不一样。这时候可以做一种折中处理：把 item 按类型分组或者用固定高度设计统一尺寸，或者手动预估一个平均高度。Flutter 也提供了 itemExtentBuilder 这种更灵活的方案，可以在一定范围内做预估。
我这里最终选择了全列表统一固定高度方案。做法是把所有卡片内容裁剪到同一视觉高度，多余的文字用省略号处理，图片区域也统一换算成相同高度。这样做的收益非常大，layout 阶段几乎为零额外开销，滚动位置的估算变得极其精确。
2.3 平台适配层对方案选型的影响
在选择优化手段时，还需要考虑 OpenHarmony 适配层的能力边界。比如 Flutter 的 shader warm-up 在 OpenHarmony 上目前支持不够完善，首次进入页面会有一波 GPU 编译导致的卡顿。这时候就不要依赖 shader 预热那套方案，而是应该减少自定义 shader 的使用，尽量走框架内置的绘制路径。
同时 OpenHarmony 的纹理上传路径比标准 Android 要重一些，所以图片相关的优化优先级需要提到很高。我后面在图片加载方案里会把大图降采样、复用位图内存这些动作放在比较靠前的位置，因为对 raster 线程的收益最直观。
还要注意 Flutter 的 Impeller 渲染引擎在 OpenHarmony 上的支持还在逐步完善中，我那个测试环境下依然是走 Skia 后端。Skia 对绘制指令的 batch 优化能力弱于 Impeller，所以尽量避免在 item 里使用过多独立的阴影、模糊、遮罩效果，这些在 Skia 下会变成多张离屏纹理，开销非常大。
3. 列表项构建层面的优化实操
3.1 压扁 Widget 树，控制 build 复杂度
优化从最直接的 build 耗时入手。我原来的 item 结构大概是这样的：Container 外层包圆角背景，内部一个 Padding，再套一个 Row，Row 左边是图片，右边是一个 Column，Column 里又有两三层嵌套的 Text 和间距。这样一棵树在 build 时有大量中间层的布局计算，并且每当父级 rebuild 时这些层都会参与比对。
我把结构压成了尽量扁平的形态：用自定义的 RenderObject 去画背景圆角，替代 Container 加 BoxDecoration 的组合；通过预先组合好的 Widget 对象来减少重建判断的开销。这个阶段我用了一个简单的原则：每一个多出来的 Padding 或 Container 层，至少要问一次“它是否真的承担了独立的布局或者绘制职责”。
改造后 item 的平均 widget 深度从八层降到了四层，build 耗时从 12ms 降到了 7ms 左右。这个收益非常直接，因为 build 阶段是所有 item 创建和更新的必经之路，压扁一点，每个 item 省下的时间在滚动时会被放大几十倍。
3.2 用 itemExtent 消除重复测量开销
之前提到我最后选了固定高度方案，实际上这个优化在压扁树之后紧接着就做了。固定 item 高度之后，ListView 内部的 SliverConstraints 处理不再需要对每个 item 做 layout 测量来确定滚动范围，滑动时的位置计算变成纯算术问题。
具体操作上，我给 itemExtent 设置了一个具体像素值，同时把内部所有卡片内容都调整为这个高度。轮播图区域我用单独的 header 插在列表前面，头部不占用 itemExtent 的额度，通过 SliverToBoxAdapter 和 ListView 的 header 机制实现。这样既保持主列表固定高度，又不影响顶部异形区域的存在。
如果你实在没办法统一高度，建议至少使用 itemExtentBuilder，它能根据 index 返回预估高度。Flutter 内部会基于这些预估做滚动范围推算，实测比默认的预估策略要准不少，能明显降低滚动条跳动和跳帧的概率。
3.3 图片加载：降采样、缓存与复用
图片是列表性能杀手，在 OpenHarmony 上尤其明显。我的信息流卡片里每张图分辨率大概在 1200 像素宽，但实际显示区域只有 400 像素宽，如果不做处理，每张图都以原始尺寸解码并上传 GPU，纹理内存直接爆炸。
我使用的图片加载方案是基于缓存组件的常规路径，但做了几个关键调整。首先是解码前降采样，取图片文件后不直接全尺寸解码，而是用解码器先读取图片宽高，结合目标显示尺寸计算采样率，只解码所需要的像素量。对这个项目来说，采样率从 1 直接调到了 3，单张图片的 decode 内存直接降到原来的九分之一。
其次是图片内存复用。在滚动过程中不断创建新的图片缓冲区是内存抖动的主要原因。我复用了图片缓存池，让退出屏幕的 item 把图片对象归还给池子，新的 item 从池子里取，这个做法在 OpenHarmony 上效果尤其明显，因为它的 malloc 和 GC 行为在频繁分配大内存时表现不理想。
最后是避免图片在 GPU 侧的重复上传。我给图片组件外层套了 RepaintBoundary，同时确保图片 widget 在滚动时不会被标记为需要重新绘制。这样 GPU 纹理只需要上传一次，后续滚动只是采样同一个纹理里的不同区域。
这套组合拳打完后，Raster 线程的绘制耗时从 10ms 掉到了 5ms 左右，内存增长曲线也平稳了很多。
3.4 addRepaintBoundary 的正确使用姿势
RepaintBoundary 可能是 Flutter 优化里最常见的词，但实际用对的人不多。它的作用是隔离重绘区域：在列表项外面套一层 RepaintBoundary 后，单个 item 的内容变化不会导致整个列表重新绘制，只是重新绘制这个 item 对应的图层。
需要注意的点是 RepaintBoundary 本身也有开销，因为每个边界都可能产生独立的图层合成，图层数量太多时合成器压力反而会变大。我的经验是：对有图片的卡片、有复杂阴影或形状的 item 包裹 RepaintBoundary，纯文本的轻量 item 不包。这样既保证了重绘隔离，又不会让图层数量失控。
在 OpenHarmony 上还有一个特性需要注意：过多的图层合成对系统合成器的压力比 Android 上明显。所以我会跑到列表外层的滚动容器上再加一道 RepaintBoundary，把整个列表区域和页面其他部分隔离。这样列表滚动导致的变化不会牵连到页面顶部的标题栏和底部导航的重绘。
4. 滚动过程中的专项优化
4.1 cacheExtent 参数调优与预加载策略
一开始因为我担心快速滚动出白屏，把 cacheExtent 调到了 800 逻辑像素，结果内存涨得很快。后来我用 Android Studio 的 Flutter inspector 观察了到底有多少 item 被提前构建了才发现，视觉区域内最多同时显示 5 个 item，但 cacheExtent 拉大后，构建 cache 区内的 item 数量翻了一倍还不止。
最终我把 cacheExtent 改回了 250 默认值附近，并把加载更多的触发位置从列表底部提升到了最后三个 item 可见时。通过 ScrollController 监听滚动位置，一旦检测到剩余可滚距离小于三个 item 高度，就主动触发分页加载。这样用户快速滚动时，数据已经准备好，不会因为异步请求而白屏等待。
你可能会觉得，预加载变多不是会消耗更多资源吗？这里的关键是预加载出来的 item 在用户真正看到之前不参与绘制，只停留在构建和布局阶段。配合 itemExtent 固定高度，这部分预构建成本是可预估且可控的。实测下来快速滚动时白屏出现的概率从 30% 以上降到了 3% 以下。
如果你也遇到快速滚动白屏的问题，不要一上来就加 cacheExtent，先看数据加载是不是阻塞了 build。很多时候问题出在 item builder 内部同步做网络请求或者解析 JSON，那才是真正的元凶。
4.2 滚动监听与帧率感知，按需调整加载优先级
在优化过程中我还发现一个容易被忽略的问题：加载更多和图片解码这些耗时操作，在快速滚动时会和帧绘制抢 CPU 资源。尤其是图片解码默认跑在 IO 线程，但 OpenHarmony 的 IO 线程池调度在负载高时表现不佳，会和 UI 线程抢时间片。
我的处理方式是给数据加载和图片加载分别加了一个简单的“滚动状态感知”逻辑：当滚动速度超过每秒 1500 逻辑像素时，暂停触发新的图片解码，只保留当前帧绘制的必需任务；当滚动速度降下来或者完全停止后，再恢复解码队列。这个逻辑用 ScrollController 的 position 变化监听就能实现，代码量不大，但对滚动静置时的流畅度收益很明显。
这个方案听起来有点像 Games 领域里的 LOD 思路，也就是距离远的物体降低渲染精度。我在图片加载上也做了类似的适配：快速滚动时先加载低分辨率的模糊占位图，停止后再替换成高清图。替换过程因为有图片缓存，不会产生新的 decode 压力，体验上几乎察觉不到。
4.3 深挖 OpenHarmony 上的滚动掉帧专项问题
在完成前面的优化后，帧率已经能达到 50fps 上下，但离 60fps 还有距离。我抓了 Raster 线程的 timeline，发现每隔几十帧会出现一次掉帧尖峰，持续时间 20ms 以上，明显不是连续性的负载问题。
反复对比之后，定位到两个 OpenHarmony 特有原因。第一个是系统合成器的 buffer 数量配置问题。Flutter 引擎在 OpenHarmony 上创建 surface 时，默认申请的双缓冲在某些驱动版本下会频繁触发 buffer 抢占等待，表现为周期性丢帧。这个问题需要在 Flutter engine 层或系统层调整 buffer 申请策略，业务侧能做到的是减少图层数，避免每个图层都要独立参与合成。
第二个原因是 Dart 堆的 GC 停顿。当 item 对象在快速滚动中被大量创建和销毁时，Dart 的新生代回收会造成短暂停顿。我通过对象池复用 item 的数据模型和图片句柄，大幅减少了临时对象的产生，GC 触发频率从每秒好几次降到了每几分钟一次，那些周期性尖峰基本消失了。
同时我把一部分确实需要频繁创建的对象，比如滚动位置的记录结构，改成了复用实例并进行字段覆盖。这可能听起来有点偏底层，但在处理极限性能问题时，每一处小开销都值得抠。
5. 通用性能问题速查与排查技巧
5.1 使用 Flutter DevTools 和 Timeline 定位性能瓶颈
排查性能问题最常用也最可靠的方式是跑 profile 模式，这个模式下 Dart 代码以 release 方式运行，能反映真实性能。然后把 timeline 数据导出来，一张图看全 UI 线程和 Raster 线程的帧耗时分布。
我通常先看整条帧耗时曲线的形状：如果 UI 线程频繁超过预算，说明 build 或 layout 成本太高，回到 item 构建优化；如果 Raster 线程持续高，说明绘制指令或纹理开销大，去看图片解码、阴影和图层数量；如果两边都有问题，优先处理 UI 线程，因为它一卡，raster 再快也没有用。
DevTools 里的“Layer”面板也非常值得用。它能查看当前页面的图层树，里面每个 RepaintBoundary 都对应一个独立的 layer，你可以直接看到哪些图层的绘制频率异常高。高绘制频率的图层实际上在每帧都产生绘制操作，如果有不必要的内容混在里面，很容易找到。
5.2 OpenHarmony 真机实测中的 Flutter 特别坑
这一节我列一些我实际遇到的、Flutter 通用排查经验里不容易覆盖到的问题。
第一个是字体渲染差异。OpenHarmony 系统字体族和 Android 不完全一致，某些 Text 组件在不指定字体的状态下会在区间 fallback 时产生额外的布局计算。建议在全局主题里显式指定 fontFamily，并且关闭字体降级搜索机制，在 OpenHarmony 上这个优化能把纯文本列表的 build 耗时压下去将近 10%。
第二个是 frame 回调的坑。OpenHarmony 的 v-sync 回调在某些设备上存在相位偏移，Flutter 引擎如果对齐到错误的信号周期，会出现“半帧延迟”现象，体感上就是有点微卡但测帧率又不太明显。这个情况业务代码没办法直接改，但能通过减少每帧工作量来给引擎留出足够的缓冲余量。
第三个是 Window 尺寸变化和 DPI 混淆问题。部分设备在跨屏显示时有分辨率适配异常，列表的 cacheExtent 换算成物理像素后容易偏大，直观表现为内存涨幅异常。可以用 MediaQuery 的实际 devicePixelRatio 重新校验逻辑像素和物理像素的换算关系，必要时手动修正 cacheExtent。
5.3 长列表内存增长的自我体检方法
列表内存问题很容易被忽略，因为跑半小时才出现明显异常。我给自己定了一套体检流程：连续快速滚动 200 个 item，然后停止一分钟，反复五次，观察内存曲线。
如果内存曲线随着滚动次数阶梯式上升且不回落，优先怀疑 item 里的对象没有被释放。重点检查图片相关的 Completer、流的订阅、AnimationController 是否在 item 销毁时被正确清理。
如果内存曲线上升后能回落，说明 GC 能回收，但回收频率过高仍会影响流畅度，这时候需要减少临时对象。逻辑上最粗暴的做法是把 item 的数据模型改为 mutable 且可复用，builder 里尽量不 new 新的对象。
如果内存稳定但 Raster 线程耗时逐渐上升，多半是 GPU 纹理没有被正确回收。这可能跟 OpenHarmony surface 销毁的延迟有关，在 item 销毁后手动调用图片缓存的清理方法，或者降低全局图片缓存上限，能缓解这类问题。
5.4 一个可复制的实战排查路径清单
最后我把这次优化的完整流程整理成了一个可复制的清单。按照这个顺序排查，大部分列表性能问题都能找到答案。
第一步，建立基线数据，明确 build、raster、掉帧、内存四个维度的现状。没有量化基线，优化就是盲人摸象。第二步，用极简 item 验证平台底层有没有致命问题，确认问题在业务层。第三步，压扁 widget 树，设置 itemExtent，这是性价比最高的两步。第四步，处理图片解码和纹理缓存，这是 raster 线程的核心负担。第五步，用 RepaintBoundary 隔离重绘，但不要滥用。第六步，调 cacheExtent 和加载策略，解决快速滚动白屏。第七步，针对 OpenHarmony 特有现象，字体、图层、GC 挨个排查。第八步，回归测试，跑多次标准滑动路径，对比优化前和优化后的数据。
这套排查路径不只适用于 OpenHarmony 和 Flutter 的组合，任何 Flutter 列表性能问题都能从里面找到对应的手段。
6. 最终优化的数据效果与经验心得
6.1 优化前后的数据对比
我把几轮优化后的数据汇总了一下，和最初的基线放在一起对比，差距还是很直观的。
| 指标 | 优化前基线 | 优化后结果 | 提升幅度 |
|---|---|---|---|
| UI 线程 build 平均耗时 | 13ms 左右 | 4ms 到 5ms | 约 65% |
| Raster 线程绘制平均耗时 | 11ms 左右 | 4ms 到 6ms | 约 55% |
| 快速滚动 3 秒掉帧数 | 100 次以上 | 5 次以内 | 超过 95% |
| 连续滚动内存峰值 | 约 480MB | 约 280MB | 约 42% |
| 普通滑动帧率 | 30fps 左右 | 稳定在 58fps 到 60fps | 接近翻倍 |
这个成绩是在一台中低端 OpenHarmony 真机上测出来的。如果是在性能更好的设备上，优化空间可能不会有这么夸张，但方向和方法完全一样。
有一点要说明，这些数据只是我的测试设备和测试路径下的结果，不代表所有 OpenHarmony 设备都能达到同样水平。但优化的方向是通用的，每一项改动都经过了 A/B 对比验证，我确认它是有效的。
6.2 在 OpenHarmony 上做 Flutter 列表优化的几点心得
第一点，不要迷信 Flutter 跨端的一致体验。Flutter 渲染确实是自绘的，但 GPU 驱动、适配层、系统调度都会影响最终表现。必须用真机一步步验证每个改动，模拟器上的数据参考价值有限。
第二点，性能优化一定要有优先级的判断。把 build 耗时、绘制耗时、内存占用排个序，先处理最影响体验的那一项。我这次的经验是 build 优化优先级最高，因为 build 是一切的上游，build 一慢，后续 layout 和 paint 全都会被拖累。
第三点，OpenHarmony 适配层还在快速演进，很多问题可能随着版本更新自然消失。比如某些纹理拷贝开销在新版本引擎里可能会被优化掉。所以代码里尽量通过抽象层隔离平台差异，避免把针对特定版本的 workaround 写死在业务代码里。
这个项目做完之后，我又把同一套优化思路反向移植到了原来的 Android 版本列表上，效果虽然没有 OpenHarmony 上那么夸张，但帧率和内存也都明显变好。也就是说，这些列表优化的手段本身具备跨平台通用性，OpenHarmony 环境的特殊性只是让问题暴露得更集中、更明显。这算是这次实践里除了性能数据之外，另一个让我觉得收获很大的地方。
