trimPathEnd 对未闭合的 pathData 效果不可靠，尤其路径以 z 结尾时易被忽略或渲染异常；需闭合路径、避免硬编码、配合 PathMeasure 测量、主线程调用并 invalidate。
trimPathEnd 在 vector drawable 中不起作用？检查 pathData 是否闭合
直接说结论：trimPathEnd 对未闭合的 pathData 效果不可靠，尤其当路径以 z（close）结尾时，系统可能忽略修剪逻辑或渲染异常。
Android 的 vector drawable 渲染引擎对 trimPathStart/trimPathEnd 的处理依赖路径的几何长度估算，而这个估算在路径不闭合、含贝塞尔曲线或存在重复起点/终点时容易失准。
- 用
android:pathData="M0,0 L100,0 L100,100"（不闭合）时，trimPathEnd="0.5"可能完全不生效或只裁掉一丁点 - 加
Z闭合后：android:pathData="M0,0 L100,0 L100,100 Z"，trimPathEnd才更稳定反映“总长度的 50%” - 如果路径含
C或Q曲线，长度计算本身就有近似误差，trimPathEnd="0.99"仍可能残留可见线段
XML 中 trimPathEnd 值为 0～1，但动画时别直接硬编码
trimPathEnd 是归一化值：0 表示路径完全隐藏，1 表示完整显示。但它不是像素单位，也不随 View 尺寸缩放——它只跟 pathData 自身的路径长度有关。
常见错误是写死 trimPathEnd="0.7" 然后套进 AnimatedVectorDrawable，结果动画卡顿或跳变。根本原因是：路径长度在不同 Android 版本（尤其是 API 21–23）中计算方式略有差异，硬编码值会导致动画起止位置偏移。
- 动画中优先用
ValueAnimator控制trimPathEnd，起始设0f，结束设1f，避免中间值魔数 - 若需精确停在某个视觉位置（比如只画出前 80% 的箭头），先用
PathMeasure在代码里测真实长度，再反推归一化值 - API 24+ 对曲线路径长度估算更准，但低版本仍建议加容错：动画结束时额外 set 一次
trimPathEnd="1"强制收尾
和 strokeWidth、strokeLineCap 组合使用时，trimPathEnd 会截断端点样式
trimPathEnd 是纯几何裁剪——它在路径长度的指定位置“砍一刀”，不管那里是不是线段端点。这意味着 strokeLineCap="round" 的圆头、strokeLineJoin="miter" 的尖角，都可能被截成平口或错位形状。
例如一个圆角矩形路径，trimPathEnd="0.25" 刚好停在第一个直角转弯处，你看到的不是圆润转角，而是一个突兀的、带半截圆头的断口。
- 如果 UI 要求端点必须保持
round或square，不要依赖trimPathEnd做精细控制，改用AnimatedVectorDrawable配合多个path分段绘制 -
strokeWidth越大，被截断的端点视觉误差越明显；宽度 > 4dp 时，trimPathEnd的可用精度实际下降明显 - 测试时务必在 targetSdkVersion ≤ 28 的设备上真机验证，高版本渲染优化可能掩盖低版本的真实问题
动态修改 trimPathEnd 必须调用 invalidate()，且不能在非主线程操作
XML 里写的 trimPathEnd 是静态值，运行时想改只能通过 VectorDrawable 的 mutate() + setTrimPathEnd()，但很多人漏掉关键一步：不调 invalidate()，UI 就不会刷新。
更隐蔽的坑是，在 Handler.postDelayed() 或协程 IO 线程里调用 setTrimPathEnd()，会抛 CalledFromWrongThreadException——VectorDrawable 内部状态更新强制绑定主线程。
- 正确顺序：
drawable.mutate().setTrimPathEnd(value); view.invalidate(); - 批量更新多个
path时，先全部setTrimPathEnd()，最后统一invalidate()，避免多次重绘 - 用
AnimatedVectorDrawable时，别手动干预trimPathEnd，动画系统自己管理；强行干预会导致状态冲突，出现路径闪动或卡死
真正麻烦的是路径含多段贝塞尔曲线又要求精确停在拐点——这时候 XML 的 trimPathEnd 已经不够用了，得切到 Canvas 层手动画，或者用 PathMeasure + Path 动态构造。
