折叠屏适配最容易出问题的地方，不是页面能不能铺满屏幕，而是窗口变化以后状态还能不能保住。用户从外屏切到内屏，或者在平板、鸿蒙电脑窗口里拖动宽度，页面结构可能从单栏变成双栏。如果列表选中项、滚动位置、详情页参数都丢了，体验会很差。
这篇按 HarmonyOS 7 / API 26 的多设备适配思路来拆：先把窗口宽度转成断点，再把单双栏结构和业务状态分开，最后用两条可复现路径验证。
先定义断点，不要到处写魔法数字
我一般会先把窗口宽度分成三档：compact、medium、expanded。
| 断点 | 典型场景 | 页面结构 |
| compact | 手机竖屏、折叠屏外屏 | 单栏列表，详情新页打开 |
| medium | 折叠屏半展开、小平板 | 列表加轻量详情预览 |
| expanded | 平板横屏、鸿蒙电脑窗口 | 左列表右详情双栏 |
断点判断单独封装，后面页面只消费结果。
~~~ts
type WindowBreakpoint = 'compact' | 'medium' | 'expanded'
function getBreakpoint(widthVp: number): WindowBreakpoint {
if (widthVp < 600) {
return 'compact'
}
if (widthVp < 840) {
return 'medium'
}
return 'expanded'
}
~~~
这样做的好处是清楚。后面产品说 840 这个点要调整，也只改一个地方。
页面状态不要绑死在布局里
问题写法通常是：单栏页面有一套状态，双栏页面又有一套状态。窗口一变，组件重建，状态跟着丢。
~~~ts
type RecipeListState = {
selectedId?: string
scrollIndex: number
keyword: string
}
class RecipeStateStore {
private state: RecipeListState = {
selectedId: undefined,
scrollIndex: 0,
keyword: ''
}
snapshot(): RecipeListState {
return { ...this.state }
}
update(next: Partial<RecipeListState>): void {
this.state = { ...this.state, ...next }
}
}
~~~
这个 store 不关心当前是单栏还是双栏，它只保存“用户在看什么”。布局切换时，页面从这里恢复。
案例一：外屏单栏切到内屏双栏
单栏时用户点列表进入详情；展开后应该变成左列表右详情，而且仍然选中刚才那条。
~~~ts
class AdaptiveRecipePage {
private store = new RecipeStateStore()
private breakpoint: WindowBreakpoint = 'compact'
onWindowSizeChange(widthVp: number): void {
const next = getBreakpoint(widthVp)
if (next === this.breakpoint) {
return
}
const snapshot = this.store.snapshot()
this.breakpoint = next
this.renderByBreakpoint(snapshot)
}
selectRecipe(id: string): void {
this.store.update({ selectedId: id })
const snapshot = this.store.snapshot()
this.renderByBreakpoint(snapshot)
}
private renderByBreakpoint(state: RecipeListState): void {
if (this.breakpoint === 'compact') {
renderSingleColumn(state.selectedId)
return
}
renderTwoColumn(state.selectedId)
}
}
~~~
这里的关键是：窗口变化只改变布局，不重置 selectedId。状态和布局分开以后，单双栏切换就不会把用户当前选择冲掉。
案例二：拖动窗口宽度后滚动位置丢失
平板或鸿蒙电脑窗口拖动宽度时，列表可能重排。如果滚动位置没有单独保存，页面会跳回顶部。
~~~ts
class ListScrollKeeper {
private lastIndex = 0
onScroll(index: number): void {
this.lastIndex = index
}
restore(): number {
return this.lastIndex
}
}
class AdaptiveListController {
private scrollKeeper = new ListScrollKeeper()
onVisibleAreaChange(firstVisibleIndex: number): void {
this.scrollKeeper.onScroll(firstVisibleIndex)
}
onLayoutRebuild(): void {
const index = this.scrollKeeper.restore()
scrollToIndex(index)
}
}
~~~
滚动位置不一定要保存像素值。很多列表在数据稳定时，保存 firstVisibleIndex 更实用，适配重排后也更容易恢复。
断点切换要有日志
适配问题如果没有日志，很难知道到底是窗口事件没触发，还是触发后状态没恢复。
~~~ts
type BreakpointTrace = {
oldValue: WindowBreakpoint
newValue: WindowBreakpoint
widthVp: number
selectedId?: string
scrollIndex: number
}
function printBreakpointTrace(trace: BreakpointTrace): void {
console.info(
'[breakpoint]',
trace.oldValue + '->' + trace.newValue,
'width=' + trace.widthVp,
'selected=' + (trace.selectedId ?? 'none'),
'scroll=' + trace.scrollIndex
)
}
~~~
每次窗口变化都输出一次，回归时能直接看出状态是否被保住。
本地验证脚本
先不接真实 UI，也可以验证状态逻辑。
~~~ts
function verifyFoldableState(): void {
const store = new RecipeStateStore()
store.update({ selectedId: 'recipe-12', scrollIndex: 40, keyword: 'noodle' })
const compact = getBreakpoint(390)
const expanded = getBreakpoint(900)
const snapshot = store.snapshot()
console.info('[verify-breakpoint]', compact, expanded)
console.info('[verify-state]', snapshot.selectedId, snapshot.scrollIndex, snapshot.keyword)
}
~~~
预期结果是断点从 compact 到 expanded，但 selectedId、scrollIndex、keyword 都不丢。
方案对比
| 方案 | 好处 | 问题 |
| 布局里直接放状态 | 写起来快 | 窗口一变容易丢状态 |
| 全局 store 保存所有状态 | 恢复方便 | 容易过度设计 |
| 页面级状态仓库 | 状态清楚，适配成本低 | 需要维护快照和恢复入口 |
我更推荐页面级状态仓库。它比把状态散在组件里稳，也比把所有东西塞进全局 store 更轻。
回归检查
| 场景 | 操作 | 通过标准 |
| 外屏到内屏 | 选中一条后展开 | 双栏仍显示同一条详情 |
| 拖动窗口 | 列表滚动到中间再改宽度 | 滚动位置不回到顶部 |
| 搜索后切换 | 输入关键词再切断点 | 关键词和筛选结果保留 |
| 详情返回 | 双栏切回单栏后返回 | 路由不乱跳，不重复打开详情 |
小结
HarmonyOS 7 / API 26 做折叠屏和多窗口适配，重点不是把页面拉宽，而是窗口变化以后状态不丢。把断点判断、页面状态、滚动恢复和日志分开，单双栏切换就会稳定很多。后面再遇到折叠屏适配问题，也能直接从断点、状态、滚动三个位置排查。