# HarmonyOS 组件冻结怎么用才稳多页签长列表、统计刷新和唤醒边界怎么拆ArkUI 页面越做越复杂以后最容易被忽略的不是某个 for 循环慢而是页面上很多组件明明没有被用户看到却还在跟着状态一起刷新。列表、图表、统计面板、二级页签堆在一起时一个小状态变化可能把一大片 UI 都带着重算滑动时就会出现掉帧、白块或者按钮响应慢。自定义组件冻结解决的就是这类问题组件暂时不需要参与界面刷新时把它冻住等用户真正切回来或者数据到了必须刷新时再把它唤醒。这个能力适合放在性能优化文章里讲因为它不是一个装饰接口而是用来减少无效刷新、控制状态传播范围的。这篇按排查思路拆问题怎么发生怎么复现哪些地方不能直接冻结怎么选择冻结边界最后怎么封装成可以复用的写法。## 先看问题页面没显示为什么还在刷新先做一个很常见的页面上面是 Tabs下面每个页签里都是长列表。第一个页签显示菜谱列表第二个页签显示收藏第三个页签显示统计。用户停在第一个页签时后两个页签其实看不见。如果把状态都放在父页面里再把同一个统计对象传给每个子组件就会出现一个问题只要收藏数量、筛选条件、加载状态发生变化几个页签里的组件都会收到状态变动。即使当前只显示第一个页签隐藏页签也可能继续参与构建、计算和刷新。小页面看不出来大页面就明显了- 切换页签时有一瞬间卡顿- 长列表滚动时偶尔掉帧- 统计面板没打开里面的计算却一直在跑- 某个状态只影响当前页却把兄弟页签也带着刷新。这个时候不要先急着怀疑列表组件。更应该先问一句当前状态变化到底需要刷新哪些组件哪些组件只是被顺手带上了## 复现场景一隐藏页签被无意义刷新下面这个例子故意写得比较直接。父页面维护 selectedIndex 和 stats三个页签都能拿到 stats。每次列表里点击收藏stats.favoriteCount 增加。问题是统计页签虽然没展示也会因为 stats 变化被带着刷新。代码结构可以先这么看Observedclass PageStats {favoriteCount: number 0;viewedCount: number 0;updatedAt: number Date.now();}Componentstruct RecipeTabPage {State selectedIndex: number 0;State stats: PageStats new PageStats();build() {Column() {Tabs({ index: this.selectedIndex }) {TabContent() { RecipeList({ stats: this.stats }) }.tabBar(菜谱)TabContent() { FavoriteList({ stats: this.stats }) }.tabBar(收藏)TabContent() { StatsPanel({ stats: this.stats }) }.tabBar(统计)}.onChange((index: number) { this.selectedIndex index; })}}}这段代码功能没错但性能边界不清楚。RecipeList 改了收藏数StatsPanel 立刻响应FavoriteList 可能也跟着响应。用户没有打开这些页签时这些响应大部分就是无效刷新。组件冻结适合放在这里不是冻结整页也不是冻结数据而是冻结“当前不可见、暂时不需要响应 UI 刷新”的子组件。可以先包一层 FreezeTabContentComponentstruct FreezeTabContent {Prop active: boolean;BuilderParam content: () void;build() {Column() {this.content()}.freeze(!this.active)}}使用时把每个页签包进去TabContent() {FreezeTabContent({ active: this.selectedIndex 0 }) {RecipeList({ stats: this.stats })}}.tabBar(菜谱)TabContent() {FreezeTabContent({ active: this.selectedIndex 1 }) {FavoriteList({ stats: this.stats })}}.tabBar(收藏)这里的重点不是把代码变花而是把刷新边界说清楚当前页签 active就允许刷新非当前页签 inactive就先冻结别让它跟着每次状态变化一起跑。## 复现场景二统计面板计算太重切回来又要保持结果正确第二个问题更容易踩坑统计面板不是普通文本它可能要做分组、排序、TopN、空状态判断还要显示最近更新时间。如果冻结之后直接不管用户切回统计页时看到旧数据就变成另一个问题。所以冻结不是“永远不刷新”而是“不可见时少刷新可见时补一次正确刷新”。这个边界要写在代码里。Observedclass StatsSnapshot {total: number 0;favorite: number 0;topCategory: string ;version: number 0;}Componentstruct StatsPanel {ObjectLink snapshot: StatsSnapshot;Prop active: boolean;State localVersion: number -1;State displayText: string ;aboutToAppear() {this.syncIfNeeded();}private syncIfNeeded() {if (this.localVersion this.snapshot.version) {return;}this.localVersion this.snapshot.version;this.displayText 共 this.snapshot.total 条收藏 this.snapshot.favorite 条最多分类 this.snapshot.topCategory;}build() {Column({ space: 8 }) {Text(this.displayText)Text(版本 this.localVersion)}.freeze(!this.active).onVisibleAreaChange([0.0, 1.0], (_: boolean, ratio: number) {if (ratio 0) {this.syncIfNeeded();}})}}这个例子里有三个保护点用 active 控制冻结不让隐藏组件一直刷新用 version 判断统计快照是否真的变化组件重新可见时补一次 sync避免切回来看到旧结果。## 几种方案怎么选第一种是不做冻结只做拆组件。这个方案最简单适合页面很小、状态很少的场景。缺点也明显当页面继续长大状态传播范围还是会越来越乱。第二种是把所有状态拆到各个子组件里。它能减少父组件刷新但会带来同步问题。比如统计页需要知道列表和收藏页的变化状态拆得太碎以后反而要写很多事件和回调。第三种是保留清晰的数据源但把不可见组件冻结起来。这个方案更适合多页签、多列表、多统计面板的页面。数据仍然从一个地方来UI 刷新边界单独控制。我的选择一般是数据边界先理清冻结只管 UI 刷新边界。不要把冻结当成状态管理方案它是性能优化手段不是数据一致性方案。## 可以封装成什么如果项目里有很多 Tabs、Swiper、Navigation 子页面可以封装一个统一的 FreezeBoundary。Componentexport struct FreezeBoundary {Prop active: boolean;Prop name: string ;BuilderParam content: () void;build() {Column() {this.content()}.freeze(!this.active)}}使用时只关心当前页面是否活跃。这样以后排查性能时也更清楚先看状态是不是拆对再看 FreezeBoundary 的 active 是否准确最后看组件重新可见时有没有补同步。## 验证时不要只看能不能跑组件冻结看起来像一个简单开关但验证不能只看页面有没有报错。我会至少看四件事当前页签操作时隐藏页签不要频繁刷新切回隐藏页签时展示的数据必须是最新的快速切换页签时不要出现旧状态闪一下再更新长列表滑动时冻结前后的掉帧和白块情况要对比。如果项目里接了性能分析工具还可以对比状态变化时的组件刷新次数。没有工具时也可以先用日志记录组件 build 次数确认隐藏组件没有被无意义唤醒。## 最后总结一下组件冻结适合解决“不可见组件被状态变化拖着刷新”的问题。它真正有价值的地方不是少写几行代码而是让页面刷新边界变得可控。我会按这个顺序处理先拆清楚数据源再找出当前不可见但还在刷新的组件然后用 active 做冻结边界最后在组件重新可见时补一次同步。这样写出来的页面不只是跑得动也更容易解释为什么快、为什么不会丢状态。