用途
Mobile Principles 是一套触屏优先（touch-first）的移动端 UX 设计原则集合。它会在检测到移动端环境（Web 移动端、iOS、Android）时加载，正文只保留简明规则，深入的细节内容放在 references/ 目录中。它面向需要为移动设备设计或实现界面的场景，帮助避免移动端特有的可用性问题。
主要能力
触控目标（Touch Targets）
原则给出各平台的最小尺寸与推荐尺寸：Apple iOS 为 44pt（最小与推荐一致），推荐 44pt 加 8pt 间距，依据 Apple HIG；Android 为 48dp，推荐 48dp 加 8dp 间距，依据 Material Design；Web 移动端为 44px，推荐 44px 加 8px 间距，依据 WCAG 2.5.5。规则是：任何小于平台最小尺寸的点击目标都属于可用性缺陷。命中区域可以超出可见图形（通过 padding、hitSlop 或透明的内部占位实现），但交互面必须达到最小尺寸；间距与尺寸同样重要，两个边缘相接的 44pt 按钮仍然容易误触。
无悬停原则（No-Hover Doctrine）
触屏上不存在 :hover。把悬停当作主要触发方式，意味着在每台手机上都会产生隐藏的可操作项；只能通过悬停触达的内容在移动端直接等于不存在。规则是默认可见，悬停样式只作为桌面端增强，绝不能作为承载交互的方式。文档给出 Web CSS（用 @media (hover: hover) and (pointer: fine) 包裹悬停样式）、SwiftUI（用 onTapGesture 与 contextMenu 替代伪悬停）和 Compose（用 combinedClickable 处理点击与长按）三类示例。
拇指区（Thumb Zones，Hoober 研究）
依据 Steven Hoober 的研究，竖屏手机使用绝大多数是单手或托持，拇指从屏幕底部角落为支点活动。屏幕被划分为：顶部为困难区（需要伸展或双手），中部为舒适区，底部三分之一为易达区（符合拇指自然弧线）。文档给出的规则是：底部三分之一放主要 CTA、发送、确认、FAB、标签栏；中部放内容与次要操作；顶部放返回、关闭、搜索、个人资料等用户预期会主动去够、而非下意识点击的元素。主 CTA 放在屏幕下半部，次要、低频或破坏性操作放顶部，绝不要把“支付”按钮放在手机屏幕右上角。
安全区域（Safe Areas）
文档列出各平台处理安全区域的 API：Web 使用 env(safe-area-inset-*)，SwiftUI 使用 .safeAreaInset(edge: ...) 与 safeAreaInsets 环境值，Compose 使用 Modifier.windowInsetsPadding(WindowInsets.safeDrawing)。并给出 Web、SwiftUI、Compose 三段代码示例，包括 Web 需要设置 viewport-fit=cover，以及用 env(safe-area-inset-bottom) 定位悬浮按钮。
减少动态效果（Reduced Motion）
提供跨平台统一对照：Web CSS 用 @media (prefers-reduced-motion: reduce)，Web JS 用 window.matchMedia('(prefers-reduced-motion: reduce)')，SwiftUI 用 @Environment(\.accessibilityReduceMotion)，UIKit 用 UIAccessibility.isReduceMotionEnabled，Compose 需自定义辅助函数并结合 Settings.Global.ANIMATOR_DURATION_SCALE。文档给出 SwiftUI、UIKit 与 Compose 的代码示例，并提示优先使用 ValueAnimator.areAnimatorsEnabled()（API 26+），因为它在动画时长缩放为 0 时返回 false，开发者选项中的“关闭动画”、省电模式以及无障碍设置中的“移除动画”都会触发该状态。
移动端手势（canonical patterns）
列出用户已熟知的五种手势，复用它们等于免费的 UX，重新发明则带来摩擦：从左边缘滑动返回（iOS 弹栈导航栈，不要覆盖，并在 Android 上通过预测性返回 Android 14+ 对应）；下拉刷新（在滚动区域顶部下拉重新获取，常见于信息流、邮件、列表）；下拉关闭（模态面板与图片查看器向下拖过阈值，通常 100–150pt，即关闭）；双指缩放（用于图片、地图与可缩放画布，需遵守最小/最大缩放限制）；列表行滑动操作（横向滑动列表行显示上下文操作，如前导与后导滑动对应不同操作集）。
移动端性能预算（Mobile Performance Budgets）
冷启动：中端设备上低于 2s，基准设备为 Android Pixel 4a 与 iPhone SE（第二代）；如果在 Pixel 4a 上要 4s，在用户实际持有的低端设备上就要 8s。帧预算：60fps 下每帧 16.67ms，120fps 下（ProMotion／高刷 Android）8.33ms；主线程上任何超过该值的同步操作都会造成卡顿。包体积：在引入重型媒体库之前，目标为 APK 小于 30MB、IPA 小于 50MB；Lottie/Rive 会增加 500KB 到 2MB，注意资源目录，PNG 未改用 WebP 或矢量通常是罪魁祸首。电量：后台不做持续 CPU 活动，合并任务，使用平台调度器（Android 的 WorkManager、iOS 的 BGTaskScheduler），除非用户明确要求前台媒体，否则避免 wake-lock。网络：尊重连接提示，Web 使用 Save-Data 请求头与 navigator.connection.saveData，iOS 使用 URLSessionConfiguration.allowsCellularAccess 与 NWPathMonitor 区分蜂窝与 Wi-Fi，Android 用 ConnectivityManager 加 NetworkCapabilities 检测计费网络。
反模式（BAD / GOOD）
文档给出三组对照：一是把悬停作为唯一揭示方式（BAD 示例中操作按钮在移动端永不出现，GOOD 示例默认可见、仅把悬停作为桌面增强）；二是低于最小尺寸的触控目标（BAD 为 32dp 图标按钮，GOOD 为 48dp 容器内放 24dp 图标）；三是忽略安全区域 inset（BAD 中 CTA 位于现代 iPhone 的 Home Indicator 之下，GOOD 用 safeAreaInset 保证按钮可见可点）。
使用方式
该技能在检测到移动端环境时加载；正文只保留简明规则，需要深入时按需加载子技能：手势深入看 references/gestures-deep.md，移动端无障碍深入看 references/accessibility-mobile.md，Compose 专用动画看 ../compose-motion/SKILL.md，SwiftUI 专用动画看 ../swiftui-motion/SKILL.md。
适用场景
适用于移动端界面设计、跨平台前端与原生应用开发、移动端无障碍适配，以及需要审查移动端交互可用性的场景。
限制
资料未提供该技能的收费、价格、平台支持范围或具体效果等信息，这些内容暂未提供。