解读

在国内一线与二线大厂的 Android 面试中，这道题属于“动画原理”必考题。面试官通常不会满足于“一个能直接改属性，一个只是发值”这种一句话答案，而是希望候选人能把“属性动画框架的设计意图、性能差异、反射开销、动画链式组合、硬件加速兼容性”讲清楚，并能结合线上崩溃或卡顿案例给出选型依据。答得够深，可以直接把话题引到“自定义 Interpolator + Choreographer + RenderThread”等高阶优化点，体现技术厚度。

知识点

1. 继承关系：ObjectAnimator 是 ValueAnimator 的子类。
2. 数据流：ValueAnimator 只负责“时间 → 0~1 进度 → 计算后的值”，不持有 View 或任意对象；ObjectAnimator 在 ValueAnimator 的基础上通过反射/Setter 直接修改目标对象的属性。
3. 反射开销：ObjectAnimator 依赖 Property 反射或 Setter 方法，首次调用会走 JNI 查找，属性多或列表滚动场景下可能造成 1~2 ms 的卡顿；ValueAnimator 无反射，把值抛给外部回调，由开发者自己 set，可规避反射。
4. 类型安全与重载歧义：ObjectAnimator 对“同名不同参”的 Setter 敏感（如 setScaleX(float) 与 setScaleX(int) 并存），运行时会抛 NoSuchMethodError；ValueAnimator 由开发者手动赋值，不存在该隐患。
5. 更新频率：两者都在 AnimationHandler 中通过 Choreographer 每帧回调，但 ObjectAnimator 额外多一次 JNI 反射调用；在高频属性（如自定义绘制中的 pathMorph）连续变化时，ValueAnimator+手动赋值可省一次 JNI。
6. 组合动画：ValueAnimator 更灵活，可在同一个 updateListener 里修改多个属性，避免创建多个 ObjectAnimator 带来的 1~2 个对象分配；ObjectAnimator 适合与 AnimatorSet 搭配，利用 playTogether/playSequentially 做声明式编排。
7. 硬件加速：两者都支持，但 ObjectAnimator 修改的属性若声明了 @Keep 且被 RenderThread 识别（translationX/alpha/scale/rotation），可完全走 RT，不阻塞主线程；ValueAnimator 若手动修改自定义属性，需要确保该属性能被 RenderThread 缓存，否则容易回退到 CPU 绘制。
8. 生命周期与内存泄漏：ObjectAnimator 持有 target 强引用，在 Activity 退出前必须 cancel()，否则造成泄漏；ValueAnimator 只在代码里持有一次监听，监听若用弱引用或及时 remove，风险更小。
9. 国内 ROM 兼容性：部分魔改 ROM 对反射加限制（如 MIUI 12 早期“反射灰名单”），ObjectAnimator 在 targetSdk≥29 时可能触发系统拦截，导致动画失效；ValueAnimator 无此顾虑。
10. 代码可读性：Jetpack Compose 时代虽不再用 View 动画，但存量项目重构时，ObjectAnimator 的 XML 标签与 Kotlin 扩展（animate().scaleX().setDuration()）可读性更好；ValueAnimator 需要手写 updateListener，模板代码多。

答案

核心区别只有一句话：ValueAnimator 是“纯数值发生器”，ObjectAnimator 是“数值+反射 Setter 一体化”。

选型策略：

1. 只改系统已声明属性（alpha/translationX/scaleY 等）且需要 XML 声明或链式代码时，优先 ObjectAnimator，代码最少。
2. 需要同时改多个属性、或属性无 public setter、或属性名存在重载歧义、或 targetSdk≥29 在国产 ROM 上遇到反射限制时，用 ValueAnimator 手动赋值。
3. 自定义高频绘制属性（如波浪进度条中的 pathMorph）或帧率敏感场景（列表 item 动画），用 ValueAnimator 避免 JNI 反射，每帧省 0.3~0.5 ms。
4. 组合动画中若属性大于 3 个，可统一用 ValueAnimator 在单一 updateListener 里批量修改，减少 Animator 实例与 JNI 次数。
5. 在 AnimatorSet 里需要顺序或并发执行，且属性为标准属性时，ObjectAnimator 可读性最好；若动画需动态改变目标对象，用 ValueAnimator 把引用放到外部类，可随时切换 target。
6. 最后别忘了生命周期：两种动画在 onStop()/onDestroy() 里都要 cancel()，ObjectAnimator 还要把 target 置空，防止国产 ROM 的 StrictMode 报 “Animation leaked”。

拓展思考

1. Compose 时代的“动画思维”迁移：Compose 的 animate*AsState 内部实际是 SnapshotState + 帧时钟，与 ValueAnimator 的 Choreographer 回调思想一致；理解 ValueAnimator 的“值驱动”模型，有助于快速掌握 Compose Animation 的自定义 AnimationSpec。
2. 性能深挖：Systrace 中若看到 “android.animation.ObjectAnimator$ObjectPropertyValuesHolder.setValue” 占用 >0.6 ms/帧，即可判定反射成为瓶颈，可手动拆成 ValueAnimator + 缓存 Field/MethodHandle，降低 JNI。
3. RenderThread 与属性：Android 14 开始，只有标记为 @FastProperty 的 RenderNode 字段才能完全走 RT；自定义 View 的属性即使通过 ObjectAnimator 修改，也可能回退主线程，需要自定义 RenderNode 并调用 discardDisplayList() 强制缓存，才能享受 120 Hz 无掉帧。
4. 国内隐私合规：部分银行 SDK 在加固后会把反射白名单关掉，ObjectAnimator 会崩溃；提前在 init 阶段做 try-catch 并降级到 ValueAnimator，是上线前必做的兼容性巡检。