鸿蒙多端适配全链路：从断点栅格到har/hsp工程拆分

做大屏平板适配的时候，有人跟我抱怨：鸿蒙的多端适配不就是把UI扯一扯，手机能跑，平板不就自动放大吗？我直接给他看了个惨案——折叠屏展开后控件挤成一团，车机上按钮间距太小根本没法点，手表上文字超出屏幕滚成横向。真要做好多端适配，从来不是“一套布局走天下”，而是要把每个设备的用户场景、交互习惯、系统能力都考虑进去，再借助ArkUI和Stage模型的能力把差异吞掉。

这篇文章就聊聊我这段时间做鸿蒙原生App多端适配的完整思路，从场景拆解、UI适配、能力探测、数据协同，到工程模块划分、测试发布，一套全链路的东西。既有方案选型的理由，也有可以直接抄的代码和配置，还有我踩过的坑。适合正在做鸿蒙应用、准备适配平板/折叠屏/车机/手表，或者想把har/hsp工程结构理清楚的朋友。

1. 多端适配的核心逻辑：先想场景，再谈像素

1.1 适配的本质是“场景适配”，不是屏幕适配

很多团队第一次接触鸿蒙多端，第一反应是“做自适应布局”，把vp单位、百分比、栅格搞一搞，然后就能收工了。但实际上，同一款App在手机和平板上，用户的诉求很可能根本不一样。手机是碎片时间、单手操作、快速浏览；平板是沉浸阅读、分屏办公、多点触控；车机上用户注意力被驾驶占用，大字体、大按钮、极简交互才是刚需；手表上信息密度低，核心是“看一眼就能反馈”。

所以我把适配拆成三个层次：

• 第一层是UI层的适配，让布局在不同尺寸和形态下不塌、不挤、不重叠；
• 第二层是交互与能力层的适配，判断设备有没有某个传感器、有没有多窗口、支持不支持某种手势，再决定功能入口和交互方式；
• 第三层是数据与业务层的适配，比如多端登录状态同步、分布式数据落盘、账号信息在多设备间的连续性。

只有把这三层全部打通，才叫真正的全链路落地。只看UI、只调像素，到了真机测试一定会被现实打脸。

1.2 为什么鸿蒙的ArkUI天然适合做这件事

刚开始我也纠结过，要不要直接用if判断屏幕宽度来做适配？后来发现ArkUI提供了比传统Android res目录、iOS size classes更顺手的一套响应式机制，配合Stage模型的多module工程，简直是为多端而生。

ArkUI里做多端适配，核心武器就是这几个：断点（Breakpoint）、栅格（GridRow/GridCol）、媒体查询（MediaQuery），还有vp/fp单位、自适应撑开组件。断点负责把屏幕分成几档，栅格负责把内容按12列拆分，媒体查询负责特定的宽高、方向、圆角等条件。这些机制组合起来，就能做到“代码一套，布局多端”。

再配合Stage模型中har、hsp、hap的拆分，可以做到“通用能力下沉，业务模块按需引用”。所以我最终的方案是：

• 使用har承载公共UI组件、工具库、常量定义；
• 使用hsp承载动态共享的模块（比如需要按需加载的业务页面）；
• 使用hap承载不同入口应用和独立场景包。

这种工程结构不仅让多端适配更清爽，也顺带解决了包体积和编译效率的问题。

2. 设备形态差异与场景化适配策略

2.1 四大类设备，交互范式完全不同

我把自己做过的设备分成四类，每个类别对应一套“用户心智”和“交互约束”。下面这个表是我在方案评审时经常用的，建议你直接截图保存：