做Unity这行几年下来我最怕的不是某个API记不住而是回头翻自己三年前写的笔记发现根本找不到当时那条摄像机跟随抖动的解决方案到底存在哪个文件夹里。相信很多人跟我一样笔记从最初的新建文件夹(2)一路演化成Unity_学习_2019_不要删_重要最后连自己都不想打开。这篇内容就是把我这些年积累的Unity学习笔记按一套可检索、可扩展的目录体系重新整理出来——它不只是一份索引更是把散落在渲染、UI、平台发布、性能优化各个角落的知识点重新串成一条线。不管你是刚装好编辑器的新手还是已经做过几个上线项目的开发者这套目录结构和里面标注的实操要点都能帮你少走弯路尤其是那些官方文档不会告诉你的取舍细节。1. 为什么Unity笔记需要一份目录而不是一堆散文件1.1 笔记失控的真实代价我在带新人的时候发现一个规律大多数人记笔记的方式是按遇到问题的时间顺序来存的而不是按知识的结构关系来存的。今天调了个阴影新建一篇《阴影问题记录》明天研究微信小游戏视频播放再建一篇《视频播放踩坑》。半年之后当你想系统性回顾渲染相关的知识时发现这些笔记散落在十几个文件里彼此之间没有任何横向联系检索基本靠全文搜索碰运气。这种散乱带来的直接损失是知识的复用率极低。一个你明明解决过的问题因为没有归类下次遇到时又得从头查一遍时间全浪费在重复劳动上。更深层的损失是你无法看清自己在哪个方向上有系统性缺口。笔记目录其实就是你知识地图的投影——地图乱说明你的认知也是碎片的。提示判断自己的笔记是否失控有个简单标准——如果你的笔记里超过三次出现内容高度重复的条目说明归类体系该重建了。1.2 三层目录结构的设计逻辑我这套目录采用的是领域 → 模块 → 知识点的三层结构跟Unity自身的引擎架构大致对应。第一层是大的领域划分比如引擎基础、渲染图形、UI交互、平台发布、性能优化、工程化第二层是每个领域下的功能模块第三层才是具体知识点的单篇笔记。为什么按领域而不是按难度或时间分因为实际工作中问题几乎总是以领域的形态出现的——你调一个渲染问题会在Shader、阴影、包围盒这几个知识点之间来回跳它们应该待在同一个区域里而不是被时间线打散。按领域归类等于把关联性强的知识放在物理上相邻的位置检索时的跳转成本最低。另外一个设计原则是预留空目录。我一开始只建了四五类后来又不断往回收拾结果每次都要重新移动文件。后来学乖了一开始就把已知会碰到的领域全部建出来哪怕某些目录暂时是空的。空目录本身就是一种提醒——它告诉你这里还有一块知识没去碰。目录层级划分依据典型子项举例第一层知识领域渲染、UI、平台、优化、工程化第二层功能模块Shader、摄像机、打包、混淆第三层具体知识点单篇问题记录或方案总结2. 引擎基础与工程环境的笔记归档2.1 安装、版本与项目骨架引擎基础这块我把安装与版本管理单独拉出来作为第一模块。别小看这块Unity的版本迭代很快不同版本对同一功能的支持差异能让你怀疑人生。我的笔记里专门有一节记录各版本的关键差异和升级踩过的坑尤其是跨大版本升级时那些能被编译但运行时行为变了的隐性变更这些在升级日志里往往只有一句话但实际影响很大。项目骨架结构也是新手最容易忽略的部分。我在笔记里固定记录了一套标准目录约定资源放哪里、脚本怎么按模块拆文件夹、第三方插件单独隔离、场景文件命名规范。这套约定的价值在多人协作和后期维护时才真正显现——一个结构清晰的项目接手的人半小时就能上手一个乱堆的项目光是找入口场景就得花半天。关于下载和安装我只记录官方渠道的获取方式以及安装时组件勾选的经验移动平台支持、WebGL支持这些模块体积很大用不到的别装装了会让编辑器启动变慢也占硬盘。我试过全量安装结果启动时间比精简安装慢了一截后来只保留当前项目用得到的模块。注意升级引擎版本前先备份整个工程目录不要只依赖版本控制系统的历史记录因为有些资源导入缓存不在版本管理范围内回退时会出问题。2.2 C#脚本与Unity特有机制脚本这块的笔记我按语言基础和引擎特有机制分开记。语言基础指的是C#本身的语法、面向对象、委托事件、协程原理这些这部分是通用的我单独用一个模块避免跟Unity特有的东西混在一起。很多人把C#基础和Unity API记在一块结果复习语言时被引擎细节干扰效率很低。引擎特有机制才是重头戏我记录的核心是脚本生命周期函数的执行顺序、特性Attribute的用法、宏定义的条件编译这几块。生命周期顺序看着简单但实际调试时Update和FixedUpdate的执行时机差异、Awake和Start的先后关系经常是bug的根源。我在笔记里画了一张自己的时间轴把这个顺序固化下来遇到问题时直接对照。宏定义这块特别实用。用条件编译可以在同一个工程里区分开发版和发布版比如调试日志只在开发版里输出。我在笔记里记了几个常用宏的写法以及怎么在编辑器里切换生效这样打正式包时不用手动删代码。知识点速查区我还会收录一些容易忘但有明确答案的概念比如渲染器包围盒Renderer.bounds到底包不包含子物体、它和碰撞体的关系是什么。这类问题查一次忘一次放进速查区下次直接翻不用重新搜。还有像Mathf.PerlinNoise这种噪声函数我笔记里记的是它的输出范围、参数含义以及在生成地形或纹理时怎么配合使用这类工具函数属于知道在哪查就行的知识。2.3 基础概念速查区的维护方法速查区最忌讳的是把它写成流水账。我个人的做法是每条只保留一句话结论 一个最小示例 一个常见误解。比如包围盒那条结论就是它描述的是渲染器的轴对齐包围盒示例是获取中心点和尺寸的代码常见误解是有人以为它随旋转实时紧贴——实际上它是轴对齐的物体旋转后包围盒会变大而不是跟着转。速查区我建议每季度清一次。过时的、已经内化成直觉的条目可以删掉给新知识腾位置。笔记不是越多越好能快速定位到有用信息才是目的。这个习惯我是从踩坑里养成的曾经速查区堆了两百多条结果找东西比重新搜还慢反而成了负担。3. 渲染、Shader与视觉表现的笔记体系3.1 摄像机、分辨率与包围盒渲染这块我第一个模块放的是摄像机因为它是所有视觉呈现的入口。摄像机跟随是使用频率极高的功能我的笔记里记了三种常见跟随方案直接赋值位置、平滑插值、以及带前瞻的阻尼跟随并标注了各自的适用场景。直接赋值简单但会抖平滑插值稳但有延迟感阻尼跟随在快速移动时手感最好但参数需要调。笔记里我把关键参数的含义和调参方向都写清楚了而不是只丢一段代码。分辨率设置是另一个高频问题。不同平台、不同屏幕比例下的适配方案我按固定高度固定宽度两者都固定并处理黑边三种策略分别记录还附上了横竖屏切换时要额外注意的点。这块的坑在于编辑器里看着正常真机上一测就错位所以我的笔记强制要求每条分辨率相关的结论都标注在哪个平台哪个设备上验证过。3.2 Shader与阴影问题Shader的笔记我建议单独开一个大模块因为它自成一个体系。入门阶段记录的是渲染管线的基本流程、顶点着色器和片元着色器的分工、常用内置变量的含义。进阶部分才开始记录自定义光照、边缘光、描边这类常见效果的实现思路。阴影问题几乎是每个Unity开发者都会反复碰到的。我的笔记里把阴影问题拆成几类阴影不显示、阴影闪烁、阴影边缘锯齿、以及阴影距离过远时突然消失。每一类都记录了可能的原因和排查顺序。比如阴影闪烁常见原因是阴影偏移参数设置不当或者物体的包围盒过小导致被裁剪排查时我会先看这几个参数而不是盲目改阴影质量。这种按现象归类、按顺序排查的记录方式比单纯记解决方案有用得多因为现象是有限的而具体的解决方案是无限的。提示阴影排查时先关闭所有后处理再看基础阴影能排除掉一半的干扰因素。3.3 视觉细节技巧的沉淀除了核心渲染我还会专门留一块记那些锦上添花的视觉技巧比如物体逐渐消失的脚本控制、对话过程中角色表情的变化驱动、以及天气效果的动态浮动。这些效果单看都不难但组合起来能显著提升项目的完成度。以物体逐渐消失为例我的笔记里记了两种实现思路一是改材质的透明度二是改透明通道并配合淡出曲线。前者简单但受材质混合模式限制后者更灵活但需要处理渲染顺序。笔记里我把两种方案的代价都写明了方便按项目需求选。这类笔记的价值在于它把你零散试出来的经验固化了下次不用重新试错。4. UI、交互与输入的笔记整理4.1 UI显示隐藏三种方案的取舍UI显示隐藏到底该用哪种方式这个问题几乎每个Unity开发者都纠结过。我把SetActive、改localScale、以及把物体移出相机可视范围这三种方案单独做成一节对比笔记因为这三种方式的性能代价和使用场景完全不同。SetActive的优点是彻底隐藏后相关组件不再执行适合隐藏后短时间内不会再显示的元素缺点是频繁切换会有开销因为它涉及组件的启用停用和层级重建。改localScale的优点是切换极快不涉及层级变化缺点是物体还在场景里参与部分计算而且如果有布局组件可能会出问题边界情况多。移出相机范围则是折中方案物体保持激活但不可见适合需要保留状态的场景切换。我的笔记里给了一个选择判断表高频切换且需保留状态用移出相机或缩放低频切换且想释放开销用SetActive。这种把决策逻辑写下来的方式比单纯记三个API有用得多。方案切换开销是否保留状态适用场景SetActive较高否低频、可释放的元素改localScale低是高频切换、动画过渡移出相机范围低是需保留状态的界面切换4.2 按钮点击范围与交互细节按钮点不准是移动端项目的高频投诉点。我的笔记里记了一条视觉上的按钮大小和实际可点击区域是两回事实际响应区域由控件的射线检测区域决定。扩大点击范围的做法是在按钮边缘补一个透明的响应区域或者调整控件的目标图形设置。笔记里特别强调扩大范围时要考虑相邻按钮的间距否则会误触。交互这块我还记录了输入系统的两类方案老输入系统和新输入系统以及它们各自的适用场景。新输入系统更灵活支持多设备重绑定但对新手来说学习曲线陡。我的建议是按项目需求选别为了先进而强行上新系统简单项目用老的完全够。4.3 Timeline、对话与表情驱动Timeline是做过场动画和剧情演出的利器我的笔记里把它单独作为一个模块。核心记录的是轨道怎么组织、动画片段怎么衔接、怎么用Signal在特定时间点触发事件。Signal这块是很多人会漏掉的其实它非常实用——可以在动画的某一帧精确触发一个逻辑比如切换表情或播放音效。对话变化的角色表情驱动本质是对话系统 表情状态机的组合。我的笔记里记的思路是表情切换不要硬编码在对话脚本里而是让对话配置里带一个表情标识由独立的表情管理器去响应。这样改对话内容时不用动逻辑代码维护成本低很多。这种配置与逻辑分离的思路我在很多模块的笔记里都反复强调它是工程可维护性的关键。5. 平台发布与跨端开发的笔记分区5.1 微信小游戏打包与视频播放微信小游戏打包是这两年问得最多的方向之一。我的笔记里把它作为独立的平台模块记录打包流程、包体限制、以及常见的适配问题。包体控制是重中之重小游戏对初始包体大小有硬性要求所以资源分包、按需加载这些策略必须提前规划不能等打包报错才想起来。小游戏里的视频播放是个典型的平台特例。我的笔记里明确记了不能直接照搬原生平台的视频播放方案小游戏环境有自己的一套视频接口和限制包括视频层级、播放格式、以及和UI的层级关系。这块的坑在于编辑器里预览正常真机小游戏里视频层级压不住UI或者根本无法播放。所以我的笔记要求平台特例类的知识点必须标注验证环境避免误用。5.2 Web部署到IIS与其他发布目标发布到Web并部署到IIS这块我的笔记记录的是构建产物的目录结构、服务端需要配置的响应类型、以及常见的加载失败原因。WebGL的坑集中在资源加载路径和压缩格式上服务器如果没有正确配置响应头构建出来的文件浏览器拒收页面上就是白屏。我笔记里把必须配置的几个响应类型列成清单部署时逐条核对。其他发布目标我按平台分了组移动端、桌面端、Web各一组每组记录构建设置里的关键选项和平台特有的注意事项。这样分组的好处是做新平台适配时可以先看同组其他平台的经验很多坑是相通的。5.3 XRPico4与MR/VR切换XR这块我单独开模块记录Pico这类设备上的开发要点。核心经验是设备上的性能和渲染限制比PC严格得多帧率是硬指标所以项目在PC上跑得再流畅也不能想当然地认为设备上没问题。我的笔记里记录了针对移动XR设备的优化清单以及双眼渲染带来的额外开销。MR和VR之间的模式切换我记录的是运行时的切换流程和需要注意的资源重建问题。这类内容比较新我的笔记习惯是每次实践后立刻补录因为资料少靠记忆很容易丢细节。6. 性能优化与工程化的笔记6.1 优化清单与限定数据块大小性能优化我建议单独建一个大模块因为它横跨渲染、逻辑、资源各个方向。我的笔记里维护着一份优化清单按优先级排列先看DrawCall和批次再看填充率再看逻辑层的每帧计算。为什么要按这个顺序因为渲染瓶颈在移动端通常比逻辑瓶颈更致命先解决大头收益最高。限定数据块大小这类优化点指的是对批量处理的数据做分块避免单帧处理量过大导致卡顿。我的笔记里记录的是分块的思路和阈值经验比如资源加载不要一次性同步加载大批文件而是拆成若干批分帧处理避免主线程长时间阻塞。分块粒度需要根据实测调整太细反而增加调度开销太粗起不到作用。提示优化前后一定要用真实设备实测并记录帧率数据不要凭感觉判断变快了感觉极不可靠。6.2 工程化混淆与GameAssembly.dll工程化模块记录的是发布环节的加固和构建机制。代码混淆是上线前的常规操作我的笔记里记录了混淆的目 Unity学习笔记目录体系：从散乱文件到可检索知识地图
做Unity这行几年下来我最怕的不是某个API记不住而是回头翻自己三年前写的笔记发现根本找不到当时那条摄像机跟随抖动的解决方案到底存在哪个文件夹里。相信很多人跟我一样笔记从最初的新建文件夹(2)一路演化成Unity_学习_2019_不要删_重要最后连自己都不想打开。这篇内容就是把我这些年积累的Unity学习笔记按一套可检索、可扩展的目录体系重新整理出来——它不只是一份索引更是把散落在渲染、UI、平台发布、性能优化各个角落的知识点重新串成一条线。不管你是刚装好编辑器的新手还是已经做过几个上线项目的开发者这套目录结构和里面标注的实操要点都能帮你少走弯路尤其是那些官方文档不会告诉你的取舍细节。1. 为什么Unity笔记需要一份目录而不是一堆散文件1.1 笔记失控的真实代价我在带新人的时候发现一个规律大多数人记笔记的方式是按遇到问题的时间顺序来存的而不是按知识的结构关系来存的。今天调了个阴影新建一篇《阴影问题记录》明天研究微信小游戏视频播放再建一篇《视频播放踩坑》。半年之后当你想系统性回顾渲染相关的知识时发现这些笔记散落在十几个文件里彼此之间没有任何横向联系检索基本靠全文搜索碰运气。这种散乱带来的直接损失是知识的复用率极低。一个你明明解决过的问题因为没有归类下次遇到时又得从头查一遍时间全浪费在重复劳动上。更深层的损失是你无法看清自己在哪个方向上有系统性缺口。笔记目录其实就是你知识地图的投影——地图乱说明你的认知也是碎片的。提示判断自己的笔记是否失控有个简单标准——如果你的笔记里超过三次出现内容高度重复的条目说明归类体系该重建了。1.2 三层目录结构的设计逻辑我这套目录采用的是领域 → 模块 → 知识点的三层结构跟Unity自身的引擎架构大致对应。第一层是大的领域划分比如引擎基础、渲染图形、UI交互、平台发布、性能优化、工程化第二层是每个领域下的功能模块第三层才是具体知识点的单篇笔记。为什么按领域而不是按难度或时间分因为实际工作中问题几乎总是以领域的形态出现的——你调一个渲染问题会在Shader、阴影、包围盒这几个知识点之间来回跳它们应该待在同一个区域里而不是被时间线打散。按领域归类等于把关联性强的知识放在物理上相邻的位置检索时的跳转成本最低。另外一个设计原则是预留空目录。我一开始只建了四五类后来又不断往回收拾结果每次都要重新移动文件。后来学乖了一开始就把已知会碰到的领域全部建出来哪怕某些目录暂时是空的。空目录本身就是一种提醒——它告诉你这里还有一块知识没去碰。目录层级划分依据典型子项举例第一层知识领域渲染、UI、平台、优化、工程化第二层功能模块Shader、摄像机、打包、混淆第三层具体知识点单篇问题记录或方案总结2. 引擎基础与工程环境的笔记归档2.1 安装、版本与项目骨架引擎基础这块我把安装与版本管理单独拉出来作为第一模块。别小看这块Unity的版本迭代很快不同版本对同一功能的支持差异能让你怀疑人生。我的笔记里专门有一节记录各版本的关键差异和升级踩过的坑尤其是跨大版本升级时那些能被编译但运行时行为变了的隐性变更这些在升级日志里往往只有一句话但实际影响很大。项目骨架结构也是新手最容易忽略的部分。我在笔记里固定记录了一套标准目录约定资源放哪里、脚本怎么按模块拆文件夹、第三方插件单独隔离、场景文件命名规范。这套约定的价值在多人协作和后期维护时才真正显现——一个结构清晰的项目接手的人半小时就能上手一个乱堆的项目光是找入口场景就得花半天。关于下载和安装我只记录官方渠道的获取方式以及安装时组件勾选的经验移动平台支持、WebGL支持这些模块体积很大用不到的别装装了会让编辑器启动变慢也占硬盘。我试过全量安装结果启动时间比精简安装慢了一截后来只保留当前项目用得到的模块。注意升级引擎版本前先备份整个工程目录不要只依赖版本控制系统的历史记录因为有些资源导入缓存不在版本管理范围内回退时会出问题。2.2 C#脚本与Unity特有机制脚本这块的笔记我按语言基础和引擎特有机制分开记。语言基础指的是C#本身的语法、面向对象、委托事件、协程原理这些这部分是通用的我单独用一个模块避免跟Unity特有的东西混在一起。很多人把C#基础和Unity API记在一块结果复习语言时被引擎细节干扰效率很低。引擎特有机制才是重头戏我记录的核心是脚本生命周期函数的执行顺序、特性Attribute的用法、宏定义的条件编译这几块。生命周期顺序看着简单但实际调试时Update和FixedUpdate的执行时机差异、Awake和Start的先后关系经常是bug的根源。我在笔记里画了一张自己的时间轴把这个顺序固化下来遇到问题时直接对照。宏定义这块特别实用。用条件编译可以在同一个工程里区分开发版和发布版比如调试日志只在开发版里输出。我在笔记里记了几个常用宏的写法以及怎么在编辑器里切换生效这样打正式包时不用手动删代码。知识点速查区我还会收录一些容易忘但有明确答案的概念比如渲染器包围盒Renderer.bounds到底包不包含子物体、它和碰撞体的关系是什么。这类问题查一次忘一次放进速查区下次直接翻不用重新搜。还有像Mathf.PerlinNoise这种噪声函数我笔记里记的是它的输出范围、参数含义以及在生成地形或纹理时怎么配合使用这类工具函数属于知道在哪查就行的知识。2.3 基础概念速查区的维护方法速查区最忌讳的是把它写成流水账。我个人的做法是每条只保留一句话结论 一个最小示例 一个常见误解。比如包围盒那条结论就是它描述的是渲染器的轴对齐包围盒示例是获取中心点和尺寸的代码常见误解是有人以为它随旋转实时紧贴——实际上它是轴对齐的物体旋转后包围盒会变大而不是跟着转。速查区我建议每季度清一次。过时的、已经内化成直觉的条目可以删掉给新知识腾位置。笔记不是越多越好能快速定位到有用信息才是目的。这个习惯我是从踩坑里养成的曾经速查区堆了两百多条结果找东西比重新搜还慢反而成了负担。3. 渲染、Shader与视觉表现的笔记体系3.1 摄像机、分辨率与包围盒渲染这块我第一个模块放的是摄像机因为它是所有视觉呈现的入口。摄像机跟随是使用频率极高的功能我的笔记里记了三种常见跟随方案直接赋值位置、平滑插值、以及带前瞻的阻尼跟随并标注了各自的适用场景。直接赋值简单但会抖平滑插值稳但有延迟感阻尼跟随在快速移动时手感最好但参数需要调。笔记里我把关键参数的含义和调参方向都写清楚了而不是只丢一段代码。分辨率设置是另一个高频问题。不同平台、不同屏幕比例下的适配方案我按固定高度固定宽度两者都固定并处理黑边三种策略分别记录还附上了横竖屏切换时要额外注意的点。这块的坑在于编辑器里看着正常真机上一测就错位所以我的笔记强制要求每条分辨率相关的结论都标注在哪个平台哪个设备上验证过。3.2 Shader与阴影问题Shader的笔记我建议单独开一个大模块因为它自成一个体系。入门阶段记录的是渲染管线的基本流程、顶点着色器和片元着色器的分工、常用内置变量的含义。进阶部分才开始记录自定义光照、边缘光、描边这类常见效果的实现思路。阴影问题几乎是每个Unity开发者都会反复碰到的。我的笔记里把阴影问题拆成几类阴影不显示、阴影闪烁、阴影边缘锯齿、以及阴影距离过远时突然消失。每一类都记录了可能的原因和排查顺序。比如阴影闪烁常见原因是阴影偏移参数设置不当或者物体的包围盒过小导致被裁剪排查时我会先看这几个参数而不是盲目改阴影质量。这种按现象归类、按顺序排查的记录方式比单纯记解决方案有用得多因为现象是有限的而具体的解决方案是无限的。提示阴影排查时先关闭所有后处理再看基础阴影能排除掉一半的干扰因素。3.3 视觉细节技巧的沉淀除了核心渲染我还会专门留一块记那些锦上添花的视觉技巧比如物体逐渐消失的脚本控制、对话过程中角色表情的变化驱动、以及天气效果的动态浮动。这些效果单看都不难但组合起来能显著提升项目的完成度。以物体逐渐消失为例我的笔记里记了两种实现思路一是改材质的透明度二是改透明通道并配合淡出曲线。前者简单但受材质混合模式限制后者更灵活但需要处理渲染顺序。笔记里我把两种方案的代价都写明了方便按项目需求选。这类笔记的价值在于它把你零散试出来的经验固化了下次不用重新试错。4. UI、交互与输入的笔记整理4.1 UI显示隐藏三种方案的取舍UI显示隐藏到底该用哪种方式这个问题几乎每个Unity开发者都纠结过。我把SetActive、改localScale、以及把物体移出相机可视范围这三种方案单独做成一节对比笔记因为这三种方式的性能代价和使用场景完全不同。SetActive的优点是彻底隐藏后相关组件不再执行适合隐藏后短时间内不会再显示的元素缺点是频繁切换会有开销因为它涉及组件的启用停用和层级重建。改localScale的优点是切换极快不涉及层级变化缺点是物体还在场景里参与部分计算而且如果有布局组件可能会出问题边界情况多。移出相机范围则是折中方案物体保持激活但不可见适合需要保留状态的场景切换。我的笔记里给了一个选择判断表高频切换且需保留状态用移出相机或缩放低频切换且想释放开销用SetActive。这种把决策逻辑写下来的方式比单纯记三个API有用得多。方案切换开销是否保留状态适用场景SetActive较高否低频、可释放的元素改localScale低是高频切换、动画过渡移出相机范围低是需保留状态的界面切换4.2 按钮点击范围与交互细节按钮点不准是移动端项目的高频投诉点。我的笔记里记了一条视觉上的按钮大小和实际可点击区域是两回事实际响应区域由控件的射线检测区域决定。扩大点击范围的做法是在按钮边缘补一个透明的响应区域或者调整控件的目标图形设置。笔记里特别强调扩大范围时要考虑相邻按钮的间距否则会误触。交互这块我还记录了输入系统的两类方案老输入系统和新输入系统以及它们各自的适用场景。新输入系统更灵活支持多设备重绑定但对新手来说学习曲线陡。我的建议是按项目需求选别为了先进而强行上新系统简单项目用老的完全够。4.3 Timeline、对话与表情驱动Timeline是做过场动画和剧情演出的利器我的笔记里把它单独作为一个模块。核心记录的是轨道怎么组织、动画片段怎么衔接、怎么用Signal在特定时间点触发事件。Signal这块是很多人会漏掉的其实它非常实用——可以在动画的某一帧精确触发一个逻辑比如切换表情或播放音效。对话变化的角色表情驱动本质是对话系统 表情状态机的组合。我的笔记里记的思路是表情切换不要硬编码在对话脚本里而是让对话配置里带一个表情标识由独立的表情管理器去响应。这样改对话内容时不用动逻辑代码维护成本低很多。这种配置与逻辑分离的思路我在很多模块的笔记里都反复强调它是工程可维护性的关键。5. 平台发布与跨端开发的笔记分区5.1 微信小游戏打包与视频播放微信小游戏打包是这两年问得最多的方向之一。我的笔记里把它作为独立的平台模块记录打包流程、包体限制、以及常见的适配问题。包体控制是重中之重小游戏对初始包体大小有硬性要求所以资源分包、按需加载这些策略必须提前规划不能等打包报错才想起来。小游戏里的视频播放是个典型的平台特例。我的笔记里明确记了不能直接照搬原生平台的视频播放方案小游戏环境有自己的一套视频接口和限制包括视频层级、播放格式、以及和UI的层级关系。这块的坑在于编辑器里预览正常真机小游戏里视频层级压不住UI或者根本无法播放。所以我的笔记要求平台特例类的知识点必须标注验证环境避免误用。5.2 Web部署到IIS与其他发布目标发布到Web并部署到IIS这块我的笔记记录的是构建产物的目录结构、服务端需要配置的响应类型、以及常见的加载失败原因。WebGL的坑集中在资源加载路径和压缩格式上服务器如果没有正确配置响应头构建出来的文件浏览器拒收页面上就是白屏。我笔记里把必须配置的几个响应类型列成清单部署时逐条核对。其他发布目标我按平台分了组移动端、桌面端、Web各一组每组记录构建设置里的关键选项和平台特有的注意事项。这样分组的好处是做新平台适配时可以先看同组其他平台的经验很多坑是相通的。5.3 XRPico4与MR/VR切换XR这块我单独开模块记录Pico这类设备上的开发要点。核心经验是设备上的性能和渲染限制比PC严格得多帧率是硬指标所以项目在PC上跑得再流畅也不能想当然地认为设备上没问题。我的笔记里记录了针对移动XR设备的优化清单以及双眼渲染带来的额外开销。MR和VR之间的模式切换我记录的是运行时的切换流程和需要注意的资源重建问题。这类内容比较新我的笔记习惯是每次实践后立刻补录因为资料少靠记忆很容易丢细节。6. 性能优化与工程化的笔记6.1 优化清单与限定数据块大小性能优化我建议单独建一个大模块因为它横跨渲染、逻辑、资源各个方向。我的笔记里维护着一份优化清单按优先级排列先看DrawCall和批次再看填充率再看逻辑层的每帧计算。为什么要按这个顺序因为渲染瓶颈在移动端通常比逻辑瓶颈更致命先解决大头收益最高。限定数据块大小这类优化点指的是对批量处理的数据做分块避免单帧处理量过大导致卡顿。我的笔记里记录的是分块的思路和阈值经验比如资源加载不要一次性同步加载大批文件而是拆成若干批分帧处理避免主线程长时间阻塞。分块粒度需要根据实测调整太细反而增加调度开销太粗起不到作用。提示优化前后一定要用真实设备实测并记录帧率数据不要凭感觉判断变快了感觉极不可靠。6.2 工程化混淆与GameAssembly.dll工程化模块记录的是发布环节的加固和构建机制。代码混淆是上线前的常规操作我的笔记里记录了混淆的目