CSS动画在移动端更省电，核心原因是它把渲染任务交给了GPU合成线程，不持续占用CPU；而JS动画依赖主线程执行，频繁触发重排重绘，导致CPU负载高、发热大、电池掉电快。
为什么CSS动画能降低CPU功耗
CSS动画（尤其是用transform和opacity实现的）会被浏览器自动提升到独立的合成层（compositor layer），由GPU直接处理帧合成。这意味着：
- CPU几乎不参与每一帧的计算，只在动画开始/结束时做少量样式解析
- 即使页面不可见（比如切到后台标签页），浏览器可暂停CSS动画，进一步节电
- 无需JavaScript引擎反复解析、执行、垃圾回收，避免了内存抖动和CPU周期浪费
对比之下，JS动画哪怕用了requestAnimationFrame，也始终运行在主线程：每次回调都要执行JS逻辑、读写DOM、触发样式计算——这些全靠CPU扛着。
移动端特别敏感的两个耗电场景
在iOS Safari或Android Chrome中，以下JS操作会显著拉升功耗：
- 在
requestAnimationFrame回调里读取offsetTop、getBoundingClientRect()等布局属性 → 强制同步回流，CPU满载 - 用
element.style.left或element.style.width驱动位移/缩放 → 每次修改都触发重排，GPU无法接管 - 动画期间同时运行大量JS逻辑（如数据处理、网络轮询）→ 主线程阻塞，动画掉帧，系统被迫降频保温
而等效的CSS动画：transform: translateX(100px) + transition，全程不碰布局，GPU一帧合成完事。
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
立即学习“前端免费学习笔记（深入）”；
哪些CSS动画属性真能省电，哪些只是假象
不是所有CSS动画都省电。关键看是否走合成层：
- ✅ 真正省电：
transform（含translate、scale、rotate）、opacity—— 浏览器默认硬件加速 - ⚠️ 假省电：
top/left、width/height、box-shadow、filter（除blur外多数不加速）—— 仍走主线程重排/重绘 - ❌ 别乱加：
will-change: transform或transform: translateZ(0)虽能强制建层，但图层过多反而增加GPU内存压力和上下文切换开销
实测中，一个top: 0 → top: 200px的JS驱动动画，在iPhone 15上连续运行1分钟，机身温度上升1.8℃；同效果改用transform: translateY() + CSS transition，升温仅0.3℃。
真正容易被忽略的是：省电不等于“无代价”。CSS动画一旦启动，时间轴就固化在样式表里，没法像JS那样实时响应触摸中断、速度插值或物理阻尼——该用JS的地方硬套CSS，反而要靠轮询+强制重绘来补救，功耗更高。
