toXScale 是 XML 缩放动画的结束值，但仅控制绘制效果，不修改 View 的 scaleX 属性；需在 onAnimationEnd 中手动调用 setScaleX 或改用 ObjectAnimator 才能真正更新属性值。
scaleX 动画结束值不是 finalXScale
Android XML 缩放动画里没有 finalXScale 这个属性——它根本不存在。你写的 toXScale 就是动画结束时的最终值，但它的实际生效受两个关键因素制约：起始值来源、是否设置了 fromXScale。
常见错误现象：toXScale="0.5" 却发现动画结束后 View 没缩到 0.5，而是回弹或卡在其他值；或者动画压根没缩，只是闪一下。
- 如果没写
fromXScale，系统会默认取当前 View 的scaleX值作为起点（可能为 1.0，也可能被之前代码改过） - 动画只影响绘制层，不修改 View 的实际
scaleX属性值；动画一停，若没手动设置，View 会按原属性继续渲染 -
fillAfter="true"只让动画“看起来”停留在终点，但 View 的scaleX属性值仍是旧的，后续调用getScaleX()仍返回原始值
XML 中正确设置 scaleX 终止状态
要确保动画结束后 View 真正处于目标缩放比例，不能只靠 toXScale 和 fillAfter。必须配合 Java/Kotlin 代码做收尾。
使用场景：按钮点击后缩小消失、卡片展开时横向拉伸、加载动画中图标脉冲缩放。
- XML 动画中明确写上
fromXScale和toXScale，避免依赖运行时状态 - 给
Animation设置监听器，在onAnimationEnd里调用view.setScaleX(targetValue) - 如果用的是
ViewPropertyAnimator或ObjectAnimator，它们默认就更新属性值，无需额外处理
示例（XML 片段）：
<scale xmlns:android="http://schemas.android.com/apk/res/android" android:fromxscale="1.0" android:toxscale="0.5" android:duration="300" android:fillafter="true"></scale>
但这只是视觉停留，view.getScaleX() 仍返回 1.0，除非你在回调里手动设。
用 ObjectAnimator 替代传统 Animation 更可靠
老式 Animation 类（如 ScaleAnimation）只驱动绘制，不触碰属性本身；而 ObjectAnimator.ofFloat(view, "scaleX", 1f, 0.5f) 直接读写 scaleX 属性，动画结束即完成赋值。
性能与兼容性影响：API 11+ 可用，比 XML 动画更易控制、更少隐式状态干扰；无须担心 fillAfter 失效问题。
- 避免在 XML 动画里混用
fillAfter="true"和代码中反复调用startAnimation()，容易导致视觉错乱 - 如果必须用 XML（比如从资源文件动态加载），务必在
AnimationListener.onAnimationEnd()中补一句view.setScaleX(0.5f) - 注意：自定义 View 若重写了
setScaleX()，要确保它调用了super.setScaleX()，否则ObjectAnimator无效
scaleX 动画卡顿或跳变的典型原因
缩放动画看起来不顺滑，大概率不是 toXScale 写错了，而是布局或测量环节出了问题。
常见错误现象：动画过程中 View 内容模糊、边缘锯齿、突然位移、结束时轻微抖动。
- 父容器开启了硬件加速但子 View 启用了
setLayerType(LAYER_TYPE_SOFTWARE, null)，会导致缩放阶段强制切回软件绘制 - 在
onDraw()里做了耗时操作（如重复创建 Paint、频繁 new Path），缩放动画帧率直接受拖累 -
scaleX改变后，若 View 内部逻辑依赖getWidth()或getMeasuredWidth()，这些值不会随缩放变化——它们反映的是原始尺寸，不是视觉尺寸
调试建议：打开「GPU 呈现模式」，看缩放帧是否稳定在 16ms 内；用 Layout Inspector 检查动画期间 View 的 transform 矩阵是否连续更新。
真正麻烦的地方在于：缩放动画的“结束值”看似是个数字，实则横跨了 XML 定义、属性更新、硬件绘制、父容器测量四个层面。漏掉任意一环，toXScale 就只是个幻觉。
