DevEco模拟器搭鸿蒙多设备适配验收台：600vp布局与档案存储

鸿蒙专家

没有真机时，多设备适配验收最容易变成口头提醒：手机看过、平板再看、折叠后再试。用 DevEco Studio 的 HarmonyOS 模拟器，可以先把检查项、状态和备注按设备档案固定下来，避免“哪台设备检查过、哪项还有问题”全靠记忆。需要说明的是，这套页面做的是模拟器里的界面检查，不是对真机兼容性的最终结论。

第一版只放四项每个页面都值得扫一眼的检查：顶部导航、统计卡片、验收列表、底部操作。每项状态为已通过、有问题、待验收，卡片顶部汇总三种数量。初始四项均为待验收，只是人工检查起点，不是程序验收结果。标题、说明、状态按钮都在同一张卡片内，不需要进入另一个表单。应用不会自动识别文本裁切或按钮命中区域，这些是检查提示，状态必须由操作人看过界面后手动填写。因此每条“已通过”代表一次人工检查，而非程序自评分。检查出问题时，备注会带当前档案名称和“验收记录已更新”提示；当前版本没有专门缺陷描述输入框，团队仍需把截图和复现过程放进自己的缺陷系统。第一版也不支持新增、删除或重命名检查项，目标是验证适配记录和布局，不是做通用项目管理系统。

当清单有了结果，重复扫全页效率低，因此增加“全部、已通过、有问题、待验收”四个筛选按钮。筛选只影响卡片列表，顶部统计仍按当前设备全部检查项计数。例如手机档案切到“有问题”时，列表只剩统计卡片一项，顶部仍显示 1 项通过、1 项有问题、2 项待验收。筛选只比较当前项状态，不改写记录；点回“全部”四条重新出现。这组筛选改变的是验收阅读顺序：先集中处理已知问题，修正界面后再切回对应档案复查。它没有缺陷编号、责任人和优先级字段，适合个人检查记录，不能替代团队缺陷跟踪。筛选状态只存在当前页面内存中，切换设备时重新看“全部”；验收记录则必须按设备区分。

顶部“手机、折叠屏、平板、2in1”是四个手动选择的验收档案，不是应用读取系统设备型号自动生成的分类。每个档案独立设置同一组检查项状态和备注，好处是简单，代价是操作人要记得先选对档案。底层用 Preferences 保存 JSON 字符串，四种档案使用不同键：

2. checks_phone

复制代码

、

2. checks_foldable

复制代码

、

2. checks_tablet

复制代码

、

2. checks_2in1

复制代码

。切换档案时页面异步读取对应内容，并增加递增序号，只接受最后一次切换请求的结果，避免连续点击时较早返回的数据覆盖当前选择。手机档案留下通过和问题记录后，切到折叠屏档案仍是 0 项通过、0 项有问题、4 项待验收；配合源码里的独立键，才能说明记录按档案隔离。手机档案修改后退出并重新打开应用，统计和状态仍保留：写入时调用 put 后再 flush，重启时从 Preferences 读回字符串并解析成检查项。这证明的是当前模拟器里普通退出和重启后的本地恢复；卸载、清除应用数据、备份迁移和跨设备同步不在本次验证范围。当前存储失败没有显示在页面上，save() 捕获异常后直接返回，调用侧不会回滚已更新的内存状态或提示用户。若用于真实验收，应让保存失败成为可见状态，避免操作人误以为记录已经落盘。

布局变化没有绑定某个产品型号。页面根容器通过 onAreaChange 读取宽度，判断条件为

2. newValue.width >= 600

复制代码

，达到 600vp 后把检查项排成两列，低于阈值改回单列。成对数据由 pairedItems() 组织，每张卡片宽度设为 48%，两列之间保留间距；最后只剩一项时，用空白占住另一列。Mate X7 模拟器合上时保持单列，检查项说明可换行，能看到窄宽度下文字和按钮是否互相挤压；顶部、统计、筛选和卡片仍沿同一列向下排，交互顺序没有因屏幕变窄而改变。展开后根容器宽度越过阈值，卡片变成两列。这里变化的是窗口宽度触发的响应式布局；程序没有读取折叠角度、姿态或铰链区域，也没有实现跨铰链避让，所以它只能称为折叠前后宽度变化检查，不是完整折叠屏适配方案。平板模拟器同样呈现两列，卡片没有被横向拉成很长的文本区域；手机上的页面顺序没有改，只是每行多放一张卡片。2in1 模拟器运行在桌面窗口里，应用有系统标题栏，卡片同样两列；拖动窗口时列数会按宽度阈值重新切换。当前代码没有增加桌面专用导航、鼠标悬停状态或键盘操作，检查项按钮仍是触控风格，因此只能说明当前清单在宽窗口中可浏览和点击，不能替代完整桌面交互验收。

工程入口和关键布局逻辑在 Index.ets：状态按钮修改检查项，筛选计算可见列表，宽度变化决定单列或双列；切换点是当前根容器的 600vp，而不是某个固定型号名称。AdaptStore.ets 负责初始化 Preferences、按档案键读写 JSON，并在状态改变后刷新本地数据。把应用放到 DevEco Studio 的 Mate 90 Pro 模拟器目标运行，模拟器页面和工程入口可以互相对应，但检查结果仍来自各形态模拟器里的操作。本次完成的内容包括检查项状态切换、状态统计、问题筛选、按档案保存、重启恢复，以及折叠屏模拟器合上和展开、平板与 2in1 模拟器上的窗口宽度布局。没有验证真机触控手感、不同厂商窗口行为、折叠姿态 API、跨铰链布局、长列表性能或数据同步。下一次真机验收时，应先把四个档案当作检查清单使用，再按真实问题调整检查项，而不是先把设备兼容性说满。

热心网友2

这套思路挺实在，把“哪台设备检查过、哪项还有问题”从口头提醒变成按档案固定的清单，尤其适合没有真机时先做界面层面的自查。筛选只影响列表、统计仍按当前档案全量计数，以及切换档案时用递增序号只接受最后一次结果，这些细节考虑得比较到位；按手机、折叠屏、平板、2in1 分键保存也能说明记录是按档案隔离的。需要留意的是，保存失败目前没有页面提示，真用于验收时容易让人误以为已经落盘，建议至少让失败状态可见；另外 600vp 两列和折叠前后宽度变化只是响应式布局检查，不能当成完整折叠屏或桌面交互验收，截图和复现过程还是得进缺陷系统。整体作为模拟器验收台的第一版，目标边界写得清楚，后续真机验收时按这四个档案逐项过一遍会比较顺。

热心网友2

楼主这套思路挺实在，尤其是把“模拟器检查”和“真机兼容性结论”分开说清楚，这点很重要。四项检查、手动状态、筛选只影响列表、按设备档案用不同 Preferences 键隔离记录，整个验收闭环已经比较清晰了，600vp 宽度阈值做单双列也能覆盖折叠前后和平板、2in1 的初步布局观察。 我觉得可以继续打磨两点：一是保存失败目前静默返回，真拿来做验收记录时最好让操作人看到失败提示，避免误以为已经落盘；二是筛选状态只存在当前页面内存里没问题，但切换档案后回到“全部”这个行为可以在界面上稍微提示一下，减少误判。另外楼主自己也点明了折叠屏只验证宽度变化，不是完整铰链适配，这个边界保留得很好。下次真机验收前先把四个档案当检查清单用，再根据实际问题增删检查项，会比一开始追求通用系统更稳。

热心网友2

这套验收台思路很实在，把“哪台设备查过什么”从口头提醒变成按档案落下来的检查记录，边界也交代得清楚：状态必须人工填写，筛选只改变阅读顺序，600vp 只管窗口宽度变化，不等同真机兼容性、完整折叠屏适配或桌面交互验收。 Preferences 用四个独立键按档案隔离，切换时用递增序号只接受最后一次请求，这个细节对连续点击很有用。后续真要进团队流程，建议优先把保存失败做成页面可见状态，并和截图、复现过程进缺陷系统的动作接起来；第一版不做检查项增删改也合理，先把记录隔离和布局验证跑顺更重要。