【共创稿事节】从手机到 2in1：一个菜谱应用的三断点适配实录

一、为什么个人项目也要认真做适配个人开发者最容易把多设备适配当成大厂的事——反正用户主要在手机上。但 module.json5 里一行 deviceTypes 就决定了你的应用出现在哪些设备上写了三个设备却只按手机调布局等于自愿在平板和电脑上呈现半成品。而且鸿蒙的生态现实是折叠屏、平板、2in1 的用户重合度越来越高适配欠账迟早要还。健康菜谱助手的 module.json5 里声明了三种设备deviceTypes: [phone, tablet, 2in1]这一行的含义是应用包要能在手机、平板、2in1鸿蒙电脑形态上安装运行。声明的瞬间适配就从可选项变成了义务——2in1 上窗口可以自由拉伸平板上有分屏手机上有折叠屏展开态。这篇讲我怎么用一个不到 70 行的断点系统接住这三种形态以及哪些账到现在还没还完。二、断点系统本体70 行接住三种形态适配的核心是BreakpointSystem.etscommon/utils/ 下基于 ArkUI 的 mediaquery 能力staticregister(uiContext:UIContext):void{BreakpointSystem.unregister()constmediaQueryuiContext.getMediaQuery()BreakpointSystem.smListenermediaQuery.matchMediaSync((width600vp))BreakpointSystem.mdListenermediaQuery.matchMediaSync((600vpwidth840vp))BreakpointSystem.lgListenermediaQuery.matchMediaSync((840vpwidth))// ……change 回调里 AppStorage.setOrCreate(currentBreakpoint, bp)}三个设计决定各有理由单点分发。三个 listener 的 change 回调都只做一件事把断点写进 AppStorage 的currentBreakpoint。所有页面通过StorageLink(currentBreakpoint)订阅没有任何页面自己监听媒体查询。好处是断点逻辑只有一处坏处是所有页面都被一个字符串驱动——这是下文魔法数问题的根源。先注销再注册。register 开头先调 unregister逐个 off 掉旧 listener 再建新的。这行防御来自一个真实的担忧Entry 页面的 aboutToAppear 在热重载和窗口重建时可能被多次触发listener 泄漏会让 change 回调叠加执行。初始断点用 if 链兜底。listener 注册完后立刻探测一次当前态sm.matches → md.matches → 否则 lg保证首帧就有正确断点不依赖第一次窗口变化事件才收敛。三、四处消费点与一个魔法数问题页面侧的消费方式统一是 StorageLink 加 if 链。四个真实消费点Index.etsgetContentMaxWidth()lg→1180、md→960、sm→100000等于不限制HomePage.etsgetBannerHeight()lg→260、md→220、sm→Sizes.BANNER_HEIGHTCategoryPage网格列数和间距随断点变化ReadingPage朗读页排版宽度跑起来都正常但写专栏复盘的时候我盯着这四处 if 链看出了问题断点阈值 600/840 只存在于 BreakpointSystem 里而每个消费点的数值1180、960、260、220散落在各自的 if 链里。想新增一个 xl 断点或者把 840 调成 900要改 N 个文件漏一处就是某个页面在大屏上比例失调。最初做适配时只想着让平板不丑真正回头看才发现阈值和数值分家才是维护成本的开端。解法很朴素——断点决策收敛成一张常量表exportclassBreakpointPolicy{staticreadonlyCONTENT_MAX_WIDTH:Recordstring,number{sm:Number.MAX_SAFE_INTEGER,md:960,lg:1180}staticreadonlyBANNER_HEIGHT:Recordstring,number{sm:180,md:220,lg:260}}页面只读表不写分支。这个改造还没落地是我给自己排的下一步——专栏连载里也公开记了这笔账。四、两笔还没还的账诚实说当前 1.0.5 的适配是骨架完整、细节欠账。账一2in1 的自由窗口没有约束。module.json5 里没有配置 supportWindow 相关的窗口尺寸限制2in1 上用户可以把窗口拉到很扁——断点会掉回 sm内容宽度不限制banner 压到 180。能用但不好看。窗口最小尺寸约束是接下来要补的配置。账二折叠屏展开态只当大屏处理。当前实现里折叠屏展开就是 lg没有用 display 的折叠状态 APIfoldStatus做展开态专属布局。菜谱场景其实有明确的机会展开态是左边步骤、右边计时器的天然双栏场景。这是 1.0.6 的候选特性。两笔账的优先级我按用户感知频率排自由窗口约束影响所有 2in1 用户的每一次使用先还折叠屏双栏是增量体验后还。五、给同样要适配三种设备的你四条原则声明 deviceTypes 之前先想清楚适配范围——声明了就要负责少声明一个设备比多声明后适配烂更体面。断点阈值只允许存在一处消费点全部读表魔法数散落是适配烂掉的开始。mediaquery 手写方案和 GridRow/GridCol 声明式方案二选一即可页面少、断点行为独特如 banner 高度选手写网格类页面用 GridRow 更省。适配不是一次性的每个版本迭代把新页面是否处理了 md/lg加进发布检查清单——我的 release-notes 里已经有这一项。适配的尽头不是每个设备都好看而是用户换设备时体验不断手机上收藏的菜谱到平板上还在收藏夹里2in1 上拉窄窗口断点平滑降级回手机布局。做到这一步三种设备才真正是一个应用而不是三个移植版本。参考资料HarmonyOS 应用自适应布局开发指导断点ArkUI 媒体查询mediaquery文档工程源码BreakpointSystem.ets、Index.ets、HomePage.ets、CategoryPage.ets、ReadingPage.ets#鸿蒙 #HarmonyOS 7API 26