移动端过渡动画卡顿的根本原因是重绘开销大，应仅用 transform 和 opacity 触发硬件加速，明确声明过渡属性，结合媒体查询按设备降级时长与效果，并适配触控操作与渲染瓶颈。
过渡动画在移动端常卡顿，根本原因是重绘开销大
移动端 GPU 能力参差不齐，transform 和 opacity 是仅有的两个能触发硬件加速的 CSS 属性。其他属性（如 width、height、left、top、background-color）触发布局（layout）或重绘（paint），在低端 Android 或旧版 iOS 上极易掉帧。
- 用
transform: translateX(10px)替代left: 10px - 用
opacity: 0.5替代visibility: hidden（后者无过渡效果） - 避免在
transition中写all，明确列出需过渡的属性，例如：transition: transform 0.3s ease, opacity 0.3s ease - 对于 iOS Safari，添加
will-change: transform可提前提示渲染引擎准备图层（但不要滥用，否则反而增加内存压力）
媒体查询中设置不同 transition-duration 不是“锦上添花”，而是必要降级
小屏幕设备（尤其是折叠屏或高 DPR 屏）未必性能差，但用户手势更敏感，过长的过渡反而显得迟滞；而桌面端鼠标操作节奏慢，稍长的过渡更显沉稳。不能只靠 JS 检测 UA，必须用 CSS 媒体查询主动适配：
- 使用
@media (max-width: 768px)或更精准的@media (hover: none) and (pointer: coarse)匹配触控主设备 - 在移动断点里缩短时长：
transition-duration: 0.2s（桌面端可设为0.35s） - 对动画密集区域（如导航菜单、模态框），可在移动端直接禁用过渡：
transition: none，避免卡顿干扰交互判断 - 注意：Safari 对
prefers-reduced-motion支持良好，应加兜底：@media (prefers-reduced-motion: reduce) { * { animation-duration: 0.01ms !important; animation-iteration-count: 1 !important; transition-duration: 0.01ms !important; } }
transition-timing-function 在不同设备上表现一致，但感知差异极大
cubic-bezier(0.4, 0, 0.2, 1)（即 ease-in-out 默认值）在桌面端流畅，在移动端却容易显得“拖尾”。这不是浏览器实现差异，而是手指释放瞬间与动画结束时间错位导致的体验割裂。
Android Remote Control
下载
远程控制 Android 设备，支持截图、自动化操作手机 App 等功能。本应用使用 uiautomator2 作为底层框架，通过 ADB 连接设备，用户无需 Root（1）查看手机屏幕；（2）自动化操作手机 App；（3）远程安装/卸载应用……
- 移动端优先用更“干脆”的缓动：例如
cubic-bezier(0.25, 0.46, 0.45, 0.94)（类似 Material Design 的标准弹跳收尾） - 避免使用
ease-out做入场动画——它在末段减速明显，触控反馈延迟感强 - 如果用 JS 控制过渡（如监听
touchend后加 class），确保 class 切换与事件时机严格对齐，否则 Safari 可能跳过首帧
过渡本身没设备差异，差异全来自你是否把“用户操作方式”和“渲染管线瓶颈”当作同一问题来解。最常被忽略的是：在折叠屏或横竖屏切换时，媒体查询会重算，但已触发的 transition 不会中断——这意味着你得用 transition-cancel（目前仅 Firefox 支持）或手动移除 class 来规避意外动画残留。
立即学习“前端免费学习笔记（深入）”；
