企业官网建设流程全解析

大概快两年前，我第一次在Unity里跑通一个Live2D角色的时候，说实话有点懵——明明是一个"平面"模型，眨眼、转头、呼吸起伏却跟活的一样。那会儿我用的还是老一套序列帧动画思路，每做一个表情就导出一套图片，碰上角色头发要分层摆动，光是调动画曲线就快把头发薅光了。后来正儿八经开始学Live2D这套Unity插件，才算把这套东西摸明白。这篇文章就把我这段时间啃Live2D的经验做个整理，从核心原理到实际集成的完整链路都会聊到，全程用的都是Unity环境下的实践经历，希望能给正在和Live2D插件搏斗的朋友一点参考。

1. 先弄明白Live2D到底在算什么：和序列帧、骨骼动画的本质差异

很多初学者一上来就照着官方Demo翻源码，翻了两天发现还是云里雾里。我自己的经验是：在碰代码之前，一定先把Live2D的运行机制搞懂，不然改参数的时候完全不知道自己在改什么东西。

1.1 最核心的机制：网格变形而不是骨骼蒙皮

Live2D和传统2D动画最大的区别，在于它不在"图层"层面做文章，而是在"网格"层面做文章。整个模型本质是一张贴图，组件内部会把这张贴图切成一堆三角形网格，然后把瞳孔、嘴巴、头发、身体各部分分别挂在对应的网格区域上。所谓动画，其实就是直接修改网格顶点的位置，让贴图跟着网格一起扭曲形变——这跟Photoshop里的液化工具很像：推网格，图就跟着变。

关于贴图扭曲，这里有一个新手容易踩的认知误区。很多人一听说是网格变形，就以为和3D骨骼蒙皮是一回事。其实不一样。3D骨骼蒙皮是顶点跟着骨骼动，每个顶点受一根或多根骨骼加权控制；Live2D的网格变形是直接移动顶点坐标，不涉及真正的蒙皮权重计算（虽然装了绑骨工具，但本质上还是基于顶点偏置）。理解这个区别很重要，因为在实际调参的时候，你会知道"某个局部形变不正常"大概率是网格顶点没对齐，而不是骨骼权重写错了。

1.2 参数：一切动画的最小驱动单位

Live2D模型的所有表情、动作，最终都归到**参数（Parameter）**上。官方SDK里最常见的几个内置参数包括：ParamAngleX、ParamAngleY、ParamAngleZ（头部旋转）、ParamEyeLOpen（左眼睁开程度）、ParamMouthOpenY（嘴巴张开程度）、ParamBreath（呼吸起伏）等等。

参数本身只是一个浮点数，取值一般在-1.0 ~ 1.0或0.0 ~ 1.0之间。当你在Unity里把这个参数的值从0改成1，模型上对应的网格顶点就会按照预设的形变方式偏移，眼睛就从闭合状态变成睁开状态。换句话说：控制Live2D模型 = 控制一堆参数的数值。

这里有一个实战中的关键点：不同的模型制作方，参数名不一定完全一样。商业模型还好，基本都遵守官方命名规范；但如果是从第三方下载的模型，经常出现参数缺失或改名的情况。所以我建议在写驱动代码之前，先在运行时的Inspector面板里把模型的所有参数名刷一遍，再决定代码怎么写。

1.3 为什么要用这套方案：渲染成本和表现力的平衡

序列帧动画做高质量角色，需要准备大量的逐帧贴图，一张1024x1024的图放十来帧，内存分分钟爆掉；骨骼动画（比如Spine）效果不错，但在2D领域对美术的产出管线要求更高。Live2D用一个或几个二维贴图加一套形变数据，就能支撑出非常丰富的动态表现，内存压力小很多，而且模型换装只需要换贴图，形变数据能复用。对中小规模项目来说，这个性价比确实很突出。

2. 环境准备与版本匹配：这里最容易在第一步翻车

Live2D的Unity插件官方名字叫Cubism SDK for Unity，我一开始图省事直接在Unity的Package Manager里搜Live2D，搜出来一堆第三方封装包，装完才发现核心的CubismCore没带，根本跑不起来。后来老老实实去官网下载了最新版SDK包，才把环境理顺。

2.1 SDK的整体结构：核心、开源组件、示例工程

解压官方SDK后，你会看到几个关键目录：

• Assets/Cubism/：这底下是核心运行时代码，所有模型加载、参数控制、渲染逻辑都在这里。原则上不需要改动这些代码，只要调用就好。
• Assets/Live2D/Cubism/...：SDK的命名空间都是以Cubism开头的，比如CubismParameter、CubismModel。
• Samples/：官方示例工程，里面有从模型加载到交互控制的完整Demo，新手一定要先跑这里面的场景。
• Tools/：如果你要用Unity自带的编辑器功能生成模型预设，或者做网格编辑，会用到这里的脚本。

一个常见的困惑是：SDK版本和Unity版本是不是必须对应？我测试下来，SDK本身对Unity版本有最低要求（比如Cubism 5要求2020.3以上），但并没有苛刻的版本锁定。真正容易出问题的是两处：一是.unitypackage导入时如果你项目里存在旧版本SDK残留，会冲突；二是URP管线下的兼容性。官方的默认Shader是基于内置管线的，如果你项目开了URP，进游戏模型可能会渲染成黑乎乎一团。

2.2 URP管线下的处理办法

我自己的项目是用URP的，第一次把SDK塞进去，模型整个变成紫粉色，明显是Shader失效。解决办法有两个：

1. 把Live2D渲染用的材质放到一个不参与URP转换的相机层里，用内置管线单独渲染。这个方案麻烦，但能用。
2. 升级到Cubism 4.2.0以上的SDK版本，然后手动把Shader换成SDK里提供的URP兼容版本（在Cubism/Shaders目录下找带URP后缀的文件）。我还需要在Graphics Settings里把SRP切换成对应配置。

我最终选了方案2，换完Shader再调了一下材质上的Culling Mode和Render Queue，模型就正常显示了。如果你用的还是老版本SDK，强烈建议升级——除了管线兼容，老版本在Draw Call合并和模型加载速度上也不如新版本。

提示：在切换管线之前配置好所有渲染设置，尤其是Mobile端和PC端分开处理时，Shader变体数量也要注意，不然构建的时候会出现"shader got stripped"的报错。

2.3 模型文件放哪、怎么导入

Live2D的标准模型文件是.moc3（模型数据）、.model3.json（模型配置、贴图和参数映射）、.texture_xx.png（纹理贴图）。从一个第三方模型包里拿到这三样后，直接把整个文件夹拷到Unity的Assets/目录下，SDK会自动识别。

这里要注意的是：贴图纹理的导入设置。模型图像如果打开了Generate Mip Maps，在远处看的时候会出现一种类似"网格泛白"的视觉瑕疵，因为顶点形变后UV坐标在高Mip级别下会错位。我在项目里是手动把Live2D贴图的Mip Maps关掉的，实测清晰度稳定很多。如果需要保留Mip Map做远处降采样，可以把Aniso Level调低，并且把贴图的Wrap Mode改成Clamp，减少边缘拉伸造成的瑕疵。

3. 跑通第一个Live2D角色：从导入到屏幕上的完整链路

环境就绪后，找官方示例里自带的模型（一般有个Haru或者Mark的模型），导入场景，这一步能跑通，说明SDK和模型本身没问题。接下来再换成自己的模型，并尝试手动加载和控制。

3.1 在场景里放置模型的基本操作

在Unity中，官方推荐的方式是把.model3.json当作一个Prefab拖进场景。如果你拖进去后发现模型只显示一个空节点，不要慌——大概率是SDK的CubismModel组件还没初始化完成，或者你在界面上没点生成按钮。老版本SDK里，需要先选中Prefab，然后在菜单栏点击Live2D -> Cubism -> Generate Prefab。新版本SDK（4.x之后）一般导入的时候会自动生成，但如果你的模型是从旧工程迁移过来的，还是会遇到这个坑。

生成之后，模型节点下面会带这几个核心组件：

• CubismModel：管理模型资源的加载、令牌刷新、模型参数同步。
• CubismRenderer：负责渲染，控制颜色混合、透明度、受光参数。
• CubismParameters：包含所有参数公开属性，代码里访问它就够了。
• CubismParts：各种部件（比如头发、眼睛、嘴巴）在代码里的入口。

我建议新手先不要碰CubismModel的底层代码，直接访问Inspector里公开出来的参数列表，或者通过CubismParameter数组来遍历参数，理解每个参数和模型的对应关系。这点很重要，因为后续写表情系统、口型同步，本质都是在操作这些参数。

3.2 通过代码驱动眨眼和呼吸：最简示例

最直观的上手方式是写一小段代码，让角色自动眨眼、呼吸。核心逻辑是：拿到模型参数对象，然后根据时间曲线设置参数值。下面是我项目里的一个简化版脚本，注释写得很细，可以直接抄。

using UnityEngine; using Live2D.Cubism.Core; using Live2D.Cubism.Framework; public class SimpleLive2DController : MonoBehaviour { private CubismModel _model; private CubismParameter _eyeLOpen; private CubismParameter _eyeROpen; private CubismParameter _mouthOpen; private CubismParameter _breath; [Range(0f, 1f)] public float blinkSpeed = 0.05f; [Range(0f, 1f)] public float breathAmount = 0.08f; private void Start() { // 获取当前模型组件 _model = this.GetComponent<CubismModel>(); if (_model == null) { Debug.LogError("当前节点上没有 CubismModel 组件，请检查模型是否生成正确"); return; } // 通过参数名称查找参数对象 // 注：不同模型的参数名可能不完全一致，找不到时换个名字试 _eyeLOpen = _model.Parameters.FindById("ParamEyeLOpen"); _eyeROpen = _model.Parameters.FindById("ParamEyeROpen"); _mouthOpen = _model.Parameters.FindById("ParamMouthOpenY"); _breath = _model.Parameters.FindById("ParamBreath"); } private void Update() { if (_model == null) return; // 呼吸：用正弦波产生周期性的起伏 // 这个值同时也可以驱动胸口部分的形变参数，技美在做模型时通常会把ParamBreath映射到身体轮廓顶点上 if (_breath != null) { _breath.Value = Mathf.Sin(Time.time * 2f) * breathAmount; } // 眨眼：按固定周期眨眼，这里用平滑函数模拟真实眼睑开合的速度变化 float blinkCycle = Mathf.PingPong(Time.time * blinkSpeed * 10f, 1f); float eyeValue = Mathf.Clamp01(blinkCycle); if (_eyeLOpen != null) _eyeLOpen.Value = eyeValue; if (_eyeROpen != null) _eyeROpen.Value = eyeValue; // 简单的随机说话张嘴效果（如果想让嘴张得自然一些，应该用motion曲线控制，而不是随机数） if (_mouthOpen != null && Time.frameCount % 30 == 0) { _mouthOpen.Value = Random.Range(0f, 0.25f); } } }

这个脚本里最需要注意的就是：参数名必须和模型里实际存在的名字完全一致，包括大小写。我之前用过一批从某个平台白嫖的模型，ParamEyeLOpen在制作的时候被改名成了EyeLOpen，然后代码里找半天找不到参数，最后用Debug.Log把_model.Parameters全打出来才定位到。所以如果你的模型不眨眼，别怀疑代码逻辑，先检查参数名。

3.3 模型加载时的生命周期问题

还有一个很多人遇到的怪问题：模型一开始隐身的，等几帧之后才出现。原因是CubismModel在OnEnable的时候会异步加载资源，加载完才把网格提交给CubismRenderer。如果你在Start里立刻去设置参数，参数值虽然写进去了，但可能被加载完成后的初始化覆盖。稳妥的做法是监听模型加载完成的回调：

private void OnEnable() { if (_model != null) { _model.OnDidInitialize += OnModelInitialized; } } private void OnModelInitialized(object sender, System.EventArgs e) { // 在这里做参数初始化和动画播放 Debug.Log("模型初始化完成"); }

这个方法在官方SDK的CubismModel里是存在的，直接订阅就行。如果不确定回调名称，可以用协程延时几帧再操作参数，也能凑合解决。

4. 从眨眼到完整动作：理解动画和表情的驱动方式

只驱动几个参数能玩出一些小效果，但要做一个能对话、能摆姿势的角色，得配合Live2D的动画系统。这个系统不像Unity的Animator那样直接操作GameObject的Transform，而是操作参数曲线。

4.1 把模型导入Unity时的关键步骤：生成Animator Controller

Live2D模型自带的动作（.motion3.json）在Unity里会被转换成AnimationClip，这层转换不需要手工处理，SDK在导入模型时自动完成。你用Animation窗口打开某个动作Clip，会发现它记录的其实是各个Live2D参数的关键帧，而不是Transform位移旋转。理解了这一点，后面做动作融合就顺理成章。

要让角色播放这些动作的确跟随Unity的Animator，不过这里的Animator只负责控制参数曲线，不参与移动模型的位置。我在项目里是给模型添加了一个Animator组件，然后在Animator Controller里建了Idle、Talk、Wave几个状态，每个状态绑定一个对应的动作Clip，用Animator.Play直接切换。你也可以用CrossFade在两个动作间插值过渡，模型的表情会平滑过渡，不会突然跳变。

动画切换这块，有个很实用的经验：不要直接播放长动作，会把动作里的呼吸和随机小动作也一起播了。尤其是一些角色模型在动画编辑器里可能只做了"说话"和"闲置"两种动作，你播放"说话"时，如果你用同一个Animator层播其它动作，可能导致部分参数被覆盖（比如眼皮闭合状态），角色会出现"睁眼说话"的违和感。我的做法是把动作Clip拆成参数片段：呼吸单独用一个轻量Clip，嘴型和眨眼分开控制，这样组合起来更灵活。当然，如果你的动画师已经把所有动作都烘焙好了，那就无需拆。

注意：对于口型同步这类高频变化逻辑，建议直接写代码更新参数，不要依赖Animator，否则动画系统会跟代码产生参数争夺。如果你确实需要Animator控制嘴型，留下自己的Controller锚点值，别一直往参数里写值。

4.2 利用表情（Expression）而不是硬改参数

Live2D里还有一个特别实用的概念：表情（Expression）。表情本质上就是一个参数快照，把多个参数按指定数值同时设置，形成一种固定神态，比如"开心""沮丧""生气"。在Unity SDK里，模型导入时会自动生成表达式资产（.exp3.json对应为Expression Asset），运行时可以这样切换：

using Live2D.Cubism.Framework.Expression; var expressionController = _model.GetComponent<CubismExpressionController>(); if (expressionController != null) { expressionController.CurrentExpressionIndex = 1; // 切换到索引1对应的表情 }

注意是CubismExpressionController，不是老版本的CubismExpressionList。切换表情本质也是改参数值，但比手动一个个设省事得多。

这里有一个经验：表情切换和动画播放叠加时，会出现"表情被动画覆盖"或者反过来"动画被表情覆盖"的问题。因为动画和表达式都修改同一批参数，最终值取决于后写的一方。解决思路是：在播放动画时不要切换表情，或者在表情切换后把涉及角色的动画关键帧做一下调整。如果你的项目里角色会经常切换表情和动作，建议用一个参数优先级系统（比如给每个参数配一个优先级权重），否则功能上线后QA会把Bug单砸到你头上。

4.3 口型同步：看起来高级，实际实现很简单

Live2D的模型能做到很自然的说话效果，但口型同步需要外部输入。如果项目里接入语音识别或者是用音频波形驱动，最粗暴的方式是监听麦克风数据或者音频源的AudioSource频谱数据，抽几个频段的值映射到ParamMouthOpenY上。

我用的是Unity的AudioSource.GetSpectrumData，取低频带（比如80Hz ~ 300Hz）的能量值，经过平滑曲线映射到嘴部开合参数。效果还行，平时说话的时候嘴型跟着起伏很自然。但如果需要精确识别音素（比如区分"啊"和"咿"），则需要对更多频段做分析，或者外接口型预测的SDK。

新手做口型同步最容易犯的错是嘴型动画和眨眼动画写在同一个Update函数里，结果眨眼的频率被嘴部音频波形干扰，角色说话的时候还会疯狂眨眼。我的建议是：把眼睛参数、嘴部参数、头部转动参数拆成独立的控制模块，各管各的。后期维护起来也舒服，要调整某一个功能，不会影响其他人。

5. 实际集成中的高频问题和排查思路

踩坑经验永远是项目实战里最值钱的部分。下面这些情况基本都是在实际项目中摸爬滚打总结出来的，按"现象—原因—解决"的方式整理，方便你排查时对照。

5.1 模型显示异常：黑脸、紫粉、闪烁

这几类是Live2D入门群里问得最多的。

• 黑脸现象：材质丢失或者Shader没有正确设置。检查模型的材质球，确认Shader是Cubism/...系列。如果是URP项目，确保Shader选的是URP兼容变体。
• 紫粉色显示：同样说明Shader不兼容或编译失败，重点检查Log里有没有shader error。
• 莫名闪烁：贴图MipMaps导致UV坐标错乱，关掉MipMaps或设置Clamp模式后基本消失。另外，如果开深度写入，模型之间的重叠区域也可能出现闪烁，记得把Live2D材质的深度写入关闭。

5.2 模型透明通道出现白边或者黑边

角色贴图有Alpha通道，但边缘还是出现白边/黑边，多是因为纹理的透明度切割（AlphaIsTransparency）或Shader的Blend方式设置不对。Unity里检查贴图的Alpha Is Transparency是否勾选，材质球的Blend Mode是否切成Transparent（在Cubism Shader里一般是Normal和Cutout这两个选项）。如果还是白边，把贴图提前在美术那边做好预乘Alpha，边缘抗锯齿会好看很多。

5.3 Android或iOS真机上模型加载慢、掉帧

移动端性能瓶颈通常在渲染批次。一个Live2D模型往往由几十个网格组成，如果每个网格单独占一个Draw Call，十个角色就是几百个Draw Call，低端机扛不住。

解决办法是开SDK的渲染合批。在CubismRenderer上有一个CubismRenderController，里面默认有关于ShouldDrawMesh、DrawCall合并的相关设置。实际做过一个测试场景，开启合批后，二十个角色从300+Draw Call降到80左右。另外，贴图尽量合并到一张Atlas里，网格顶点不变的情况下也能减批次。如果你在移动端碰到莫名其妙的闪帧，先不要怀疑代码，用Profiler看一下渲染调用量和纹理内存，往往问题出在这一层。

5.4 模型整体偏移或缩放异常

不同模型的制作比例不一样，有的模型长宽比是1:1，有的可能更宽。Unity里引入多个模型后，最好在模型根节点统一设置缩放。我见过有项目因为模型缩放不一致，角色站在一起有的半身大有的半身小，最后是在加载时根据模型边界（CubismModel.GetBounds()）动态计算一个统一的缩放比例，才对整齐的。这个接口实测可以直接调用，不用担心跨版本问题。

5.5 角色没有动画但一直呼吸不止

如果你没有写呼吸逻辑，但模型还是像在呼吸一样，可能是模型自带的动作在循环播放。官方模型预设里往往会带一个Idle动作，如果你不想要，可以把Animator Controller里的Entry直接连到空状态，或者把那个时钟相关的Clip删掉。如果你只想要表情切换而不要闲置动作，把Animator的Play改成固定参数也行。

6. 把Live2D角色变成一个可交互角色：完整设计思路

等你能自由控制参数和播放动画了，下一步就是把角色真正做成一个"对话角色"。这部分的技术点不多，关键在于架构设计。我在自己的项目里是这么组织的：

6.1 模块划分：模型层、行为层、UI层

把Live2D的角色模块拆成三层，各管各的，千万不要把代码全塞在一个MonoBehaviour里：

• 模型层：负责参数封装，对外提供SetExpression(int index)、PlayMotion(string stateName)、SetLookingAt(Vector2 pos)等接口。内部管理Cubism模型组件和渲染设置。
• 行为层：负责角色的行为决策。比如：处于空闲状态时每隔5~10秒切换一个微笑表情；收到用户输入时进入听状态，随机点头；对话开始时播放"说话"动作并触发口型同步。这套逻辑和具体的模型无关，换一个模型也一样跑。
• 交互层：负责UI点击、键盘输入、消息系统对接。交互层只把用户意图传给行为层，行为层再调模型层接口。

这样分完之后，最关键的好处是：如果后续要换一个更精细的Live2D模型，不需要动行为层和交互层代码，只改模型层的参数名映射就行。我有一次换模型，花了不到半天就把全流程跑通了。

6.2 让角色"看着你"：视线跟随实现

这个功能很加交互真实感，实现也不复杂。核心思路是：根据角色在世界坐标的位置和玩家相机/用户鼠标的位置，算出角色头部的旋转角度，映射到ParamAngleX/Y，再用两个眼睛的开合参数做视线的朝上朝下调整。下面贴一段我简化过的视线跟随代码：

public class LookAtTarget : MonoBehaviour { public Transform target; // 要看向的目标 public CubismModel model; private CubismParameter angleX; private CubismParameter angleY; private CubismParameter eyeX; private CubismParameter eyeY; [Range(0f, 30f)] public float maxAngleX = 15f; [Range(0f, 20f)] public float maxAngleY = 10f; private void Start() { angleX = model.Parameters.FindById("ParamAngleX"); angleY = model.Parameters.FindById("ParamAngleY"); eyeX = model.Parameters.FindById("ParamEyeX"); eyeY = model.Parameters.FindById("ParamEyeY"); } private void LateUpdate() { if (target == null || model == null) return; // 把目标点从世界坐标转到模型本地坐标 Vector3 localTarget = model.transform.InverseTransformPoint(target.position); // 用atan2算出相对角度，再限制范围 float targetAngleY = Mathf.Atan2(localTarget.x, localTarget.z) * Mathf.Rad2Deg; float targetAngleX = Mathf.Atan2(-localTarget.y, localTarget.z) * Mathf.Rad2Deg; // 头部和眼睛的主次分配：头部负责大幅角度，眼睛负责小幅补齐 angleX.Value = Mathf.Clamp(targetAngleX, -maxAngleX, maxAngleX) / maxAngleX; angleY.Value = Mathf.Clamp(targetAngleY, -maxAngleY, maxAngleY) / maxAngleY; eyeX.Value = angleX.Value * 0.25f; eyeY.Value = angleY.Value * 0.25f; } }

这个函数放在LateUpdate里跑，保证在所有动画更新之后再计算视线，避免跟Animator抢参数。我用了主次分配思路，头部角度满幅时，眼睛只补一点，这样看着更真实，没有"机械转头"的生硬感。

6.3 结合对话和选择项

把Live2D角色嫁接到对话系统，理论上没有任何障碍，因为对话系统只关心"角色当前在说哪句话"，然后你去驱动口型和表情。我在做某款互动剧情Demo的时候采用的结构是这样的：

• 对话文本传到行为层。
• 行为层根据文本的情感色彩（比如带感叹号、特定关键词）匹配一个表情。
• 播放对应嘴型同步或嘴型动作，同时把当前句子按文本长度估算一个播放时长，作为动画切回Idle状态的延迟。

这里注意一个细节：中文文本和英文文本的语速差异很大，要按字符数估算时长，不能一刀切。我一开始直接按音频帧数做口型，结果碰到中文长句切换慢了半拍，后来改成根据字符数动态调整表情起始时间和结束时间，体验好了很多。

7. 性能优化和网格精度：折腾完动效的最后的硬骨头

Live2D在开发环境里跑得飞快，但真机上的性能优化才是决定项目能不能上线的那道坎。

7.1 Draw Call与网格合并

前面提到过CubismRenderController的合批能力。实际操作步骤是：找到模型组件，检查CubismRenderController的Inspector面板，把ShouldDrawMesh相关的空Mesh剔除，再把UseDrawCallInterop打开，平时测试能合并多少是看GPU能力定的。在Unity 2021以上的版本里，如果再用上GPU Instancing配合合批材质，提升会更明显。

如果合批后依然有很多Draw Call，还有一个土办法：让美术把贴图尽量合并成一张大图，然后同一个角色的多个网格共享材质，这样批次天然就是少的。有些模型为了换装的方便，把贴图拆得很碎，批次暴多，这时候需要在"换装灵活度"和"性能"之间做个取舍。

7.2 顶点数太多导致的高频更新压力

模型的顶点数不是越多越精细，尤其是对需要实时形变的网格。官方建议单模型在几万顶点以内，但实际上移动端的顶点数超过两三万，Update顶点数据的CPU消耗就会明显上升。如果你的模型在PC上流畅，一到手机就卡，先去看看模型网格顶点总数。我自己的经验是，把那些细节丰富但不参与动画区域的网格降采样（例如背景饰品、被头发遮挡的耳朵），可以减少大量计算。

7.3 定时更新策略

Live2D模型不需要每帧都更新参数，尤其是大多数时间只做闲置动画的时候。可以用CubismParameter的更新间隔做节流：如果模型主要待机不动，不需要让参数每帧引发网格重算。我试过把更新频率降到15Hz，在互动的瞬间切回60Hz，肉眼几乎察觉不到区别，但CPU占用降了差不多一半。不过这需要你对游戏的状态机有全局把握，不然容易漏掉某个交互入口。

7.4 内存与纹理压缩

Live2D的纹理一般是1024x1024左右，个别高清模型可能到2048x2048。移动端尽量把Texture Compression设为ASTC或ETC2，并根据目标平台调整Max Size。我有个老项目就是因为贴图没压缩，加载四个角色直接涨了100多MB内存，后来统一压缩，内存掉了一半。

8. 新手最容易忽略的五个坑：来自反复踩踏的经验

最后集中说一下那些"看起来没问题但就是跑不对"的隐蔽坑。

• 模型脚下偏移：模型的锚点有时候不在模型底部中心，而在模型头的位置。做角色摆位时不要凭感觉摆放，务必先读取CubismModel.GetBounds()的边界数据。

• 动画Clip里包含隐藏参数：若模型的Animator Controller里某个闲置Clip突然让角色的头发固定在一个角度，多半是那个动作Clip记录了不必要的参数值。百检法：在Animation窗口里打开Clip看帧曲线，只要不是你想控制的参数，果断删掉那一轨。

• CubismModel的Update Order：如果你同时用了CubismUpdateController，它会按ExecutionOrder统一管理模型的刷新时机。如果你直接改参数值但模型不动，马上查模型上CubismUpdateController的执行顺序或者是不是被别的组件停止了。

• 透明度对光照的影响：在高版本Unity里开启灯光后，Live2D材质会有受光照影响，如果模型整体发灰，调到Unlit、或者将材质的灯光影响关掉。

• 移动端多点触控导致角色乱跳：有些示例代码里直接写死了鼠标位置转模型角度，移植到移动端后要注意用多点触控的焦点，而不是取Input.mousePosition，不然两个手指同时点屏幕的时候角色会抽风。

写到这里，Live2D在Unity里的那点"门道"算是基本捋清了。回头再看，这套东西真正难的地方从来不是API调用，而是你用参数的思维去理解动画、理解和模型的关系——想通了这一层，后面那些表情、口型、视线跟随全都水到渠成。我后来在另一个项目里甚至用同一套模型代码直接跑了三个完全不同的游戏玩法，除了参数映射表换了换，其他基本没动。希望这篇经验整理能帮你少走几个弯路，有具体的翻车情况也欢迎在评论区聊聊，人多力量大嘛。