1. 项目缘起为什么非要用 Flutter 去啃 OpenHarmony 这块硬骨头先交代一下项目背景。我接手的是一个二手物品置换类 App 的 Flutter 端开发业务逻辑不复杂用户拍照上传闲置物品、按分类浏览、搜索、私聊议价、线下交易核心场景就是一套逛闲鱼式的信息流列表。团队一开始选了 Flutter 这条路目标只有一个——用一套 Dart 代码同时覆盖 Android、iOS 和 OpenHarmony 设备尽量降低多端维护成本。为什么不开一条 ArkTS 的原生开发线这件事我们内部争论过好几次。OpenHarmony 毕竟有官方力推的语言 ArkTS而且周边生态日渐完善如果你做的是纯 OpenHarmony 的小场景应用直接用 ArkTS 确实更省事。但我们的情况是存量业务已经全部在 Flutter 上了双端用户基数都不小如果再单独维护一套 ArkTS 实现等于每改一个功能要写两遍。投入产出比太难看。加上 Flutter 在列表渲染、动画、富文本这些场景的成熟度很高社区里能抄的作业多最后团队拍板继续 Flutter把 OpenHarmony 作为第三端接入适配层的问题逐个击破。这个决定放到今天回看性价比是划算的。OpenHarmony 的 Flutter 适配已经能跑通大部分日常 UI 场景做二手置换类的中度交互应用没有硬伤。但真正让我头疼的不是能不能跑起来而是列表性能。二手物品信息流有个天然矛盾用户逛这种 App本质上是在刷图片。一张物品主图加上若干细节图再叠上价格、成色、距离、发布时间、卖家头像每个卡片的信息密度比普通新闻流高得多。而对应的目标设备除了旗舰手机还有大量中低端安卓机、平板甚至 OpenHarmony 生态里的电视盒子、教育平板这类性能并不富裕的设备。如何在低端设备上保持 55fps 以上的流畅度这成了我整个优化周期的核心命题。这篇文章就把我在这个项目里做的列表性能优化完整复盘一遍。从怎么定位瓶颈、怎么设计懒加载和数据缓存到图片解码和组件复用再到 OpenHarmony 平台特有的坑每一刀都是真实项目里切过的。不是在讲教科书理论是拿上过线的代码说话。2. 先搞清楚列表卡顿的元凶二手卡片到底把性能吃在哪里很多人一上来就改代码、加缓存这不太对。性能优化的第一步永远是先量化、先定位。我接手第一版列表的时候中端安卓机实测帧率只有 38fps 左右滑动起来肉眼可见的掉帧低端机上更惨直接到 22fps。但我没有急着去优化而是先拆了一个卡片的构建成本看看到底是什么在拖后腿。2.1 一个二手卡片 Widget 树的规模估算以我们的商品卡片为例一个 Item 大概包含这些元素外层商品主体容器带圆角、边框、阴影图片区主图网络图、成色角标、视频图标部分商品有信息区标题、价格、原价、标签九成新/自提/可小刀、发布时间、距离、浏览数卖家区头像、昵称、实名认证标识、关注按钮数下来一个卡片的所有 Widget 加一起接近 90~120 个节点。这还不算图片解码的耗时以及每个 Widget build 过程中产生的布局计算。ListView 一次性在屏幕上保持可见的 Item 大概 4~6 个加上 cacheExtent 区域里的预构建同时存活的 Item 可能超过 10 个。也就是说任何一次列表滚动都意味着上千个 Widget 节点的比较、重建或布局计算同时在进行。如果你用的是ListView(children: [...])这种一次性全量构建的方式性能问题会成倍放大。我接手的第一版代码里竟然还有人用SingleChildScrollViewColumn包了整个商品列表这属于最基础的错误所有商品不管有没有滚进屏幕全部一次性构建图片全部一次性发起网络请求。这种写法在测试机上看不出问题刷到几百条商品数据后内存直接起飞低端机上打开列表要白屏好几秒。列表页的构建方式没有第二个选择必须是ListView.builder或者SliverList配合懒加载。这一点我后面单独讲。2.2 用帧率分析和 Widget 构建统计锁定瓶颈分布怎么定位我的做法是三步走用 Flutter 自带的PerformanceOverlay开启后覆盖在 App 上直接看 UI 线程和 Raster 线程的帧耗时。二手列表里Raster 线程渲染线程的耗时几乎总是高于 UI 线程尤其快速滑动时出现了明显的Raster 线程峰值。用Dart DevTools的 Timeline 录制一段 10 秒的滑动过程定位哪些帧的 build 耗时超过 16ms。在 Item 的build()里临时打点用Stopwatch统计单次 Item 构建耗时。印象最深的是一个包含 4 张网络图的卡片首帧 build 时间接近 45ms其中图片解码占了大头。结论非常清晰列表卡顿的主要来源不是 Dart 逻辑计算而是图片解码和脏重建的叠加效应。每次快速滑动时新进入可视区的卡片要现场解码多张网络图Raster 线程被打满同时因为 Item 没有做合理的缓存和复用UI 线程也在反复重建大量 Widget两条线程互相拖累帧率自然崩了。搞清楚这一点后我的优化方向才真正明确让列表只构建需要展示的 Item让图片只解码需要被看到的尺寸让重复构建的组件尽量复用让每个 Item 的 setState 触发范围尽量小。下面这几刀都是围绕这个思路展开的顺序也很重要先解决数量问题再解决体积问题最后才是复用问题。3. 第一刀用 Sliver 系组件把存活数量压到最低列表优化的核心不是让你把所有 Item 都做得更快而是让不该存在的 Item 压根不出现。这是一个资源密集型的业务一个用户一天可能浏览几百个商品服务端返回的商品数据条数动辄上千。如果你一口气全塞进内存做什么优化都白搭。3.1 数据层分页与预取的节奏控制服务端分页接口我们设计的是每页 20 条向下滚动接近底部时预取下一页。这个过程有个细节值得说一下不要等滚到底部再触发加载用户会在底部边缘停顿等待那种卡一下才出数据的体验非常差。我实现的是在离底部还有 5 个 Item 时就开始预取同时用一个_isLoadingMore布尔值防止重复请求。if (_scrollController.position.extentAfter itemHeight * 5) { _loadMore(); }这里的一个工程化要点是加载更多数据后不要重建整个列表也不要粗暴地setState(() list.addAll(items))之后让所有可见 Item 都重跑一遍 build。更好的做法是让列表数据源用SliverChildBuilderDelegate承接新增数据只影响后续 Item 的构建。配合Flutter的ListView.builder天然支持局部构建新增数据不会导致已有可见 Item 的重建实测滚动过程中的卡顿少了很多。3.2 滑动构建三大参数builder、cacheExtent 和 itemExtentListView.builder是列表性能的地基但用好的关键是三个参数itemExtent或itemExtentBuilder每个 Item 的高度尽量固定。二手卡片的布局虽然信息多但主列表卡片的高度其实是相对固定的。显式声明itemExtent之后Flutter不再需要测量每个 Item 的高度来估计滚动范围布局计算量大幅下降。我们的卡片高度基本在 260~320 之间波动最后我干脆把图片区固定为 3:4 的比例整卡高度就锁死了。cacheExtent默认值是 250 像素表示屏幕外上下各预构建 250 像素范围内的 Item。这个值不是越大越好调大了确实可以减少快速滑动时的白屏概率但同时会增加存活的 Item 数量。我在低端设备上把cacheExtent从 250 降到 100内存占用减少了 16%帧率没有明显劣化。经验是先跑低端机如果滑动不出白屏cacheExtent 越小越好。addAutomaticKeepAlives与addRepaintBoundariesbuilder 默认会给每个 Item 包一层AutomaticKeepAlive和RepaintBoundary。对二手列表来说Item 状态不需要跨滚动保持离开屏幕就销毁所以我把addAutomaticKeepAlives设为 false让 Flutter 更激进地回收离屏 Item而addRepaintBoundaries保留为 true可以避免某个 Item 重绘时牵连整条列表。这套组合拳打下来最直接的收益是同屏存活的 Item 数量从原来的 14 个降到了 7~8 个内存和构建压力几乎减半。3.3 页面维度再加一道隔离首页只加载首屏别信加载更多有一个容易忽略的点列表页如果嵌在 Tab 里分类切换、首页推荐、关注列表三个 tab 三个列表不要一进页面就把三个列表的数据全部请求一遍。我见过太多 App 在这里做预加载然后崩了。合理的做法是哪个 tab 被选中哪个 tab 才发起首屏请求切换 tab 时页面销毁或者暂停。这样既保住了体验又不给低端设备叠加压力。Flutter 里可以用IndexedStack配合各列表页自己管理生命周期或者干脆用TabBarView的懒加载特性来实现。4. 第二刀图片解码和缓存改造二手列表最大的性能深坑如果说列表构建是基础问题那图片就是二手物品 App 列表性能的隐形杀手。为什么强调二手因为这类业务的商品图有几个特点用户随手拍的分辨率极高现在手机随便一拍就是 4000×3000画质参差没有统一规范的压缩流程一张商品往往有 4~9 张图列表页却只需要展示一张主图。结果就是服务端给的是 2MB 的原始大图列表却只画一个 200×260 的缩略图——带宽、内存、解码耗时全部浪费。4.1 干脆利落的方案服务端出图时先出缩略图最彻底的优化是在服务端做裁剪。我们在上传接口里除了原图还让服务端生成两种尺寸的图列表用的400x400缩略图体积控制在 50KB 左右和详情页用的1200x1200高清图。列表接口直接返回缩略图 URL点进详情才加载高清图。这一步做完列表网络流量直接降低了 80% 以上图片解码耗时从平均 34ms 降到了 8ms。这不是 Flutter 层面的优化而是整个数据链路的优化效果却比任何客户端缓存都明显。4.2 客户端解码双保险Image.network 的参数陷阱如果服务端暂时没法配合很多二手交易平台图床是现成的改不了客户端也要有兜底策略。Flutter 的Image.network有几个参数是专门为列表场景设计的但很多人从来不用cacheWidth/cacheHeight告诉 Flutter 在解码时直接缩放到指定尺寸。比如列表里图片显示宽度是 200 物理像素可以传cacheWidth: 600考虑 DPR 2~3 倍解码出来的位图远小于原图内存暴降。gaplessPlayback设为 true 之后图片换 URL 时不会闪白屏。loadingBuilder在加载完成前显示一个占位色块或骨架屏避免布局抖动。这仨参数属于不加白不加的优化我建议所有列表图片都写上。实测只加cacheWidth一项低端机的图片解码耗时又降了一半。4.3 全局 ImageCache 调优别让缓存列表变成内存炸弹Flutter 自带的PaintingBinding.instance.imageCache默认最多缓存 1000 张图片、100MB 内存。对列表页来说这个默认值太大了。二手 App 的用户滑动路径很长几百张缩略图快速滑过缓存存下大量早已离开屏幕的位图内存压力极高。我的调优做法PaintingBinding.instance.imageCache.maximumSize 300; // 最多缓存 300 张 PaintingBinding.instance.imageCache.maximumSizeBytes 60 * 1024 * 1024; // 60MB 上限同时在列表数据源变化比如切换分类时主动imageCache.clear()清掉旧分类的缓存。注意清缓存会导致回退时重新加载但考虑到闪退风险远比回退慢可怕这个取舍是划算的。4.4 并发解码控制与低端机降级网络图片框架我们用的 cached_network_image它的好处是自带磁盘缓存还能控制并发。但默认的并发数在低端机上依然会导致突然同时解码 8 张大图的尖峰。我做的降级策略是在列表滚动停止前只允许同时解码 2 张图片滚动停止后才逐渐补齐所有可见图片。这个逻辑实现起来不算复杂监听ScrollController滚动中设置一个_scrolling标志Image的loader里根据标志决定是立即加载还是延迟加载。实测下来快速滑动时帧率掉帧的峰值明显减少了 60%这是单靠图片尺寸优化做不到的。5. 第三刀从组件复用到滚动渲染把 Item 的构建成本摊薄前两刀把数量和体积控住了接下来要把单位 Item 的构建成本降下来。这是最需要工程耐心的地方收益是渐进式的但一旦累积起来效果立竿见影。5.1 拆 Widget不要在一个 build 里堆 90 个节点第一个问题是原来的 Item 是个 400 行的大 build 方法所有内容塞在一个方法里。问题在于Flutter 的 Widget 是不可变描述每次 rebuild整棵子树都要执行一次构造虽然只 diff 变化的部分但构造 90 个 Widget 实例本身就有成本。如果 Item 里的某个局部组件比如关注按钮触发了 setState整个卡片所有 Widget 都会被重新执行构造。解法是把这个大 build 拆成多个小 Widget并且用 const 构造_ItemImageSection只负责图片区关注图片加载状态_ItemInfoSection只负责文本信息接收一个ItemModel_ItemSellerSection只负责卖家信息行_ItemActionSection只负责价格、标签、操作按钮这些子组件各自独立且构造参数能加 const 的都加 const。这样局部刷新时没变化的子组件因为 const 标识Flutter 可以直接跳过 diff省掉整个子树的 build 调用。拆完以后单次 Item 的完整 build 耗时从 45ms 降到了 22ms列表卡片的瞬时构建成本降了一半。5.2 用 RepaintBoundary 卡住重绘边界拆完 Widget 还不够。即使拆成了子组件只要 Item 内部有动画或状态变化重绘范围仍可能扩大到整个列表。解决方案是给每个 Item 包上RepaintBoundary——上面提到 builder 默认已经包了一层但那是每个 Item 一层。更好的是在 Item 内部的局部区域比如图片区单独再包一层让图片加载完成的绘制只在图片区内重绘不牵连文本信息区。这个优化对滑动帧率的提升很微妙但有效尤其是在图片懒加载完成的瞬间如果没有 RepaintBoundary 隔绝整个列表都要重新走一遍合成卡顿的观感非常明显。5.3 Provider 分层让状态刷新不再牵一发动全身热词里出现了很多次flutter provider 怎么用这里顺便展开说下状态管理对列表性能的影响。我的列表页有多个实时可变的状态收藏状态、关注状态、当前分类、加载中状态。如果这些状态全放在页面级的一个大 Model 里任何一个小状态的改变都会触发页面级 notify导致所有 Item 重建。我的做法是按领域拆分 ProviderCategoryProvider分类页签状态FavoriteProvider收藏状态只影响单个 Item 的心形图标ListDataProvider列表数据与加载状态Item 内部只通过Provider.ofFavoriteProvider监听收藏相关变化页面级 Provider 的变化不会传导到 Item。注意Provider.of后面加上listen: false用于一次性读取避免不必要的订阅需要响应变化的地方才保留 listen。还有一个细节列表 Item 不要放进 Provider 的依赖树深层能用构造参数传数据就用构造参数传Provider 的粒度太粗会让性能问题从源头就藏住。5.4 滚动时的分帧渲染策略最后一个降本手段是分帧渲染。快速滑动时如果同时有多个新 Item 进入可视区每个 Item 都要做完整的构建布局绘制帧率自然撑不住。我的做法是把新 Item 的加载分帧处理用SchedulerBinding.instance.scheduleFrameCallback或者最简单的做法——在itemBuilder里对新进入可视区的 Item 先显示一个轻量骨架屏下一帧再渲染真实内容。这样一次滚动事件里每帧只处理 1~2 个 Item 的完整构建其余延后。实测滑动帧率在低端机上的最低点从 28fps 提升到 45fps体感完全不一样。这个策略的代价是实现复杂度增加了需要维护一个_pendingRenderItems队列但效果是真的值。6. OpenHarmony 平台上的适配细节同一个世界不同的坑理论上 Flutter 跨端是一致的但实际上每多一个平台就多一批平台特有的问题。OpenHarmony 的 Flutter 适配目前还没有达到 Android/iOS 那样久经考验的成熟度这一步我只讲真实遇到的坑。6.1 开发环境与工程的第一个坑首先OpenHarmony 的 Flutter 工程开发不能直接用标准的flutter create命令跑出目标产物得借助 OpenHarmony 社区维护的 Flutter SDK 分支配合 DevEco Studio 编译为 HAP 包。我第一次搭建的时候flutter doctor一切正常但编译时直接报错说找不到 OpenHarmony 的 target platform查了一圈发现是我本地 Flutter SDK 的版本和社区分支不匹配。这个适配分支更新比较快务必以 OpenHarmony SIG 的说明文档为准锁定版本。用错分支的话你后续每次编译都是噩梦。另外一个开发期体验差异是热重载。OpenHarmony 设备上热重载hot reload的稳定性不如 Android 模拟器有时候改了数据层代码hot reload 不生效要整体重启。刚开始很容易让人误判是代码问题实际是适配层的限制。6.2 Impeller 与渲染后端的真实表现热词里有flutter impeller这里就多聊一下Flutter 3.x 之后默认的渲染引擎逐步切换到 Impeller主打解决 Skia 在部分设备上的 shader 编译卡顿。但在 OpenHarmony 的适配分支上Impeller 的支持还不够完整某些设备上仍默认走 Skia 后端。这意味着你在 Android 上优化的渲染表现并不能直接套用到 OpenHarmony 设备上必须分别在目标设备上做帧率验证。实际测下来我们有一台 OpenHarmony 派的低内存平板设备同样的列表代码Android 手机上能稳 55fps在这台平板上只能到 30fps 左右。逐帧分析发现问题出在图片位图上传 GPU 的耗时上Skia 后端对位图格式的转换比 Impeller 慢。最后我们的解决方案是在 OpenHarmony 上检测到低内存设备时自动把列表图片的cacheWidth再降一档从 600 降到 400同时把列表 Item 图片区的圆角裁剪改由外层容器裁切减少 GPU 的 alpha 处理负担。帧率提上来了约 20%效果明显。6.3 字体渲染和中文字体的体积开销还有一个不算性能但很影响观感的问题OpenHarmony 设备上的默认字体和 Android 不同部分设备缺少中文字体如果工程里没有打包所需字体文字会变成方块或者回退效果很差。打包字体文件有两个选择一是打一个精简中文字体子集只包含常用 3500 字二是直接用系统字体并声明 fontFamily 回退链。前者体积大、加载快后者体积小、可能有渲染不一致。我们在列表场景选了后者固定行高减少文本布局的行高跳动。6.4 真机调试与 XTS 认证的注意点如果你的应用要跑在正式的 OpenHarmony 设备上绕不开 XTS 认证。列表性能优化在这个环节的直接影响是XTS 会跑大量自动化用例快速刷新列表、切换页面、反复进出详情页如果列表的内存回收不彻底长时间跑下来容易触发内存峰值告警。所以我在优化后期专门加了一个连续滑动 10 分钟反复进详情 100 次的压测用例。印象最深刻的是一次测试中详情页返回列表后图片缓存未被及时清理内存持续走高最终 OOM。排查后确认是详情页的图片没有把列表页的缓存策略覆盖到——两套图片加载逻辑不一致导致缓存翻倍。统一图片加载层全 App 共用同一套缓存和并发策略是后续所有优化能生效的前提。这件事优先级很高越早做越好。7. 优化后的真实数据与几条血泪经验最后汇总一下这一轮优化的重要数据和踩坑心得供后面做同类项目的人参考。7.1 优化效果对比我在同一台中端安卓机上用同一份数据做了优化前后的对比指标优化前优化后列表首屏加载耗时3.1s1.4s快速滑动帧率最低值28fps46fps平均帧率38fps54fps峰值内存占用286MB141MB同屏存活 Item 数147单 Item 首帧构建耗时45ms22ms这个数据不是专门制造出来的好看数字是在关了 debug 模式后跑 release 的真实数据。内存减半是我最看重的因为接下来还有 OpenHarmony 低内存设备的适配内存余量大了后面的工作才有空间挪腾。7.2 优化顺序的教训先数据链路再渲染细节如果重新做一遍这个项目我不会改变优化顺序数据分页 → 图片链路 → 组件拆分 → 平台适配。很多开发者喜欢一上来就拆 Widget、加 RepaintBoundary但这些都是抠细节如果数据层还是全量加载、图片还是原图解码抠掉的那点构建成本和一次图片解码的成本比起来微不足道。另外我还要强调一句性能优化不要想着一步到位。列表性能问题往往是多个小问题叠加的结果你改完一个参数可能帧率只提升了几帧但几个优化叠加起来量变就成质变了。过程中多用数据说话别凭感觉判断流畅了用一个标准的滑动轨迹测试脚本每次改动后跑 30 秒滑动记录帧率和内存变化这样每步优化到底有没有效心里才有底。7.3 最后的补充给团队预留的性能回归防线这次优化做完之后我更深刻的体会是性能问题从来不是一次性能解决的靠的是持续防回归。我们后来在 CI 里加了一个简单的性能测试 Job每天用固定的测试账号跑一遍主列表滑动采集帧率和内存数据超过阈值就报警。这条防线已经拦住了至少 3 次回归——都是新同事改代码时不小心把const构造删了或者又往 Item 里塞了非 const 的 Widget这类靠人工 review 很难发现的问题用自动化回归测试就能轻松兜住。再分享一个小的经验给列表 Item 的边界打上debugProfileBuildsEnabled标志在开发阶段可以清晰地看到 Item 的构建次数如果发现单个 Item 在滚动时被反复构建超过 10 次基本可以确认 KeepAlive 或者 cacheExtent 设置有问题。这个开关在正式版一定要关掉否则会带来额外性能开销。