我的硬盘里现在躺着四十多个 Unity 工程从最早那个连摄像机都不会摆的 Demo到后来接手的数字孪生项目、微信小游戏、还有几个 VR 一体机上的实验。真正让我难受的不是工程多而是笔记散有的记在工程根目录的 txt 里有的躺在聊天记录里有的只存在于我脑子里过三个月再遇到同一个阴影发黑的问题还得从头查一遍。所以上个月我花了两天时间把 Unity学习笔记 全部推翻重做了一遍从想到什么记什么改成一套有骨架、能检索、能持续回填的目录体系。这篇就聊聊这套目录是怎么搭的、每一层该记什么、哪些条目是我踩过坑之后才补进去的以及这套结构为什么比按功能模块平铺要好用得多。不管你是刚开始学 Unity 的新手还是已经做过两三个项目、想把自己的经验沉淀下来的开发者这套组织方式都可以直接抄走改成自己的版本。1. 目录先分层再分册为什么我放弃了按功能模块平铺的旧目录1.1 旧目录的三个致命问题我最早的笔记目录长这样动画、UI、渲染、物理、脚本、优化、插件……看上去挺整齐实际上用起来非常痛苦。第一个问题是条目归属模糊。比如按钮点击范围扩大这件事它既算 UI 又算交互还能扯到射线检测我每次都不知道该往哪个文件夹里塞最后就变成随手丢。第二个问题是层级太浅。所有东西都是平级的一个优化文件夹里堆了六十多条笔记找的时候跟翻垃圾堆一样。第三个问题最要命没有时间轴。学习是有顺序的先会装编辑器、再会写脚本、然后才谈得上渲染和优化但平铺目录把这条顺序彻底抹平了新人打开一看全是陌生名词直接劝退。1.2 四层骨架工具链层、基础层、表现层、交付层重做之后我换成了四层结构核心逻辑是按我在项目里处在哪个阶段来分而不是按这是引擎的哪个模块来分。工具链层管的是环境本身装哪个版本、Hub 怎么用、工程目录里哪些东西不能删基础层管的是写代码这件事生命周期、C# 底子、场景对象的日常操作表现层管画面渲染、Shader、UI、相机、特效交付层管上线打包、部署、混淆、优化。这四层的好处是任何一个具体问题你都能顺着我现在在干什么快速定位到层再在层里找册。比如微信小游戏里视频播不出来这明显属于交付层里的打包分册而不是 UI 分册归属问题一下就解决了。另外四层天然带顺序新人从第一层往下读就是一条完整的学习路径。1.3 每条笔记的最小单元格式光有目录不够每条笔记本身也得有固定格式否则三个月后你连自己写的是什么意思都看不懂。我固定的字段是五个现象、环境、原因、解法、验证。现象用一句话写清症状比如SkinnedMesh 角色在屏幕边缘突然消失环境写引擎版本和渲染管线因为 URP 和内置管线的行为经常不一样原因写机制层面的解释哪怕当时没完全搞懂也要留个 TODO解法贴代码或截图验证写清楚怎么确认问题真的解决了。额外加一个关联字段指向相关的其他条目这样笔记之间能连成网。我实测下来坚持写原因这一栏是收益最大的因为它逼着你去查机制而不是停在改了某个参数就好了。2. 工具链层笔记安装、版本、工程结构与那些一次配好就不想再碰的设置2.1 版本与安装Hub、LTS、Intel Mac 与语言包工具链层第一条笔记永远是安装。我的记录方式是把版本选择当成一个决策表来记而不是记操作步骤。选版本的原则很简单新项目优先选最新的 LTS因为 LTS 有长期维护第三方插件兼容性也最好老项目保持原版本不要动升级引擎带来的收益往往抵不上修兼容问题的时间成本。安装环节我推荐用 Hub 统一管理不要单独下载离线安装包到处装否则同一台机器上三四个版本混在一起哪天空闲时想删都找不到路径。安装时把Android Build SupportWebGL Build Support这类模块按需勾选用不到的先别装模块装多了 Hub 的磁盘占用会非常夸张。Mac 用户有额外的坑。Intel 芯片的 Mac 上装较新的编辑器版本时要留意官方对 Intel 平台的支持节奏有些新版本在 Intel 机器上的编辑器体验会明显慢于 Apple Silicon我一般在 Intel Mac 上会保守地停在 2022.3 系列的稳定补丁版本。安装完成后在偏好设置里把语言切成简体中文这一步很多新手不知道翻半天菜单找中文包。另外顺手把脚本编辑器关联好我习惯用 Rider 或 VS Code关联好之后双击脚本能直接跳转省掉每天几十次的手动打开。2.2 工程结构Assets 之外的隐藏主角第二个大类是工程结构。绝大多数人的笔记里只记 Assets 文件夹其实真正决定工程能不能被别人接手的是 Assets 之外的那几个目录和文件。我的笔记里固定记录这几项ProjectSettings存的是项目级配置包括输入、图形、物理、标签层这个目录一定要进版本管理Packages里的 manifest.json 决定依赖了哪些包出问题时第一件事就是看它Library和Temp绝对不能进版本管理它们是缓存几千个文件会让仓库爆炸。还有一点很多人不知道工程目录名带中文或空格会在某些平台打包时出问题所以我在笔记里直接写明工程路径只允许英文、数字、下划线。2.3 GameAssembly.dll、宏定义与特性三个最容易被问到的冷知识工具链层里我专门留了一册叫冷知识收的都是那种平时用不上、但一旦被问到或者出问题就很致命的东西。GameAssembly.dll属于这一册。它是 IL2CPP 后端把 C# 转成 C 再编译出来的原生代码产物换句话说你的游戏逻辑最终就住在它里面。理解了这一点很多事情就顺了为什么 IL2CPP 打包比 Mono 慢很多、为什么有些反射代码在移动端会失效、为什么做代码保护时大家都会盯着这个文件。宏定义是我建议每个人都要花十分钟搞明白的东西。代码里那些#if UNITY_EDITOR、#if UNITY_ANDROID的写法本质是编译期裁剪没命中的分支根本不会进包。我在笔记里整理了一张常用宏的对照表标注每个宏在什么平台下生效、能不能在 Player Settings 的 Scripting Define Symbols 里自己加。自定义宏的价值在于做功能开关比如把付费模块、调试面板整体包在一个宏里出正式包时一键剔除比重构代码省事得多。特性这一条我记的是几个真正会用的而不是把所有 Attribute 抄一遍。常用的就那几个[SerializeField]把私有字段暴露到 Inspector比写 public 干净[RequireComponent]保证依赖组件不会被人误删[ExecuteAlways]让脚本在编辑器里也跑[Header]和[Range]纯属提升 Inspector 可读性团队协作时很值。我在笔记里加了一句提醒[ExecuteAlways]用不好会让编辑器不断刷新严重的会卡到无法操作加之前先想清楚。条目关键词一句话记忆点GameAssembly.dllIL2CPP 产物逻辑最终都在这里反射失效先想它宏定义编译期裁剪没命中的分支不进包可用于功能开关特性元数据只记常用的五个别当字典背3. 基础层笔记脚本、C# 底子与场景对象的日常操作3.1 生命周期与执行顺序笔记里必须画的那张表基础层最重要的一条笔记是生命周期与执行顺序。我不建议只抄文档里的顺序图而是记**什么时候必须用哪个**的对应关系。Awake做自身初始化OnEnable做事件订阅Start做依赖其他对象的初始化Update处理输入和逻辑FixedUpdate处理物理LateUpdate处理跟随相机和 IK。这里面有个非常经典的坑所有跟相机有关的位移一定要放LateUpdate因为角色位移在Update里算完如果相机也在Update里跟随你看到的就会是一帧抖动。我把这条写在最显眼的位置因为我自己因为这个原因排查过两个下午。还有一个执行顺序相关的细节值得记脚本之间的执行顺序默认是随机的需要固定顺序时用Script Execution Order面板或者用事件中心解耦。我在笔记里标注了一句话——依赖执行顺序本身就是设计问题能用事件解决就不要靠顺序面板。3.2 八股整理法把面试题变成索引而不是背诵清单面试题和 C# 八股这类内容网上到处都是但我发现直接抄一份清单进笔记是没用的因为背诵清单和自己理解的笔记完全不是一回事。我的做法是只记我自己解释得出来的条目解释不出来的先标红待补。比如协程我笔记里写的不是协程是基于 IEnumerator 的而是这样一段协程本质是一个返回 IEnumerator 的方法Unity 在每一帧调用它的 MoveNext遇到 yield 就记下当前状态并暂停条件满足后继续。所以它运行的时机是在 Update 之后、LateUpdate 之前而且它不是在多线程里跑的阻塞操作放进协程一样会卡主线程。GC 这一条我也记得比较细值类型在栈上、引用类型在堆上装箱会把值类型搬到堆上频繁装箱是 GC 压力的常见来源。字符串拼接、每帧new数组、在 Update 里用 LINQ这几个都是我实际遇到过导致掉帧的写法。值类型和引用类型、String 和 StringBuilder、委托与事件、接口和抽象类的取舍这几条我都写成了什么时候用哪个的形式比背定义有用得多。3.3 不用脚本也能隐藏组件的几种做法与它们各自的下场在编辑器里不写代码就隐藏掉某些东西是很多人会问的问题我的笔记里把可行方案和代价一起记下来了因为这里面没有免费午餐。第一种是编辑器层面把对象或组件临时隐藏。场景视图的可见性开关、Inspector 上的折叠、Prefab 变体的覆盖开关都属于这一类。好处是完全不影响运行时代价是实现不了任何运行时行为纯属编辑期方便。第二种是用图层的 Culling Mask把对象放到一个相机不渲染的层上或者直接让主相机的 Culling Mask 排除它。这种方式的关键优势是对象还在场景里脚本照样能访问到它做逻辑上存在但视觉上不出现的需求很合适。第三种是HideFlags运行时不渲染也不参与保存但注意它是代码层面的东西绕了一圈还是要写脚本。我的结论写在笔记末尾真正意义上的不写代码就隐藏只适合做编辑期整理只要涉及运行时的显示与隐藏就一定得写逻辑区别只在于用哪种方式写代价更小。4. 表现层笔记渲染、Shader、UI 与相机里那些反复踩的坑4.1 Renderer 的包围盒模型忽然消失的头号嫌疑表现层里我踩得最深的一个坑是 Renderer 的包围盒。现象是角色在画面边缘时突然整个消失转身或者挪回去又出现看上去像是渲染坏了实际上是被视锥体剔除掉了。原因在于 Unity 用 Renderer 的包围盒来判断这个物体在不在相机视野内而蒙皮网格的包围盒是烘焙的如果动画幅度超过了烘焙范围、或者包围盒被算得太小剔除就会发生在错误的位置。我把两种边界记在了笔记里bounds是世界空间的轴对齐包围盒用来做剔除判断localBounds是模型空间的可以手动设置。解决办法就是给需要大幅度变形的对象手动扩大localBoundsvoid Start() { var r GetComponentRenderer(); // 留出足够余量宁可稍微多渲染也不要闪消失 r.localBounds new Bounds(Vector3.zero, Vector3.one * 10f); }这条笔记我额外补了一句经验包围盒给大了会影响剔除效率所以不要无脑给一个特别夸张的值测试时就按动画最大位移的 1.5 倍来设。这个坑还有个变种就是特效粒子系统在大范围移动时同样会闪消失原理一样。4.2 阴影、分辨率与相机三个参数决定画面下限阴影问题的表现特别多边缘锯齿、条纹状的摩尔纹、物体上出现诡异的黑斑、近处有阴影远处没有。我在笔记里按表现分类记录条纹和摩尔纹多半是深度精度问题调Bias和Normal Bias近处有远处没有基本是Shadow Distance设小了整体发黑或者不发光要看光源的阴影类型和强度。移动端还有个额外限制阴影贴图的级联数量越多开销越大我一般在中端机型上只用两级。分辨率设置这一条我记的重点不是 API 本身而是什么时候该动它。Screen.SetResolution在 PC 端做窗口化、做分辨率选项列表时很有用但移动端千万不要手动改交给系统就行。真正需要记录的坑是UI 适配Canvas Scaler 的参考分辨率和匹配方式选错会导致某些机型上 UI 被拉伸或者被裁掉。我的经验是按主流比例设参考分辨率匹配模式优先选按高度匹配因为竖屏游戏和横屏游戏对高度的敏感度不一样横屏通常更在意高度。相机跟随这条我写了一段可直接用的代码并且特意注明为什么用SmoothDamp而不是Lerppublic Transform target; public Vector3 offset new Vector3(0f, 2f, -5f); Vector3 vel; void LateUpdate() { // SmoothDamp 与帧率无关Lerp 在不同帧率下速度会变 transform.position Vector3.SmoothDamp( transform.position, target.position offset, ref vel, 0.15f); }顺带在笔记里记了一个边界情况如果目标对象在FixedUpdate里移动相机放在LateUpdate仍然会出现轻微抖动这时候要么把目标移动也统一到Update要么开启相机的插值。4.3 UI 的显示隐藏之争SetActive、CanvasGroup、localScale、移出相机这是我看过最多人争论的问题我的笔记里干脆做成了一张对照表写清每种方式的代价而不是给一个标准答案。因为答案真的取决于你要什么。方式主要开销能否参与布局适用场景SetActive首次激活有实例化与重建成本会触发布局重算不参与大面板、低频切换CanvasGroup.alpha几乎无抖动但元素仍在渲染与参与射线检测参与高频淡入淡出CanvasGroup.interactable不控制视觉只控制交互参与只做禁用交互localScale 置零会触发布局重算且 scale 为 0 时可能有除零风险参与简单缩放动画移出相机可视范围不改动层级但仍在渲染队列里参与不想打断动画的临时隐藏我实际项目里的默认策略是高频切换用 CanvasGroup 配合blocksRaycasts低频的大面板切换用 SetActive。因为 SetActive 关掉之后会触发合批重建如果每帧都在开关一个复杂面板帧率会肉眼可见地掉。还有一个细节很多人忽略CanvasGroup.alpha 0时对象依然参与射线检测如果你只是想让玩家看不到但还能被点这是特性如果不想被点一定要记得同时把blocksRaycasts关掉。4.4 按钮点击范围与 Tooltip交互手感的两件小事按钮点击范围太小是移动端最常被吐槽的问题。我的笔记里记了三种做法按侵入性从低到高排列最简单的是在按钮下加一张完全透明的 Image勾上Raycast Target靠它把热区撑大第二种是把按钮的 Image 换成不透明的纯色再把透明度降下来视觉上没变化但热区按实际尺寸算第三种是自定义组件重写射线检测能做不规则热区适合做圆形按钮。有个小坑必须记下来用图片的 alpha 来决定是否响应点击时需要纹理开启可读运行时会多一份内存拷贝图集里的大图这么干会明显吃内存。所以除非真的需要不规则热区否则优先用透明 Image 的方式。Tooltip 这类小功能我记的是别自己造的思路如果只是想在编辑器里给美术和策划写备注内置的 Tooltip 和自定义 Inspector 就够了如果要的是运行时鼠标悬停提示社区里有现成的轻量插件与其花两天写一个还不如直接用。这一册我特意标注了每条笔记是自己写的还是用的现成方案避免半年后自己都忘了哪个模块是第三方代码。4.5 Shader、Timeline、PerlinNoise 与程序化内容的笔记组织Shader 的笔记我单独开了一册因为它的知识结构跟其他部分完全不同。我的组织方式是效果反查原理先按效果分类描边、溶解、水面、卡通渲染、热扰每个效果下面记实现思路和关键代码片段而不是按语法章节整理。因为实际工作中你是先有需求才去找语法反过来记的话几乎用不上。性能提醒我也记在每一条里片元着色器里的分支代价高能用数学替代就别用 ifpow、sin这些函数在移动端要节制使用。Timeline 我记的重点是它和 Animator 的边界Timeline 适合做线性编排比如过场、剧情、镜头切换Animator 适合做状态机比如角色的移动、攻击、受击切换。两者混用时容易出现Timeline 播完角色卡在某个姿势多半是 Track 的绑定和 Animator 的权重没处理好。我还记了一个实用技巧Timeline 的轨道可以绑定到场景对象上如果绑定的是 Prefab 里的对象建议用变量引用而不是硬编码路径改结构时不会全崩。程序化内容这块Mathf.PerlinNoise是最常被记的一个。它的返回值在 0 到 1 之间输入相同的坐标永远得到相同结果所以很适合做地形、云层、随机分布。我记了两个坑一是采样频率要控制频率太高会变成噪点太低会看到明显的块状二是它的周期性问题做无缝贴图时需要按周期取模采样否则接缝会露馅。// 用两个不同频率叠加得到更有层次的地形高度 float h Mathf.PerlinNoise(x * 0.05f, y * 0.05f) * 0.7f Mathf.PerlinNoise(x * 0.2f, y * 0.2f) * 0.3f;角色表现这一类里SkeletonUtilityBone我也收了进来。它属于骨骼工具链的一环主要用途是把挂点、特效、武器这些需要跟随骨骼的东西绑到骨架上避免每帧手写代码去同步位置。我的笔记里写清了它的适用前提是骨架结构完整并且提醒了性能挂点数量多的时候会有额外开销能用父子关系解决的不要用逐帧同步。类似的还有根据对话变化表情我的方案记录是表情用 BlendShape 或贴图切换配合状态机驱动来源是数据配置而不是硬编码这样策划改对话时不用改代码。5. 交互与空间计算层VR/MR、数字孪生、地图与硬件通信5.1 Pico4 开发与 MR/VR 切换的笔记要点一体机开发这一册是我最近补得最多的。Pico4 这类设备的开发流程我记录成了一条固定链路安装设备厂商的 Unity 集成包、在 XR 插件管理里启用对应平台、配置项目为 Android 平台并设置最低 API 等级、处理渲染管线兼容URP 基本是必选项、然后才是写业务逻辑。这里最容易漏的是着色器变体一体机上的渲染路径和 PC 端不一样某些在 PC 上跑得好好的材质打包到设备上直接变粉或者变黑所以我在笔记里写了一条硬规则——所有材质上设备前必须实机验证。MR 和 VR 的切换我单独记了一条。VR 是纯虚拟画面MR 要在画面里叠加真实世界的透视画面。技术上通常体现为相机背景的处理方式不同以及是否需要开启设备的透视能力。切换时的典型问题是透视画面和虚拟物体的对齐偏差需要校准相机参数并且注意不同设备的透视能力开放程度不一样。我的笔记里明确写了不要假设所有设备都支持同一个功能一定要先查能力清单这条经验帮我省过不少返工。5.2 Cesium for Unity 与离线地图别把瓦片服务器写进笔记就忘了数字孪生和地图类项目里Cesium for Unity 是绕不开的一环。我的笔记把它分成三块记数据格式、服务来源、性能代价。数据格式主要是 3D Tiles 和地形数据它们是分层的越靠近视点加载越细一级这也是它能承载大场景的原因。服务来源这块我写得很明确默认的在线服务需要网络和账号做内网部署或者断网场景时必须自建瓦片服务或者准备本地数据集这一步最好在项目立项时就确定下来不要等到验收前才发现环境没有外网。性能代价这块我记了几个实测数字分辨率调高一级内存和显存占用会明显上升倾斜摄影模型的三角形数量非常夸张必须做 LOD 和分块加载地形叠加多层影像时纹理带宽会成为瓶颈。我的笔记里还专门留了一条边界条件如果场景很小、只在室内其实完全没必要上这么大的方案普通的模型加贴图就够了用重型方案会让整个项目变复杂。5.3 串口通信System.IO.Ports 在 Unity 里的正确打开方式串口通信这一册属于偏硬件的方向做设备对接、展厅互动、工业可视化时会突然需要。核心写法很简单using System.IO.Ports; SerialPort port; void Start() { port new SerialPort(COM3, 115200, Parity.None, 8, StopBits.One); port.ReadTimeout 50; port.Open(); }但坑全在细节里。第一串口号在不同机器上不固定插入的顺序变了就会换号所以正式项目里要提供选择串口的界面或者按设备描述符去匹配。第二ReadLine这类同步读取会阻塞主线程直接放在Update里会让画面卡成幻灯片正确做法是开一个后台线程收数据再把数据丢进一个线程安全的队列主线程每帧取。第三Unity 的 API 兼容级别设置会影响System.IO.Ports的可用性如果在 PC 上跑得好好的切到别的平台报命名空间找不到先检查这个设置。第四Android 设备上的串口需要额外的权限和原生调用不能直接用 PC 上那套写法这条我在笔记里标成了红色。5.4 数字孪生与天气可视化数据驱动的场景组织数字孪生这类项目难点从来不是单个模型好不好看而是大量对象怎么组织和怎么驱动。我的笔记里记录了一套固定模式用配置表描述每个设备的唯一标识、模型路径、位置、需要绑定的数据字段运行时由数据层定时拉取或订阅数据通过唯一标识把数值分发到对应对象上对象自身只负责把数值映射成视觉表现比如温度映射成颜色、转速映射成旋转速度。这样组织的好处是加设备只改配置不动代码。天气可视化算是这个模式的一个具体应用。我的做法是把天气状态拆成几层天空盒或环境光、粒子效果雨雪、地面湿滑反光、以及 UI 上的数值展示每一层由一个独立的控制器驱动共用一个天气状态数据源。这样切换天气时只需要改一个状态值所有表现层自动跟着变。笔记里我把共用单一数据源这句话加粗了因为多个脚本各自维护一份天气状态是我见过最常见的状态不同步来源。6. 交付层笔记小游戏打包、Web 部署、混淆与优化清单6.1 微信小游戏打包、视频播放与广告接入小游戏这一册是整个目录里更新最频繁的因为平台侧的工具链一直在变。我的记录方式是每次成功打包后立刻回填包括转换插件用的哪个版本、引擎版本、需要在转换设置里勾哪些项、包体多大、首包加载多久。这些数字过两个月就是最宝贵的参考。视频播放是这一册里被问得最多的问题。我的笔记里写了几种方案的适用边界如果视频只是播个开场动画可以考虑转成序列帧或者直接内置短片如果必须播真实视频文件一般要借助平台提供的视频组件把它当作覆盖在画布之上的独立层来处理这时候要先想清楚层级关系、缩放和屏幕旋转带来的对齐问题以及用户点击穿透怎么处理。别指望用普通的视频纹理组件直接搞定在浏览器环境里视频纹理的限制比原生平台多。广告接入相对直接激励视频是最常用的一种。我的笔记里记了几个必查项广告的加载和展示是两个独立步骤必须等加载回调成功再展示直接调用会失败广告关闭后的奖励发放要区分完整观看和中途关闭测试阶段一定要用测试广告位正式广告位在测试机上刷多了容易触发风控。这几条每一条我都踩过。环节最容易出错的地方我的处理方式打包转换插件版本与引擎版本不匹配固定版本组合写进笔记不再随意升级视频播放层级与缩放对不齐独立层处理锁定横竖屏策略激励广告未等加载完成就展示严格走回调测试用测试广告位首包体积资源未做拆包按场景拆分包先跑通再优化6.2 WebGL 部署到 IIS缓存、压缩与跨域WebGL 发布到 IIS 这一册我踩的坑集中在服务器不认文件类型上。WebGL 的构建产物里有.wasm、.data、.js这些文件IIS 默认的 MIME 类型表里不一定都有缺失的话浏览器请求回来是 404 或者以错误类型解析页面白屏。解决办法是在站点的配置里显式添加 MIME 映射.wasm映射为application/wasm。第二个坑是压缩。构建产物里的.js.gz、.wasm.br这类预压缩文件需要服务器正确声明内容编码否则浏览器拿到的还是压缩后的二进制流直接报解析错误。我的笔记里记了一条检查清单MIME 类型、内容编码、静态压缩开关、以及是否需要关闭动态压缩避免二次压缩。第三个坑是跨域如果页面和数据文件不在同一个域名下需要配置跨域响应头。这一册我写了一句总结性的话WebGL 上线的问题九成在服务器配置不在代码每次遇到白屏先查服务器控制台的请求记录。6.3 混淆与 IL2CPP保护与代价代码保护这一册我保持理性记录因为我知道大概没有绝对安全的方案只有提高门槛。基本盘是使用 IL2CPP 后端脚本会被转成原生代码比 Mono 后端直接暴露 DLL 要好得多。在此之上再对生成的原生库做加壳或者加密处理能进一步提高逆向成本。混淆工具的笔记我记了两条关键约束一是混淆和反射天生冲突如果你的代码里大量使用字符串形式的反射调用、或者依赖序列化字段名混淆之后就可能失效所以要么给相关成员加排除规则要么改成非反射的实现二是混淆会拖慢构建、增加包体并且出问题时的堆栈信息会变得难以阅读因此我的建议是只在发布分支开启开发分支保持关闭。这一册里我还写了一句提醒与其花大力气防破解不如先把游戏本身做好成本收益完全不在一个量级。6.4 优化清单从 Profiler 到限定数据块大小优化这一册我做成了一份可以直接照做的清单按先测后改的顺序排列因为上来就凭感觉改代码是最常见的浪费。第一步永远是 Profiler看清楚到底是 CPU 卡还是 GPU 卡、是脚本耗时还是渲染耗时、内存峰值出现在加载阶段还是运行阶段。第二步针对结论动手CPU 卡先看合批和 DrawCall图集有没有正确合并、材质能不能共用脚本耗时高先找每帧分配字符串、数组、LINQ 都是嫌疑对象GPU 卡看分辨率、后处理、阴影距离。限定数据块大小这个说法我在笔记里展开成了具体的做法单个网格、单张纹理都不要做得过大超大的资源会带来加载时的内存峰值和卡顿也不利于分帧加载。我的经验值是单张纹理按平台选择压缩格式别拿一张原图一路用到底模型按场景拆分避免一个大文件里塞着整个场景。对象池也是清单里的固定项子弹、特效、飘字这类高频生成销毁的对象必须池化这条我标成了必做项。6.5 桌面美化与模型替换两个边缘但有趣的玩法桌面美化这一类是玩票性质但很有意思所以我也留了一册。基本思路是把 Unity 应用做成一个无边框透明窗口常驻桌面播放动画或者做互动。要注意的是窗口透明在不同系统上的实现方式不同而且这类应用对资源占用的要求比游戏更严格因为它要一直开着。我的笔记里写了一条实测体验这类项目最大的性能消耗往往是动画和特效把帧率降到 30 甚至 15肉眼几乎看不出来风扇声音小很多。模型替换我记的是资源热更场景下的做法用 AssetBundle 或者 Addressables 加载新的网格和材质替换掉当前角色的对应部分。这里的关键是骨骼要能对上如果新模型和旧模型的骨骼层级不一致蒙皮就会错位。我的笔记里写了一条硬性要求换模型的资源必须基于同一套骨架导出并且在导出多段动画时确认每一段的帧范围和根节点设置正确否则会出现换完模型动作乱飞的问题。7. 让目录活起来检索、复习与进阶路线7.1 命名与标签规范目录搭好只是开始真正决定它能不能用得久的是命名规范。我现在的规则很简单文件名用领域-具体现象比如渲染-蒙皮网格边缘消失不要用问题1笔记2这种。给每条笔记打标签标签分三类技术栈标签渲染、UI、打包、设备标签PC、Android、一体机、状态标签已解决、待验证、已知限制。这三类标签配合搜索基本能在十秒内定位到想要的条目比翻文件夹快得多。7.2 每周一次回填我给自己定了一个习惯每周花二十分钟把这一周踩过的坑补进目录只写现象和一句话结论也行细节等下次再遇到时补。这个习惯的价值在于笔记的质量是靠次数堆出来的。同一条条目我可能改过三四次第一次只记了现象第二次补了原因第三次补了代码第四次补了边界条件最后它才变成一条真正能帮到别人的内容。反过来如果攒到月底再写八成什么都想不起来了。7.3 进阶书单与全栈方向进阶这块我在目录里留了一册专门放输入源也就是书、课程和开源项目。书我推荐先啃渲染方向的经典和引擎原理方向的系统书前者能让你把 Shader 从抄代码变成自己写后者能让你理解引擎为什么这么设计。C# 语言本身也值得单独看一本系统的教材很多写了两三年 Unity 的人对语言特性的理解是碎的看一遍就串起来了。全栈这个方向我也记了一条路径客户端能力扎实之后往上补服务端和数据层理解通信协议、数据存储、并发和部署。这个方向的价值不在于多一个头衔而在于你接到一个联网需求时能自己想清楚数据怎么流、状态怎么同步而不是等别人给接口。我的目录里这一册目前最短但我知道它会慢慢变长——笔记本来就是跟着人走的人在往前走目录自然会跟着长。