ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

Impeccable 原生应用技术审计:基于 audit.native 对 iOS / Android 应用做代码级质量评分与报告生成

Impeccable 原生应用技术审计:基于 audit.native 对 iOS / Android 应用做代码级质量评分与报告生成 Impeccable 原生应用技术审计基于 audit.native 对 iOS / Android 应用做代码级质量评分与报告生成【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable本指南讲解 Impeccable 设计技能体系中面向原生应用ios/android/adaptive的专项审计能力audit.native。它是一套从源码出发、按平台规范打分的系统化技术质检流程先按可访问性、性能、外观与主题、平台符合性、自适应性五个维度逐一扫描再生成包含健康评分、严重级别分级和修复命令建议的完整报告。读完本文你将掌握原生审计的评分标准、报告骨架的每一部分写法以及如何把审计结论安全地交给polish等后续命令落地修复。从 Web 审计到原生审计为什么需要独立的 audit.nativeImpeccable 的audit命令承担技术质量检查并生成综合报告的职责其核心规则是只记录问题、不直接修复把问题交给其他命令处理。当审计对象是原生平台时路由会发生切换Web 项目走 audit.md面向 DOM、CSS、浏览器渲染可调用impeccable detect等浏览器工具链ios/android/adaptive项目则必须切换到本文档对应的原生审计流程 audit.native.md从源码SwiftUI / UIKit / Compose / React Native / Flutter直接审查不适用任何浏览器工具或impeccable detect。两者共享同一份报告骨架因此在修改报告结构时必须保持同步。原生审计的打分依据不是主观审美而是平台参考文档iOS 平台参考 ios.mdHIG 符合性、SF Symbols、Dynamic Type、44 pt 触控目标等Android 平台参考 android.mdMaterial Design 3、Material 颜色角色、sp 缩放、48 dp 触控目标等adaptive双端跨平台项目则两个参考都要读。关键区别在于原生审计是代码级审计而非设计评论design critique。评分前必须先阅读对应平台参考若 Setup 尚未加载且每一步都以这个界面读起来像原生应用还是像移植过来的网站为判定锚点。诊断扫描五个维度的检查清单与 0-4 评分审计覆盖 5 个维度每个维度 0-4 分合计 20 分。下面逐个展开检查项与评分标准评分时对照平台参考执行。1. AccessibilityVoiceOver / TalkBack从无障碍角度检查交互元素能否被读屏软件完整理解与操作缺失标签交互元素没有无障碍标签accessibility label、特征traits/roles或状态播报阅读与焦点顺序遍历顺序不合逻辑、控件不可达、导航后焦点丢失文本缩放iOS 用固定 point 尺寸破坏 Dynamic Type或 Android 用 px 而非 sp大字号下布局裁剪或重叠触控目标小于 44 ptiOS/ 48 dpAndroid或间距过挤忽略 Reduce Motion视差和大幅滑动没有淡入淡出crossfade替代方案对比度在浅色或深色任一种外观下文本对比度不达标。评分锚点0读屏完全不可用、1重大缺口控件无标签、不支持缩放、2部分达标有标签但顺序或缩放破坏、3良好少量缺口、4优秀有标签、顺序合理、缩放干净、尊重 Reduce Motion。2. Performance原生性能检查聚焦运行时体验启动缓慢首帧前在 launch 阶段做重活列表未虚拟化长内容没有使用 FlatList / LazyColumn / List 的回收复用主线程卡顿滚动或手势路径中的同步工作60/120 Hz 下掉帧无效渲染React Native 中无意义的 re-renderCompose 中无意义的 recomposition缺少 memoization 或 key图片处理缩略图解码全尺寸大图、无缓存应用体积JS bundle 或二进制臃肿、存在未使用的依赖。评分锚点0到处卡顿、1重大问题未虚拟化列表、启动慢、2部分达标、3良好有轻微优化空间、4优秀启动快、滚动顺滑、体积精简。3. Appearance Theming外观与主题维度的核心是语义化硬编码颜色使用原始 hex 而非语义系统色iOS/ Material 颜色角色Android/ 设计令牌design tokens深色外观破损缺少深色变体、深色下对比度差、快速反色quick invertDynamic ColorAndroid 12没有静态回退方案或在该用的地方被忽略跨平台材质在系统材质system materials或色调抬升tonal elevation该出现的地方手搓视觉效果。评分锚点0全部硬编码、1令牌极少、2部分达标有令牌但使用不一致、3良好少量硬编码值、4优秀全语义化两种外观都是一等公民。4. Platform ConformanceCRITICAL关键维度对照已加载的平台参考含其 slop test打分重点识别网页移植痕迹系统手势破坏iOS 禁用边缘右滑返回edge-swipe backAndroid 劫持预测性返回手势predictive Back安全区违规内容侵入刘海、灵动岛Dynamic Island、Home 指示条、状态栏或键盘跨平台导航混用自定义全局导航、过度负载的标签栏、iOS 模式搬到 Android 或反之Web 形状控件HTML 风格按钮、自定义开关、依赖 hover 的交互暗示图标漂移混用图标集而非 SF Symbols / Material Symbols系统漂移与产品、平台或既有设计系统冲突的重复快捷键或装饰模式。评分锚点0Web 移植毫无原生感、1严重违规3-4 类、2部分违规1-2 处明显、3基本符合轻微问题、4完全原生熟练用户信任每个屏幕。5. Adaptivity自适应维度关注多尺寸、多方向、多窗口环境拉伸的手机布局平板/iPad 渲染放大版手机 UI而不是使用 size classes / window size classes方向破损横屏裁剪、被忽略或无故锁定方向键盘/IME 处理输入框被键盘遮挡、没有 insets 调整多任务iPad Split View / Android 多窗口破坏布局折叠屏Android 折叠屏在姿态变化时无视铰链。评分锚点0只适配一种屏幕尺寸、1重大破损横屏或平板坏掉、2部分达标、3良好少量边界情况、4优秀适配各种尺寸、方向与窗口化。打分所依赖的平台规则速查打分不是凭感觉而是落到平台参考的具体规则上。以下是 ios.md 与 android.md 中与五维评分直接相关的核心规则对照维度iOS 规则Android 规则触控目标每个可点击控件44×44 pt 起相邻目标留呼吸空间每个触控目标48×48 dp 起之间至少8 dp文本缩放使用系统文本样式Large Title 到 Caption跟随用户阅读字号禁止硬编码 point 尺寸11 pt 底线、Body 17 pt使用 Material type scaleDisplay/Headline/Title/Body/Labelsp 单位而非固定 px色彩语义系统色label、secondaryLabel、systemBackground、separator、tint自动适配深色与增强对比单一 tint 色驱动交互Material 颜色角色primary、on-primary、surface、surface-variant、secondary-container、outline、error角色令牌自动解析明暗与对比变体图标与字体SF Symbols SF Pro/SF Compact不混入 Web 图标集Material Symbols Roboto品牌字体经由 type scale 引入深色外观深色模式是一等外观设计与测试都要做深色主题是一等方案绝不做快速反色系统手势保留左边缘返回手势永不禁用或遮挡永远尊重预测性 Back 手势/按钮不困住用户安全区布局在 safe-area insets 内控件不进入刘海、灵动岛、Home 指示条、圆角edge-to-edge 应用 window insets状态栏、导航栏、挖孔、IME内容不藏在系统栏或键盘后动效系统转场push 滑动、sheet 升起尊重 Reduce Motion用 crossfade 替代视差与大滑动Material 动效模式container transform、shared-axis、fade-through遵守系统移除动画设置导航2-5 个顶级分区的 Tab bar层级用 navigation stack独立任务用 sheetcompact 宽度用底部导航栏3-5 个目的地expanded 宽度改用导航 rail 或 drawer永远不要把手机底部栏原样搬到平板slop 测试熟练 iPhone 用户会不会在非标控件前迟疑网页移植的典型特征是重造导航栏、自定义返回手势、Web 形状按钮、hover 依赖常见特征是披着 Android 皮肤的 iOS 应用只抄 iPhone 的底部导航、忽略系统 Back 手势、Cupertino 形状的开关与对话框这些规则在平台参考中以!-- rule:... --注释的形式内嵌可供工具链精确定位引用。生成报告从健康评分到分级发现诊断扫描完成后按固定骨架生成报告。注意骨架与 audit.md 保持同步仅维度名不同原生版为 Accessibility / Performance / Appearance Theming / Platform Conformance / AdaptivityWeb 版为 A11y / Performance / Theming / Responsive / Implementation Integrity。Audit Health Score审计健康评分先给出总览表每个维度填上分数与最关键发现#DimensionScoreKey Finding1Accessibility?[最严重的无障碍问题或 --]2Performance?3Appearance Theming?4Platform Conformance?5Adaptivity?Total??/20[Rating band]Rating bands评级区间18-20 Excellent只需小幅打磨minor polish14-17 Good修复薄弱维度即可10-13 Acceptable需要大量工作6-9 Poor需要重大重构0-5 Critical存在根本性问题。Platform Conformance Verdict平台符合性裁决从这里开始写。用通过与不通过pass/fail直接回答这个应用读起来像原生应用还是像移植的网站列出具体违规项并且要求残酷地诚实brutally honest——这是整个报告定调的部分。Executive Summary执行摘要Audit Health Score??/20评级区间发现的问题总数按 P0/P1/P2/P3 严重级别计数最关键的 3-5 个问题Top 3-5 critical issues建议的下一步行动。Detailed Findings by Severity按严重级别分级的问题明细每个问题都必须打上P0-P3 严重级别标签P0 Blocking阻塞阻止任务完成立即修复P1 Major重大显著影响使用或违反平台规范发布前修复P2 Minor次要造成困扰但存在绕过方案下一轮修复P3 Polish打磨锦上添花无真实用户影响有时间就修。每个问题的记录模板必须包含 7 个字段[P?] 问题名称Location位置屏幕、文件、行号Category类别Accessibility / Performance / Theming / Conformance / AdaptivityImpact影响对用户的实际影响Guideline规范违反了哪条 HIG / Material 规则如适用Recommendation修复建议如何修复Suggested command建议命令优先从{{available_commands}}中选用哪个命令处理。Patterns Systemic Issues模式与系统性问题识别重复出现的共性问题——这类问题说明是系统性缺口而非一次性失误。典型表达硬编码颜色出现在 15 个屏幕中应改用语义颜色整个标签栏和列表行的触控目标都低于 44 pt。Positive Findings正面发现记录做得好、值得保持和复制的实践。报告模板对此有专门要求跳过正面发现是被明令禁止的行为之一见下文 NEVER 清单。推荐行动把发现映射到命令而不是停留在描述报告以按优先级排序的推荐命令列表收尾排序规则是 P0 优先、再 P1、再 P21. **[P?] {{command_prefix}}command-name**简要描述结合审计发现的具体上下文 2. **[P?] {{command_prefix}}command-name**简要描述结合审计发现的具体上下文规则只推荐{{available_commands}}中的命令把发现映射到最合适的命令上如果推荐了任何修复最后一步必须以{{command_prefix}}impeccable polish结尾——这与 polish.md 的定位一致polish 是发布前的最终质量关卡它按 functional defects → 缺失状态 → 流程/层级/响应式漂移 → 视觉与动效不一致 → 代码与资源清理的顺序做分级修复并在验证通过后关闭 critique snapshot结束语固定为给用户的交接文案告诉用户可以逐个、全部或按任意顺序运行这些命令并提示修复后重新运行{{command_prefix}}impeccable audit查看分数提升。为什么审计必须可操作报告纪律清单文档末尾给出了报告质量的硬性纪律防止审计报告沦为噪音要详尽但必须可操作Be thorough but actionableP3 问题过多只会制造噪音聚焦真正重要的事NEVER 清单报告问题却不解释影响为什么这对用户重要给出泛泛的修复建议要具体、可操作跳过正面发现要肯定做对的部分忘记排序不可能所有问题都是 P0不经验证就报告误报false positives。这条不报告误报的纪律与 Web 版 audit.md 中把确定性发现与视觉判断分开、点出误报的要求一脉相承。与生态的衔接审计只是质检闭环的第一环从 SKILL.src.md 的命令表可以看到audit [target]位于Evaluate评估类别与其同类的还有critique启发式 UX 设计评审而修复落在 Refine 类别polish、bolder、quieter、distill、harden等和 Fix 类别clarify、adapt、optimize等。原生审计定位为只记录、不修复正是为了让问题能够路由到最合适的命令去解决平台符合性违规 → 结构性重做时参考 adapt.native.md强调重构思而非缩放、按 size classes 驱动、绝不在平板上拉伸手机布局触控目标与对比度 → optimize.md 或 harden.md全局收尾 →impeccable polish。此外原生审计与 Web 审计共享同一报告骨架这一设计保证了无论审计对象是网页还是原生应用产出的报告结构、严重级别体系、命令映射规则完全一致方便同一套 Agent 工作流无缝处理两种形态的项目。小结audit.native把原生应用质量从模糊的主观感受转化为可复现的量化流程五个维度可访问性、性能、外观与主题、平台符合性、自适应性逐项打分对照 ios.md / android.md 的平台规则判定符合性再按 P0-P3 分级产出可路由到具体命令的修复建议。它的核心价值在于两条纪律一是只记录不修复让问题进入正确的命令链路二是报告必须可操作——每个发现都要有位置、影响、规范依据和对应命令最终以polish收尾并重跑 audit 验证分数提升形成扫描 → 报告 → 修复 → 复检的完整闭环。【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表