4. 动画与帧率：Android Choreographer机制、属性动画与硬件加速、60fps与120fps的调优目标
说到座舱的动画，我见过太多「看起来流畅，一测帧率就露馅」的项目了。你想想看，用户手指滑过地图，或者切换仪表主题时，但凡掉一帧，那种「卡一下」的感觉，在车内这种近距离、高专注度的场景下，会被放大好几倍。今天我们就来聊聊，怎么把动画帧率这块硬骨头啃下来。
4.1 先搞懂 Choreographer 在干什么
Android 的渲染流程，说白了就是一场「生产与消费」的接力赛。Choreographer 就是那个发令枪。它负责接收 VSync（垂直同步）信号，然后通知各个模块开始干活。
我习惯把 Choreographer 的工作流程拆成三步：
- 接收 VSync 信号：硬件每 16.6ms（60fps）或 8.3ms（120fps）发一次信号。
- 分发回调：依次触发 Input（输入处理）、Animation（动画计算）、Traversal（布局与绘制）。
- 提交帧：把最终结果交给 SurfaceFlinger 合成显示。
这里有个坑，我踩过好几次。Choreographer 的回调是串行的。如果 Input 阶段耗时过长，Animation 和 Traversal 就得排队。结果就是——掉帧。所以，不要在 Input 回调里做任何耗时操作，哪怕只是打印日志。
核心要点：Choreographer 的每一轮回调，必须在 VSync 周期内完成。超时 = 丢帧。
4.2 属性动画 vs 视图动画：选对工具
很多新手喜欢用 View Animation（补间动画），因为它写起来简单。但我个人建议，能用属性动画就别用视图动画。为什么？
视图动画只改变 View 的绘制位置，不改变实际坐标。你想想看，一个按钮用视图动画移走了，点击事件还在原地。这在座舱里很要命——用户明明看到按钮在右边，点左边却触发了，体验极差。
属性动画就不一样了。它直接修改对象的真实属性，比如 translationX、alpha、scaleY。而且，属性动画天然支持硬件加速。
举个例子，我优化过一个仪表盘上的转速指针动画：
// 不推荐：视图动画
RotateAnimation anim = new RotateAnimation(0, 90);
anim.setDuration(300);
view.startAnimation(anim);
// 推荐：属性动画
ObjectAnimator anim = ObjectAnimator.ofFloat(view, "rotation", 0f, 90f);
anim.setDuration(300);
anim.start();属性动画还有一个好处：它自带帧率回调。你可以通过 addUpdateListener 实时监控当前帧的进度，方便做性能打点。
我的习惯：所有涉及用户交互的动画，一律用属性动画。纯装饰性的背景动画，才考虑视图动画。
4.3 硬件加速：不是开了就完事
Android 从 3.0 开始支持硬件加速，4.0 之后默认开启。但「开启」不等于「生效」。我见过太多项目，清单文件里配了 android:hardwareAccelerated="true"，结果动画还是卡。
为什么会这样？因为硬件加速对某些 API 不兼容。一旦遇到不支持的绘制操作，系统会回退到软件渲染。这一退，帧率直接腰斩。
常见的「坑」有这些：
- Canvas.clipPath()：在硬件加速下，clipPath 只支持差值路径，不支持复杂路径裁剪。
- Paint.setXfermode()：某些混合模式在硬件加速下无效。
- 自定义 View 的 onDraw 中直接操作 Bitmap：比如在 draw 方法里 new Bitmap，这会导致 GPU 纹理上传频繁。
我曾经排查过一个地图缩放卡顿的问题。代码里用了 Canvas.saveLayer() 来做图层叠加，结果在部分车机上帧率从 60fps 掉到 20fps。查了半天，发现 saveLayer 在硬件加速下会触发离屏渲染，开销极大。后来改用 Bitmap 缓存 + 矩阵变换，问题解决。
避坑指南：如果你发现某个动画在模拟器上流畅，真机上卡顿，优先检查是否触发了软件渲染回退。可以用 adb shell dumpsys gfxinfo 查看渲染类型。
4.4 60fps vs 120fps：调优目标怎么定
现在很多座舱屏幕都上了 120Hz 刷新率。但说实话，不是所有动画都需要跑 120fps。你想想看，一个静态的菜单切换动画，60fps 和 120fps 人眼几乎分辨不出区别。但如果是地图拖拽、列表快速滑动，120fps 的顺滑感就非常明显。
我建议这样定目标：
| 场景 | 目标帧率 | 说明 |
|---|---|---|
| 静态页面切换 | 60fps | 过渡动画，人眼感知不强 |
| 列表滑动 | 90fps 以上 | 滑动跟手性要求高 |
| 地图拖拽/缩放 | 120fps | 连续操作，帧率越高越跟手 |
| 仪表指针动画 | 60fps 稳定即可 | 指针运动有物理惯性，60fps 足够 |
这里有个细节：120fps 的 VSync 周期只有 8.3ms。这意味着你的每一帧处理时间必须控制在 8ms 以内。对于复杂的动画，比如同时有多个属性在变化，很容易超时。
我的做法是：分层渲染。把动画拆成「高频更新层」和「低频更新层」。高频层只更新位置、旋转等轻量属性；低频层负责颜色、文字等变化。这样能有效降低单帧负载。
调优口诀：能缓存的别重绘，能复用的别新建，能分层的别混在一起。
4.5 实战：用 Profile GPU Rendering 定位问题
工具不用多，够用就行。我排查动画帧率问题时，最常用的就是 Profile GPU Rendering（开发者选项里的「GPU 呈现模式分析」）。
打开之后，屏幕上会显示一条条彩色柱状图。每根柱子代表一帧，颜色代表不同阶段：
- 蓝色：Display 时间（实际显示耗时）
- 红色：Command 时间（GPU 命令处理）
- 绿色：Process 时间（CPU 处理）
如果绿色柱子特别高，说明 CPU 侧在布局或绘制上耗时过多。如果红色柱子高，说明 GPU 负载重，可能是过度绘制或纹理太大。
我记得有一次，一个车载音乐播放器的封面旋转动画，帧率始终上不去。打开 Profile GPU Rendering 一看，红色柱子几乎顶到天花板。排查后发现，封面图片是 4K 分辨率，每次旋转都要重新采样。后来改成加载 720p 的缩略图，帧率直接回到 60fps。
小技巧：在开发者选项里开启「显示刷新率」，可以实时看到当前帧率。配合 Profile GPU Rendering，基本能定位 90% 的动画卡顿问题。
4.6 总结一下
动画与帧率优化，说到底就是「在有限的时间内，做完该做的事」。Choreographer 给了你一个固定的时间窗口，属性动画给了你灵活的 API，硬件加速给了你 GPU 的算力。你要做的，就是别浪费这些资源。
最后送大家一句话：流畅不是测出来的，是设计出来的。从动画选型到渲染链路，每一步都考虑性能，最终才能交出让人满意的座舱体验。