trimPathStart 从路径绘制起点（首个M命令处）按归一化比例裁剪路径前端，0.0显示全部、1.0完全隐藏；仅对单个path生效，多子路径时只计第一个M，配合trimPathEnd定义可见区间[start,end]，start>end则全隐。
trimPathStart 在 path 里到底修的是哪一段
它不是从整个 SVG 路径字符串开头切，而是从路径的「绘制起点」开始按比例裁掉前面一部分。这个起点由 android:pathData 中第一个命令（通常是 M）决定，后续所有 L、C、Q 都算在“路径长度”里——但 Android 不直接暴露总长度，它用的是归一化比例（0.0 到 1.0）。
常见错误现象：trimPathStart="0.5" 却没看到半截路径消失，可能因为路径是闭合的（Z），或起始点被移动过（比如 M 后跟了 m 相对移动），导致视觉起点和计算起点不一致。
- 只对单个
<path></path>生效，不能跨多个<path></path>累加计算 - 值为
0.0表示显示全部，1.0表示完全隐藏（留空） - 若同时设了
trimPathEnd，实际显示区间是[trimPathStart, trimPathEnd]，超出范围自动截断
XML 里写 trimPathStart 的典型场景
最常用在加载动画、进度指示器这类需要“路径逐步展开”的效果上，比如画一个圆环进度条，用 trimPathStart 控制已填充部分的起始位置。
使用场景：VectorDrawable 配合 AnimatedVectorDrawable 做属性动画；或静态设置做固定状态展示（如 30% 加载完成）。
- 必须配合
android:pathData使用，单独写trimPathStart没效果 - 不支持表达式或引用资源，只能写浮点字面量（如
"0.25"） - 如果路径含多个子路径（多个
M），Android 只按第一个M开始算，其余子路径被忽略在长度计算外
<path
android:name="circle"
android:pathData="M20,40 A20,20 0 1,1 60,40 A20,20 0 1,1 20,40"
android:trimPathStart="0.25"
android:strokeWidth="2"
android:strokeColor="#333" />
trimPathStart 和 trimPathEnd 的配合陷阱
两者不是独立生效，而是共同定义一个“可见窗口”。当 trimPathStart > trimPathEnd 时，路径会完全不可见（Android 内部逻辑直接跳过绘制）。
容易踩的坑：trimPathStart="0.7" + trimPathEnd="0.3" 看起来像想“绕一圈”，但实际结果是空白——Android 不做模运算，也不翻转方向。
- 动画中动态修改这两个值时，务必保证
start ≤ end，否则动画中间会突然闪一下 - 若想实现“反向擦除”，应该保持
end = 1.0，只动start；或用android:rotation配合翻转整个VectorDrawable - 在低版本 Android（如 5.0）上，某些复杂路径（含大量贝塞尔曲线）的长度估算有偏差，
trimPathStart="0.5"可能实际切在 48% 或 53%
替代方案：为什么有时该放弃 trimPathStart
当路径结构复杂、需精确控制某一段线段（比如只裁掉箭头尖端），或要响应触摸事件做交互式裁剪时，trimPathStart 就力不从心了——它没有锚点、不支持坐标定位、也不能按像素裁。
这时候更可靠的做法是：把原路径拆成多个独立 <path></path>，用 android:visibility 或 android:alpha 控制显隐；或者改用 Canvas.drawPath() + PathMeasure 在代码里手动截取。
- VectorDrawable 的 path 修剪本质是渲染层优化，不是矢量编辑，别指望它做设计软件级操作
- 如果路径来自 Sketch/Figma 导出，注意检查是否含未合并的子路径、冗余
M命令，这些都会干扰trimPathStart的行为 - 真要调试裁剪位置？加个临时
android:strokeColor="#f00"+android:strokeWidth="4"，肉眼比数值更准
路径修剪的“比例”背后没有标准长度定义，不同设备、不同 Android 版本对同一段 pathData 的长度估算可能差几个百分点。别死磕 0.333 和 0.334 的区别，留点余量更稳妥。
