layer-list中android:top/left不生效，因偏移基于item自身原始尺寸计算；若drawable无显式尺寸（如shape或color），其默认占0×0空间，偏移不可见。
layer-list 里 item 的 android:top/android:left 不生效？
多数时候不是写错了，而是没理解 layer-list 的默认布局逻辑：它不会自动拉伸子 item 去填满父容器，所有偏移量（android:top、android:left 等）都是相对于「该 item 自身原始尺寸」计算的。如果 drawable 本身是固定大小（比如一张 48×48 dp 的 bitmap），那偏移才直观；但如果是 shape 或未指定尺寸的 color，它默认只占最小必要空间（常为 0×0），偏移自然“看不见”。
实操建议：
- 给
item显式加android:width和android:height，哪怕只是android:width="match_parent"（注意：XML 中不支持字符串值"match_parent"，得用具体 dp 或android:gravity配合） - 更可靠的做法是用
android:gravity控制定位，比如android:gravity="top|end"，它对shape和color同样有效 - 若必须用偏移，优先在
bitmap或已知尺寸的 drawable 上使用，避免对android:top
用 android:gravity 替代偏移时要注意什么
android:gravity 是 layer-list 中最稳定的位置控制方式，但它作用对象是「当前 item 的内容」，不是整个图层——也就是说，它把内容往指定方向“贴边”，而不是让图层整体移动。效果取决于该 item 是否有明确尺寸边界。
常见场景与处理：
- 想让一个
android:width="match_parent"和android:height="match_parent"（实际用具体 dp 更稳妥），再加android:gravity="top|end" - 多个
item叠在一起，其中一个要居中：直接用android:gravity="center"，无需算偏移值 -
android:gravity在 API 23+ 对bitmap支持更好；旧版本中，bitmap的 gravity 可能被忽略，此时必须回退到android:top/android:right+ 显式宽高
为什么 android:top 设了 20dp，结果图层却下移了 40dp
这是叠加效应导致的错觉：layer-list 渲染时，每个 item 的位置是独立计算的，但视觉上它们会相互遮挡。如果你有两个 item，第一个设了 android:top="20dp"，第二个没设，它就从顶部开始画，看起来就像第一个“多下了 20dp”。更常见的是误把父容器 padding 或 View 的 layout_margin 当成了 item 偏移。
排查步骤：
- 用 Layout Inspector 查看真实渲染边界，确认偏移是否真的发生在
item层级 - 临时把其他
item注释掉，单独测试目标item的偏移效果 - 检查该
item的 drawable 是否自带内边距（比如inset标签或bitmap的android:gravity设置） - 注意单位：XML 中写
20dp没问题，但写成20（无单位）会被当成 px，在高密度屏上会严重偏移
在代码里动态替换 layer-list 的某个 item drawable 时位置错乱
XML 定义的 android:top/android:left 等属性，在运行时通过 LayerDrawable 的 getDrawable() 获取后，并不会自动映射为可编程的 offset。你拿到的只是一个普通 Drawable，它的位置信息已固化在 XML 解析阶段。
正确做法：
- 不要试图在代码里“修改”已有
item的偏移——layer-list 不提供 setTop/setLeft 接口 - 如需动态控制位置，改用
InsetDrawable包裹目标 drawable，再放进 layer-list；这样可在代码中调用setInsetTop()等方法 - 或者彻底放弃 layer-list，改用
FrameLayout+ 多个ImageView，用layout_marginTop和layout_gravity控制，灵活性更高
真正容易被忽略的点是：layer-list 的定位行为高度依赖子 drawable 的固有尺寸和测量逻辑，而不是一套统一的“坐标系”。很多问题其实不是写法错，而是没意识到某个 shape 默认宽度是 0，或者某个 bitmap 被缩放后改变了基准尺寸。
