Impeccable 原生设计适配实战：用 iOS / Android 平台惯例重构体验而非缩放像素

Impeccable 原生设计适配实战用 iOS / Android 平台惯例重构体验而非缩放像素【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable关联文档plugin/skills/impeccable/reference/adapt.native.mdImpeccable 的adapt命令面向把一个既有设计迁移到新上下文这一高频场景设备类别变了、方向变了、平台换了、或源头是网站。本文聚焦其原生分支adapt.native.md——它专门处理ios/android/adaptive三类原生项目的适配工作核心信条只有一句话适配是重新思考体验不是缩放像素。读完本文你将掌握从评估适配挑战到分场景制定策略再到用尺寸类驱动结构、尊重安全区、双端验证的完整可执行方法并能借助仓库中配套的平台参考与验证命令把跨设备、跨平台、Web 转原生的适配做到在每种上下文里都显得天生长在那里。一、这个文档在 Impeccable 技能体系中的位置Impeccable 是一个面向 AI 设计工作流也即其项目描述所言 The design language that makes your AI harness better at design的技能包。在 SKILL.md 的 Commands 表中adapt [target]属于Fix修复类命令其官方定义为Adapt for different devices and screen sizes且明确标注了路由规则native:reference/adapt.native.md也就是说当目标平台是ios/android/adaptive时adapt命令会路由到原生参考文档Web含移动端 Web则走 adapt.md。原生变体开篇即声明在制定方案前必须阅读目标平台的参考文档——即 ios.md 或 android.md——除非 Setup 阶段已经加载过。平台判定来自 init.md 中记录的PRODUCT.md平台假设web、ios、android或adaptive一个真正按操作系统自适应设计语言的产品。注意其明确边界移动端 Web 仍属于web套壳网站的原生包装并不会让它的设计语言变成原生。当平台是ios/android/adaptive时init 会自行加载对应平台参考adaptive则需同时加载两者。二、第一步评估适配挑战Assess Adaptation Challenge动手前必须先回答三个问题任何跳过这一步的适配都会退化成机械放大源上下文Source context这个设计当初为谁而做它做了哪些隐含假设——仅手机仅竖屏只遵循某一平台的惯用表达它本质上是一个网站目标上下文Target context目标设备类别是什么手机、平板、折叠屏方向如何平台是什么使用姿态是什么——单手赶路场景还是双手放松使用场景什么会坏What breaks哪些导航在目标设备上放不下哪些布局被拉伸而不是被重构哪些手势或控件在目标平台上根本不存在这组问题与 adapt.md 中 Web 版的源上下文 / 目标上下文 / 适配挑战三问同构但原生版把考察重心放在设备类别、方向、平台惯用语上——因为原生平台的适配难点从来不是 CSS 断点而是交互范式与系统约束的迁移。三、四大适配策略Adaptation Strategies3.1 手机 → 平板iPad / 大屏平板适配的第一戒律是重构不要拉伸Restructure, dont stretch。把手机 UI 等比放大铺在平板上是适配失败的标准形态。正确做法是用尺寸类iOS 的 size classes或窗口尺寸类Android 的 window size classes来切换整体结构而不是依赖设备型号判断。导航改变形态iPhone 的 Tab bar 在 iPad 上保留或演化为侧边栏Android 的导航栏navigation bar在加宽宽度上变成导航 rail侧栏或 drawer抽屉。用足宽度采用 split view / master-detail列表 详情并排、多列网格手机上用 sheet 的地方平板上改用 popover。多任务是一个尺寸不是边界情况iPad Split View 和 Android 多窗口会把平板塞成手机宽度的窗口而尺寸类驱动的布局会免费同时处理好这两者。与之对应的底层约束来自 ios.mdTab bar for 2–5 top-level sections承载区段而非动作……无自定义全局导航无混合隐喻和 android.md导航栏底部3–5 个目的地用于紧凑宽度扩展宽度用导航 rail 或 drawer。绝不要把手机底部栏原样搬上平板。3.2 方向与折叠屏Orientation foldables横屏要做结构重构并排窗格、重新定位控件绝不裁剪或加黑边letterbox只有当任务真正需要时才锁定方向。折叠屏Android通过窗口尺寸类响应姿态与铰链必须在折叠、展开、桌面式tabletop三种状态都测试。3.3 平台 → 平台iOS ↔ Android核心方法论是翻译惯用语绝不移植惯用语Translate idioms; never transplant them。文档给出了一张关键对照表这是跨平台适配最直接的落地清单iOSAndroidTab barNavigation bar / rail / drawer边缘滑动返回、返回箭头预测性返回手势Predictive Back/ 返回按钮Switch、分段控件segmented control、系统选择器Material switch、chips、Material 选择器Action sheetBottom sheet / Material dialogSF Symbols、SF Pro、Dynamic TypeMaterial Symbols、Roboto、sp 缩放语义系统色、材质materialsMaterial color roles、tonal elevation系统 push/sheet 转场Container transform、shared-axis、fade-through实施要点用目标平台的词汇表重建导航与控件同时把品牌的表达层palette intent 调色板意图、type accent 字体强调、motion personality 动效个性通过目标平台的主题系统带过去。这与两端平台参考的slop test劣质感测试相呼应——ios.md 称之为从网站移植过来的迹象自定义导航栏、自定义返回手势、Web 形状按钮、依赖 hover 的交互android.md 则点名穿着 Android 皮肤的 iOS 应用照搬 iPhone 的底部导航、无视系统返回手势的返回箭头、Cupertino 形状的开关和对话框是 Android 最常见的 slop。3.4 Web → 原生移植网站或 Web 应用重新符合规范而不是重新流动Reconform, dont reflow用平台自身的导航模型替换 Web 导航用平台控件替换 HTML 形状的控件用触摸优先的交互替换 hover 类提示用Dynamic Type / sp替换 px 字号。完成后把结果整体过一遍完整的平台参考该平台的 slop test 就是验收标准。四、实施与验证Implement Verify4.1 结构由尺寸类驱动绝不由设备型号驱动文档的硬性要求从尺寸类 / 窗口尺寸类驱动结构绝不做 device-model 检查。这在两端平台参考中都有配套工具链iOSios.md安全区safe area内布局控件不得进入刘海、灵动岛、Home 指示条或圆角区域系统导航栈 sheet边缘滑动返回必须存活永不禁用或覆盖。Androidandroid.mdedge-to-edge 配合窗口 insets——状态栏、导航栏、显示切割display cutout、IME 键盘 insets 都要处理内容永不躲在系统栏或键盘后面系统返回永远可用尊重预测性返回手势。4.2 每种新配置都要尊重安全区与窗口 insets文档要求在每一种新配置刘海、铰链、状态栏、键盘下都尊重安全区与窗口 insets。这与两个平台参考的验收流程一致同时也呼应 Web 侧 adapt.md 中的env(safe-area-inset-*)与viewport-fitcover处理——但原生侧不是 CSS 技巧而是系统级 insets 的硬约束。4.3 模拟器求广度真机求真相文档给出明确的测试组合每个发布平台至少一台手机和一台平板两种方向支持的平台做分屏测试。两端平台参考给出了可直接复制的验证命令iOSios.md截图必须来自模拟器而非浏览器——xcrun simctl io booted screenshot path多台模拟器时用xcrun simctl list devices booted取 UDID 替换booted深色模式与动态字体必须纳入测试——xcrun simctl ui booted appearance dark并在大号 Dynamic Type 下检查截断。同时强调模拟器给广度姿态、手势与性能需要真机并说明证据来自哪一端。Androidandroid.md截图来自模拟器或真机——adb exec-out screencap -p path多设备用adb -s serial深色主题adb shell cmd uimode night yes字体缩放adb shell settings put system font_scale 1.3用后恢复1.0用于暴露固定布局掩盖的裁切。同样强调模拟器给广度手势、刷新率与性能需要真机。其他原生硬指标也值得在验证时对照iOS每个可点控件 44×44 pt 起、正文 17 pt、11 pt 下限、SF Pro 承担 UI 而品牌字只出现于展示性时刻、语义系统色 一种 tint 色驱动交互、系统材质而非手搓玻璃拟态Android触摸目标 48×48 dp 起、相邻至少 8 dp、sp 而非固定 px、Material 色彩角色与 tonal elevation、Material 3 组件与动效模式container transform / shared-axis / fade-through、遵循系统移除动画设置。这两组数字都是文档中翻译惯用语策略的量化锚点。五、完成后的交接交给 polish 做终审文档明确规定了适配的收尾动作When the adaptation feels native to each context, hand off to/impeccable polishfor the final pass.即当适配在每种上下文中都显得原生时交接给/impeccable polish做最终一轮打磨。这与 polish.md 的定位一致——polish 是精修绝非暗度陈仓的重新设计它会保留现有视觉世界只做缺陷分类missing token / one-off implementation / conceptual mismatch / local defect与最小正确层面的修复其验证清单明确包含原生平台在两种方向下测试手机与平板的尺寸类恰好是adapt.native.md产出物应达到的验收口径。两条参考由此形成闭环adapt负责跨上下文的迁移与重构polish负责迁移后的系统一致性与质量收口。六、NEVER 清单适配的五条红线adapt.native.md以一张禁令清单收尾任何一条被触碰都意味着适配失败不要把拉伸的手机布局发布到平板上Ship a stretched phone layout on a tablet不要把某一平台的控件或导航移植到另一平台Port one platforms controls or navigation onto the other不要在小屏设备上隐藏核心功能——如果它重要就让它能用Hide core functionality on smaller devices不要为了绕开布局 bug 而锁定方向Lock orientation to dodge a layout bug不要只信模拟器——姿态、手势和性能都需要真机Trust simulators alone。前三条与 ios.md、android.md 的 slop test 相互印证后两条则与两端平台参考Verifying the build章节的模拟器给广度真机给真相原则完全一致。把这条清单贴在每一次原生适配的验收之前就守住了适配 ≠ 缩放这条方法论的生命线。延伸阅读想了解 Web含移动 Web侧的适配可对照阅读 adapt.md进行原生适配前务必先读目标平台参考 ios.md 与 android.mdadaptive跨 OS 自适应设计语言项目需同时遵循两者。平台判定与PRODUCT.md的写入规则见 init.mdadapt命令在技能命令体系中的完整定位见 SKILL.md。【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考