企业官网建设流程全解析

上个月我们把一个跑在 Android 和 iOS 上的 Flutter 应用往 OpenHarmony 迁移，真正让我睡不着觉的，不是依赖冲突，也不是构建链问题，而是这个：一套代码，怎么在手机、折叠屏、平板、自由窗口里都长得像话？

这句话拆开就是标题里那串关键词——设备特征、响应式 UI、Flutter、OpenHarmony、智能布局。过去我们在移动端做适配，无非是 MediaQuery 拿个屏幕宽度，然后三两个断点分一下手机和平板。可一旦落到 OpenHarmony 这种强调窗口化、多形态、自由缩放的系统上，老办法立刻露馅。窗口可以像桌面应用一样随手拉大拉小，折叠屏展开以后宽高比完全变样，甚至同一个 App 在不同设备上要以完全不同的导航形态呈现。这不是简单的“等比缩放”能解决的。

这篇文章是我自己踩完坑之后的完整复盘，包含我在 OpenHarmony 上用 Flutter 搭建基于设备特征的响应式布局的全过程。你会看到我如何采集设备特征、如何设计断点、如何把根布局和组件级布局同时做“智能决策”，以及我在平台视图、状态保持、渲染引擎这几个最容易翻车的地方记录下来的问题清单。适合正在做 Flutter 跨端适配、或者刚接触 OpenHarmony 应用开发的人参考。

1. 为什么“设备特征”会成为布局的指挥棒

1.1 一个真实的迁移场景

先交代一下背景。我们原本的产品是一个偏工具类的应用，首页是信息流，二级页有复杂表单，还有一些地图和实时数据展示模块。在单块传统手机屏幕上，这套 UI 没有任何问题，底部导航栏、单列列表、窄表单，都是很成熟的设计。可迁移到 OpenHarmony 生态之后，目标设备一下子就发散得没边了：有 6 英寸左右的手机，有 10 英寸以上的平板，有展开后接近方形的折叠屏，还有带鼠标键盘的桌面模式。甚至同一个设备上，用户可以随时把一个全屏窗口拖成一个窄长条。

第一个版本我天真地以为，把根布局的宽度撑满，内容按比例放大，问题就解决了。结果在平板上跑起来，底部导航栏拉成一条横贯屏幕的宽条带，触控目标被拉伸得毫无章法；折叠屏展开后，单列信息流的行宽长到阅读视线要横扫整个屏幕，用户看一条卡片得扭头，这种体验根本没法交付。

我这才意识到，问题不是“尺寸变大了”，而是“布局结构已经不再成立”。在窄屏上合理的底部导航，在宽屏上应该变成侧边导航；在窄屏上合适的单列列表，在宽屏上应该变成多列网格；在触摸设备上好用的抽屉，在鼠标键盘环境下应该直接展开。这些变化不是缩放能解决的，而是需要根据设备特征重新决策——这就是我理解的智能布局的核心含义。

1.2 响应式 UI 到底在解决什么问题

很多人把响应式 UI 和自适应 UI 混为一谈，实际上两者有本质区别。自适应是“东西不动，尺寸变”，比如图片缩放、文字放大、间距压缩，它解决的是眼睛的舒适度。而响应式是“结构重组”，比如三栏变一栏、底部导航变侧边导航、表格变卡片，它解决的是交互的合理性。

拿网页举例最直观：同样的新闻网站，PC 浏览器上是左边目录、中间正文、右边推荐位的三栏布局，手机浏览器上则变成单栏上下滑动。这不是哪个浏览器把页面压缩了，而是页面代码检测到视口宽度变化之后，主动换了一套布局方案。Flutter 应用也是一样的道理，只不过我们要做的不是响应浏览器，而是响应设备。

在移动端传统环境中，设备特征相对稳定：屏幕大小基本固定，方向变化只有横竖两种，窗口几乎不会被用户随意缩放。所以过去我们只需要在少数几个固定断点做切换就够了。但 OpenHarmony 的变化维度更多、更动态。折叠屏展开折叠、自由窗口任意拖拽、外接显示器后切换桌面模式，这些都会导致同一台设备在几秒内呈现出完全不同的“视口特征”。布局代码不能再假设屏幕尺寸是一个常量，必须把设备特征当作输入，把布局形态当作输出，随时准备重组。

1.3 OpenHarmony 上跑 Flutter 的现状

先说实话，Flutter 官方并没有直接发布过支持 OpenHarmony 的正式版 SDK。目前社区和厂商生态里用的方案，主要是基于 OpenHarmony SIG 组织维护的 flutter_flutter 工程，配合对应版本的 Flutter Engine 适配产物。也就是说，你需要把 Flutter 工具链换成带 OpenHarmony 支持的分支，然后在 Android Studio 或者 DevEco Studio 里配置 OpenHarmony 的 SDK 路径，才能把 Flutter 工程构建到 OpenHarmony 设备上。

这个架构带来一个关键事实：你的 Flutter 界面本质上运行在一个 OpenHarmony 的原生容器之上，Flutter 引擎负责渲染 UI，而和系统能力打交道（窗口、原生控件、硬件接口）通常要经过一个桥接层。所以做设备特征采集的时候，有两个视角：Flutter 侧自己就能拿到的，比如逻辑分辨率、像素比、安全区；以及必须从 OpenHarmony 系统侧拿到的，比如窗口模式、折叠状态、输入方式。把两侧的数据汇聚到一处，形成统一设备画像，这是后面所有布局决策的基础。

也正因为 Flutter 在 OpenHarmony 上天然带有“跨端一致性”的优势，我们最终决定不引入第二套 ArkUI 页面，而是让 Flutter 承担全部 UI 层。代价就是，响应式布局的复杂度必须由我们在 Flutter 侧自己消化。

2. 设备特征采集：先搞清楚手里有什么牌

2.1 设备特征到底包含哪些维度

做智能布局，第一步不是写布局，而是定义“特征”。设备特征不是只有一个屏幕宽度，我实践中至少会分这几个维度：

1. 逻辑分辨率和宽高比。这是最基础的，决定断点判断。注意一定是逻辑分辨率，而不是物理像素，因为同样 1080p 的屏幕，在不同像素密度下对应的逻辑宽度差别很大。
2. 像素比（devicePixelRatio）。这个不直接参与布局结构决策，但是影响图片资源选取和线条粗细。像素比高的时候，同一个逻辑宽度里实际渲染的物理像素更多，纹理和字体的开销都不一样。
3. 安全区。OpenHarmony 设备上，挖孔屏、系统导航条、手势条都会占据一定的不可用区域。折叠屏展开后中间铰链区域还可能有一条显示禁区。安全区数据必须实时更新，否则布局会顶到不该顶的位置。
4. 窗口模式。这是 OpenHarmony 和传统手机最大的区别。设备可能处于全屏、分屏、自由窗口、悬浮窗等状态，窗口尺寸可以由用户任意调整。这意味着宽度会连续变化，断点可能被反复横跳，布局代码必须有“防抖”意识。
5. 折叠状态。折叠屏的展开和折叠不只是尺寸变化，还伴随着屏幕数量和使用场景的切换。展开后是平板形态，折叠后是手机形态，布局策略需要整体切换。
6. 输入方式。有触摸、鼠标、键盘、手写笔等。触摸环境要求点击目标至少 48dp，鼠标环境允许更紧凑的密度，键盘环境还需要考虑焦点管理。输入方式影响的是布局密度和交互形式。
7. 系统深浅色与字体缩放。严格说这不是设备特征而是系统偏好，但同样来自设备上下文，而且会影响布局容量的判断。字体缩放太大时，原本能放三列的卡片区域可能只能放两列。

如果你把这些字段零散地散落在各个页面去读，代码很快就会失控。我的做法是，不管特征从哪个 API 来，最终都收敛成一个统一的设备画像对象，叫做 DeviceProfile，布局层只认这个对象。

2.2 在 OpenHarmony 里拿到这些特征的正确姿势

Flutter 侧自带的能力已经能覆盖一部分。MediaQuery.of(context).size 可以拿到逻辑尺寸，MediaQuery.devicePixelRatioOf(context) 拿到像素比，MediaQuery.paddingOf(context) 拿到安全区。在较新的 Flutter 版本里，我建议用 MediaQueryData.fromView 或者直接挂在 View 上取，因为 Flutter 3 之后 MediaQuery 的窗口概念在向多窗口场景演进，从 View 维度取数据更贴合未来需求。

但这还不够。窗口模式、折叠状态这类信息，Flutter 侧拿不到，必须走 OpenHarmony 的系统接口。应用层一般通过 @ohos.window 模块获取窗口属性，比如 getLastWindow 拿到当前窗口对象，然后 getWindowProperties 获取窗口尺寸、是否全屏等信息。折叠状态通常要查系统能力接口或者监听特定事件。在这些场景里，你可能会接触到 HDI（Hardware Device Interface）的概念——往底层走，硬件能力的抽象都通过 HDI 提供，但应用开发几乎不会直接操作 HDI 这一层，而是用系统 API。我第一次接触 OpenHarmony 时也被 HDI 这个词吓到，后来头撞了南墙才发现，应用开发者根本不碰驱动接口，老老实实走系统窗口 API 就行。

拿到这些原生数据之后，通过 MethodChannel 或者 EventChannel 把数据传给 Flutter 侧。我的习惯是启动时主动拉一次全量数据，之后依靠事件订阅做增量更新。窗口尺寸变化、折叠状态切换、安全区变化，这些都应该注册监听，在回调里刷新 DeviceProfile。

这里有一个容易忽略的细节：Window 属性里的窗口尺寸包含不包含系统装饰，不同版本的表现可能不一样。我建议直接读取内容区域尺寸，而不是窗口总尺寸，否则布局会多算一条导航条的高度，导致底部内容被遮挡。这个问题在真机上调试时很容易暴露，但在模拟器上往往看不出来。

2.3 静态特征缓存与动态特征监听的取舍

不是所有特征都需要实时监听。实践里我把特征分成两类：静态特征和动态特征。

静态特征包括设备类型、像素比、系统版本、默认输入方式等，这些值在应用生命周期内几乎不变，启动时读取一次，放进内存缓存就行，不必每次布局都重新获取。你要是每个页面 build 里去调一次原生方法拿设备像素比，性能损耗不算大，但代码会显得很蠢，而且异步返回值与布局时机错位，反而可能引起闪动。

动态特征包括窗口尺寸、安全区、折叠状态、方向、字体缩放等，这些可能随时变化，必须监听。在 OpenHarmony 自由窗口场景下，窗口尺寸变化是高频事件，用户拖着窗口边缘调整大小时，可能一秒钟触发几十次回调。如果每次回调都直接 notifyListeners 并触发全局重建，界面会明显卡顿。

我的解决办法是：回调里先做一次粗判断，只有变化真正跨越了断点阈值、或者涉及布局结构切换时，才通知布局层重建。纯粹是宽度从 800 变到 812 这种没有越过断点的变化，记录下来即可，不触发 UI 刷新。后面我会在代码示例里展示这个逻辑。

3. 断点系统与容器感知：智能布局的决策框架

3.1 断点不是拍脑袋，设计前先看设备分布

很多教程里直接给出一组断点：手机 600、平板 840、桌面 1200，看起来标准，实际用起来并不是那么回事。断点的意义在于切分真实设备的布局需求区间，如果你的目标设备里根本没有 800dp 以下的平板，那 840 这个断点就是多余的。

我建议在定义断点之前，先把目标设备列表拉出来，统计每台设备的内容区域逻辑宽度。比如我们的目标环境里，手机大致在 360~430dp，折叠屏折叠态约 400dp、展开态约 700dp，平板约 800dp，桌面窗口常见 960~1280dp。基于这个分布，我把断点设计成三档：

这套分法不一定适合所有人，但它反映了目标真实分布，而不是空泛的最佳实践。断点设计的原则是：每个区间内的设备，布局方案应该基本一致；越过分界点后，交互形式应该有实质性的优化空间。如果两个区间采用相同的布局方案，说明这个断点是多余的。

另外，判断断点我基本只看内容宽度，不看高度。原因是宽度决定了行的容量，这是布局结构的核心约束；而高度只是纵向可用空间，对结构影响远小于宽度。在自由窗口场景下，高度主要影响是否要滚动、是否要折叠次要信息，不会改变导航形态。

3.2 从整页响应式走向组件级响应式

刚开始做响应式的时候，我习惯把断点判断放在页面根部，根据档位切换整页布局。这在 B 端页面里还可以，但放到信息流和工具型页面，问题就来了：页面内部那些自带布局逻辑的组件，并不会因为你整页切换成平板模式就自动表现良好。

举个例子，一个卡片网格组件，在整页宽度 1200dp 时被要求撑满，如果组件内部硬编码了三列，那它在 1200dp 和 600dp 下的表现会都很奇怪——前者列宽过大，后者列宽拥挤。整页布局是城市规划，组件级布局是每一栋楼对地块的适配，两者缺一不可。

所以在我们的组件体系里，凡是内部有“排列逻辑”的组件，都要具备对自己可用宽度的感知能力。Flutter 里最常用的工具就是 LayoutBuilder——它把父级施加的实际约束告诉你，你根据这个约束决定内部排列。网格列数可以用“可用宽度除以期望最小列宽”来算，这样组件被放在侧边栏、对开页、还是全屏页里，都能自己调整出舒适形态。

这个思路在 OpenHarmony 上尤其重要，因为窗口尺寸可以连续变化，整页断点只能给出粗粒度的结构切换，真正让页面“好看”的，还是组件级在连续宽度上的平滑表现。

3.3 设备特征如何驱动布局决策

设备特征和布局方案之间，不是一个简单的 switch-case。我的做法是建立一个两层决策模型。

第一层是全局决策。根据 DeviceProfile 里的断点、窗口模式、输入方式，决定应用的“骨架”：导航用底部还是侧边、主从视图是否同时展示、页面是否要留出内容边距、顶栏是否要隐藏。这些决策影响整个 App 的框架，所以必须在根节点完成。

第二层是局部决策。在每一个具体页面和组件内部，根据实际约束宽度，决定内容密度、列数、卡片形态。局部决策不一定看全局 DeviceProfile，更多是看 LayoutBuilder 给出的实际宽度，因为它更准确。一个 expanded 档位的设备，如果用户把窗口拖得很窄，全局骨架仍然是侧边导航，但某个页面里的网格列数必须跟着变少，这时候全局决策和局部决策要能各自独立工作。

为了避免每个组件都去读设备特征的原始字段，我会把特征先映射成更语义化的配置。比如把窗口模式映射成“是否允许多栏布局”，把输入方式映射成“目标点击尺寸”，把折叠状态映射成“内容边距策略”。这样布局代码读的是语义配置，而不是裸的原生特征值，测试和替换都方便很多。

4. 实操落地：写一个能跑的智能布局 Demo

4.1 工程初始化与 OpenHarmony 设备接入

先把工程跑起来。在 Android Studio 里创建 Flutter 工程时，默认设备列表里是看不到 OpenHarmony 设备的，需要先做两件事：下载 OpenHarmony SDK 并配置好本机路径，然后把 Flutter SDK 切换到支持 OpenHarmony 的适配分支。这个适配分支通常维护在 OpenHarmony SIG 的仓库里，对应 engine 产物也要单独准备，不能直接用 Google 官方渠道下载的二进制。我第一次就是没换引擎，构建成功了但设备上始终起不来，后来才意识到工具链不匹配。

壳工程的配置类似 HarmonyOS 应用工程，Flutter 的产物在壳工程里以模块形式被集成。简单理解，最终用户安装的是一个 OpenHarmony 应用包，Flutter 引擎在这个应用内部的容器里渲染界面。如果你要做 XTS 认证，最好一开始就把响应式布局的测试场景考虑进去，比如折叠屏展开折叠、分屏切换、窗口缩放场景下的功能完整性验证，别等适配完了才发现某些布局分支在测试设备上直接崩。

工程跑通之后，第一件事不是写业务，而是把设备特征采集的通道建立起来。我建议从第一天就用上 MethodChannel 和 EventChannel：MethodChannel 负责 Flutter 主动拉取原生数据，EventChannel 负责原生侧主动推送变化事件。后面加特征字段或者改监听逻辑，都在这两个通道上扩展，不用动业务代码。

4.2 核心实现：设备特征模型与监听逻辑

先把设备画像定义出来。我习惯用一个不可变的 DeviceProfile 类，所有特征字段都在里面：

enum Breakpoint { compact, // < 600dp medium, // 600 ~ 840dp expanded, // > 840dp } class DeviceProfile { final double width; final double height; final double devicePixelRatio; final double textScaleFactor; final EdgeInsets safeArea; final bool isWindowed; // 自由窗口模式 final bool isFoldExpanded; // 折叠屏展开状态 const DeviceProfile({ required this.width, required this.height, this.devicePixelRatio = 1.0, this.textScaleFactor = 1.0, this.safeArea = EdgeInsets.zero, this.isWindowed = false, this.isFoldExpanded = false, }); Breakpoint get breakpoint => Breakpoint.values.firstWhere( (bp) => width < bp.minWidth, orElse: () => Breakpoint.expanded, ); }

这里我加了点巧活：把断点范围和 breakpoint 判断直接写进 DeviceProfile，让特征模型自带决策能力。布局层拿到这个对象，直接读 breakpoint 字段就行，不必到处都是 width < 600 这样的裸判断。

监听逻辑要注意一件事：不要每收到一次尺寸变化就通知全局。我用一个 DeviceFeatureManager 管理状态，只在自己的对象里做断点跨越判断：

class DeviceFeatureManager extends ChangeNotifier { DeviceProfile _profile; DeviceProfile get profile => _profile; DeviceFeatureManager(this._profile); void update(DeviceProfile next) { final oldBreakpoint = _profile.breakpoint; final newBreakpoint = next.breakpoint; _profile = next; // 只有断点跨越或窗口形态变化才通知布局层 if (oldBreakpoint != newBreakpoint || next.isWindowed != _profile.isWindowed || next.isFoldExpanded != _profile.isFoldExpanded) { notifyListeners(); } } }

原生侧推送过来的窗口尺寸变化，先在这里更新 profile，再轻量判断要不要通知。这么做之后，用户拖窗口的时候，大多数回调都只是更新缓存值，只有真的越过断点了，界面才做一次结构切换，性能开销小很多。

4.3 从根布局到组件的响应式实现

根布局要做的，是根据 DeviceProfile 切换不同的导航骨架。我把骨架拆成两个壳组件：紧凑壳和宽屏壳。紧凑壳用底部导航，宽屏壳用侧边导航加内容区：

class RootScaffold extends StatelessWidget { final DeviceProfile profile; const RootScaffold({super.key, required this.profile}); @override Widget build(BuildContext context) { if (profile.breakpoint == Breakpoint.expanded) { return WideScaffold(profile: profile); } return CompactScaffold(profile: profile); } }

CompactScaffold 里是 Scaffold 加 BottomNavigationBar，WideScaffold 里是 Row 加 NavigationRail 加 Expanded 内容区。这个骨架切换就是智能布局的全局决策部分，它把宽度特征转化成导航形态。

但是这里埋着一个容易踩的坑：如果两部分返回的是不同的组件树，断点切换的时候，页面 State 会被重建。后面我会专门讲这个问题，先记住解法是：把页面的“状态存储”往上提，或者用 stable key 保持同一个组件实例。

页面内部的组件级布局，我用 LayoutBuilder 感知实际宽度，动态计算网格列数：

Widget buildCardGrid(BuildContext context) { return LayoutBuilder( builder: (context, constraints) { final columns = (constraints.maxWidth / 280).floor().clamp(1, 6); return GridView.builder( gridDelegate: SliverGridDelegateWithFixedCrossAxisCount( crossAxisCount: columns, mainAxisSpacing: 12, crossAxisSpacing: 12, ), itemBuilder: (context, index) => ItemCard(index: index), ); }, ); }

列数的计算逻辑是：期望每列至少 280dp 宽，用可用宽度除以它，向下取整，再限制在 1 到 6 列之间。这个式子看起来简单，但它让同一个卡片网格组件在手机、平板、桌面窗口里都能自适应，不需要任何上层断点参与。组件级响应式的好处就在这里：一个组件只对自己的约束负责。

4.4 嵌入原生视图：PlatformView 布局协同

不是所有内容都能用 Flutter 绘制。我们在 App 里嵌入了一个原生地图视图，还有一个实时摄像头的预览画面。在 OpenHarmony 上，这些原生控件通过 PlatformView 融入 Flutter 的布局树。

PlatformView 在智能布局里有个特殊矛盾：布局频繁切换时，原生视图的创建和销毁成本比 Flutter 普通控件高得多。我们一开始按普通 Widget 的写法，把 PlatformView 放在 AnimatedSwitcher 里做过渡动画，结果每次布局切换，原生视图都会被摘掉再重新创建，肉眼可见的黑屏闪烁，严重的还会让地图控件内部状态丢失。

后来改成更保守的策略：PlatformView 所在的容器不做结构切换，只做尺寸变化。用一个 Stack 把 PlatformView 固定在里面，上层用 Flutter 控件覆盖。宽度变化时，PlatformView 随容器一起放大缩小，但组件实例始终不销毁。这样牺牲了一点动画灵活性，换来了原生视图的稳定。

如果确实要根据断点切换 PlatformView 的形态，我建议至少把创建过程拆出来，复用已有的原生实例，而不是销毁重建。这个思路有点像是移动端 WebView 的复用池，只不过这里复用的是 PlatformView 的 controller。

5. 踩坑记录与排查清单

5.1 切换页面后状态丢失的真相

网上关于 Flutter 页面切换后状态丢失的讨论很多，我的结论是：Navigator push 出来的新页面不会丢状态，它还在页面栈里；真正丢状态的是你把组件从组件树上摘掉的情形。比如断点切换时，RootScaffold 从 CompactScaffold 换成 WideScaffold，如果这两个壳里用的是不同结构的子树，原来的页面 SizedBox 和组件实例会被销毁，State 里的数据全部消失。

这个坑在智能布局场景里几乎是必踩的。我们的首页是一个表单页，用户在窄屏下填了一半，旋转屏幕或者拖宽窗口进入宽屏布局，表单内容全部清空，用户直接疯掉。

解决办法有三个层次。最省事的是使用 IndexedStack，把所有断点对应的布局都放在 Stack 里，始终保持子树存活。代价是内存占用偏高。第二个办法是给跨断点保持的组件设置稳定的 ValueKey，让 Flutter 在组件树结构变化时尽量复用同一 State。第三个办法是把需要保持的状态提升到根节点之外，或者直接用状态管理库的全局 store。我会优先做第三个，因为它最干净。

5.2 PlatformView 与布局切换的冲突

PlatformView 黑屏、闪烁、手势错乱，这类问题占据了我们调试时间的很大比例。在 OpenHarmony 适配版本的 Flutter 上，PlatformView 的合成方式和 Android 不完全一样，有些在 Android 上正常的技术方案到这里就表现异常。

我记录到的典型表现有：切换断点后，PlatformView 区域变成黑块，必须重新进入页面才恢复；在 PlatformView 上做 Flutter 层动画时，原生控件出现明显的显示滞后；多个 PlatformView 同时存在时，手势只能命中某一个，其他都无法交互。

排查思路是三步：先确认是不是 PlatformView 本身的问题，把页面里所有 Flutter 动画和过渡效果去掉，只留原生视图，看是否还异常；再确认是不是布局切换的问题，手动在窄屏和宽屏之间切换，看黑屏是否发生；最后才是适配层的问题，去看 OpenHarmony 侧的合成参数。如果你和我一样是第一次接触这套环境，不建议一上来就去翻引擎层代码，先把 App 层的布局策略改保守，对比效果后再说。

5.3 渲染性能与 Impeller

Flutter 新版本默认启用 Impeller 渲染引擎之后，动画流畅度确实有提升，但 OpenHarmony 适配环境里并不总是按预期工作。我们遇到的情况是：启用 Impeller 后，某些带模糊和阴影效果的自定义组件在宽屏布局下出现渲染序列错乱，界面偶尔会闪一下，切回旧渲染引擎就正常了。

如果你也遇到类似的渲染异常，我的建议是做一个快速对照测试：把渲染引擎切到旧方案，看问题是否消失。尤其在做智能布局这种“大量结构切换 + 动画过渡”的场景，渲染引擎的稳定性比理论性能更重要。另外，布局切换动画不要做得太花哨，AnimatedSwitcher 可以缓和跳变，但频繁切换时动画叠加会放大渲染负担。我把断点切换的动画时长控制在 200 毫秒以内，而且只在跨越断点的瞬间触发。

还有一个容易被忽视的点：Future 的 then 回调放进微任务队列之后，执行时机比我们直觉上“下一步”要晚。如果你在一个 Future.then 里调用 setState 来切换布局，而这个 Future 的上下文已经因为断点切换而过期，可能会出现“旧的覆盖新的”这种诡异现象。我的做法是，异步回调回来之后先检查当前 profile 是否已变化，只有条件仍然成立时才更新界面。这个细节平时没事，但在快速调整窗口大小的场景里很容易踩中。

5.4 常见问题速查表

速查表只是结果，更关键的是形成排查习惯。我的经验是：遇到布局类问题，先截断视觉因素，把动画和过渡全关掉，再定位是结构问题还是渲染问题；遇到状态类问题，先确认是不是同一个 State 实例在存活，再谈数据同步。这个顺序能节省大量无效调试时间。

6. 几个值得沉淀的经验

智能布局做完之后，我最大的感触是：不要把响应式设计变成一场无休止的特例堆砌。设备特征再多，最终都要收敛成少数几个语义配置，布局代码只和语义配置打交道，否则你会在每一处分支里被原始特征淹没。

我现在的做法是，新写任何一个页面组件之前，先问三个问题：这个组件在 400dp 和 1200dp 下分别应该长什么样？中间是渐变过渡还是断点切换？如果窗口被拖得很窄，它会不会自己也跟着变窄而不是依赖全局壳来救？这三个问题想清楚之后，写出来的组件天然就是自适应的。

另一个经验是关于断点的：断点不是一个需要一次定死的数值，而是一个需要根据真实设备分布持续调整的策略。我们第一版断点定完之后，在真机上跑了一周，收集实际窗口尺寸，之后重新调了一次阈值。不要怕改断点，怕的是把断点写死在业务代码的各个角落，改一处漏一处。

最后说一个很多人忽略的点：设备特征采集本身不应该是业务逻辑的一部分。不要让页面代码直接去调 @ohos.window 的接口，不要让布局代码直接判断设备型号。把这些都收敛到 DeviceFeatureManager 和 DeviceProfile 这两层里，业务代码永远只面向 profile。这样以后接入新设备形态、新增断点、调整策略时，你改的只是一处配置，而不是整个项目的每个页面。这也是我这次实践中收益最大的架构决策。