引言：2D 项目的性能瓶颈同样在 Draw Call100 个 NPC 精灵产生 250+ Draw Call，加上特效与 UI 直奔 500——这是 2D 项目最常见的性能形态。直觉反应是打图集，但图集拆分不当反而更卡。问题在于：从Texture2D导入到SpriteRenderer上屏，中间每一层都有独立的优化条件，不理解合批规则与图集机制，优化就是碰运气。本文沿 Sprite 的生命周期拆解：数据构成、渲染收集与合批、图集与加载策略。一、Sprite 的数据模型与内存布局1.1 Sprite 是什么Sprite 不是纹理，而是"纹理 + 区域 + 元数据"的视图对象：Rect：在源纹理（或图集纹理）上的像素区域；Pivot：归一化的旋转/定位锚点；Border：九宫格（Sliced/Tiled）拉伸的边距；顶点网格：默认 4 顶点四边形，启用 Tight Mesh（网格打包）或自定义 Physics Shape 时为切分后的三角网；UV 映射：已按 Rect 换算到纹理坐标系，打进图集后 UV 自动指向图集位置。托管层的 C# 对象只是几十字节的包装，实际数据（顶点缓冲、UV 表、纹理引用）都在原生侧。内存评估应聚焦纹理本身（含压缩格式与 Mipmap）而非 Sprite 对象数量。/