本文件由 scripts/build_unity_note_index.py 自动生成,生成时间:2026-05-13。

用途:汇总 Unity 主题笔记中的核心知识点,便于从一个入口跳转到具体笔记。

笔记总览

核心知识点

Unity-Android-iOS平台问题笔记

  • 移动端问题通常发生在 Unity、原生 SDK、系统版本、商店政策和构建工具链的交界处。
  • Android 16 KB Page Size、SDK 版本升级、OpenURL 文件权限、ANR、Crashlytics 符号化都是发布前必须单独验证的风险点。
  • iOS 侧要重点关注符号表、Framework 链接、动态字体、UnityFramework 和原生插件兼容。
  • 平台问题不能只在 Editor 验证,必须用真机、Release 包、目标 ABI 和线上等价构建配置验证。

Unity-FMOD音频接入笔记

  • FMOD 接入重点不只是播放声音,还包括 Bank 打包、事件路径、平台格式、热更新、内存占用和生命周期管理。
  • ERR_EVENT_NOTFOUND 通常不是播放 API 本身的问题,而是 Bank 没加载、事件路径变更、GUID 不一致或构建产物没同步。
  • 移动端要特别关注 Bank 加载策略、Android 音频格式、热更新下载和内存峰值。
  • 音频系统需要和资源系统统一版本,不要让客户端代码、FMOD Studio 工程、Bank 文件和远端资源各自独立发布。

Unity-UGUI与UI工具笔记

  • UGUI 优化不是单点问题,通常要同时处理事件系统、布局重建、滚动列表复用、图集规范、字体资源和 UI 生产流程。
  • UI 工具链的核心目标是减少重复劳动:PSD 转 Prefab、批量检查组件、自动绑定代码、图文混排、图表控件和原型调试。
  • 高频 UI 的性能瓶颈常见于 Canvas 重建、Layout 递归计算、ScrollRect 大量实例化、字体纹理膨胀和过度使用 Mask。
  • 复杂 UI 项目应建立“资源规范 + Prefab 规范 + 自动检查 + 运行时复用”的闭环。
  • 主界面、背包、排行榜、聊天、活动页等大量 UI 面板。
  • 滚动列表元素多、打开卡顿、滑动掉帧或内存持续增长。
  • UI 制作依赖人工切图、拖组件、绑定脚本,效率低且容易出错。
  • TextMeshPro 图文混排、超链接、动态字体、图集管理问题频繁出现。

Unity-UI与优化

  • 本笔记是 Unity UI、渲染优化、框架入口和常用资料的综合索引,适合做“问题定位入口”,更细的 UI 工程实践可继续看 Unity-UGUI与UI工具笔记。
  • UI 与渲染优化要先建立观测链路,再决定改代码、改资源、改层级还是改工具流程。
  • DrawCall、Batch、Overdraw、GC、资源加载和脚本开销经常互相影响,不能只盯一个指标。
  • 框架资料、PureMVC、ET、DOTween、Asset Store 工具都应按项目实际使用价值筛选,避免资料堆积成新的链接池。
  • 需要快速查找 Unity 官方入口、社区入口、Asset Store、DOTween、PureMVC、ECS、UGUI 优化资料。
  • 项目出现 UI 打开慢、滑动掉帧、DrawCall 高、GC Alloc 高、渲染过度或脚本更新过重。
  • 需要对旧项目的 UI 和框架资料进行二次筛选,沉淀成可执行的优化规范。

Unity-内存与性能优化笔记

  • Unity 移动端内存主要分三块:资源内存、引擎模块内存、托管堆内存;优化时不要只盯 GC Alloc 或 Mono。
  • 大多数项目的内存压力来自资源,尤其是 Texture、Mesh、AnimationClip、AudioClip、Material、Shader、Font、Text Asset。
  • 判断内存泄漏不能只看“一次进出场景后没有完全回落”,需要做同场景多轮对比、跨场景资源对比和平台内存趋势验证。
  • AssetBundle 的问题通常不是“加载失败”,而是 WebStream / SerializedFile / Bundle 对象 / 已加载资源 / 实例化对象的生命周期没有拆清楚。
  • 性能优化要形成闭环:确定设备与路径、采集基线、定位类型、修改方案、复测数据、沉淀规则。
  • Android / iOS 包体或运行时内存过高。
  • 场景切换后内存没有下降,或者多次切换后持续增长。
  • 游戏长时间运行后出现卡顿、闪退、OOM 或系统杀进程。

Unity-框架与工具

  • Unity 框架选型不是“找一个大全框架”,而是围绕项目痛点拆分基础设施:资源、热更新、配置、异步、UI、网络、存档、编辑器工具和发布流水线。
  • 工具链价值来自可重复、可验证和可维护,优先沉淀项目真实使用过、能进入 CI、能降低人工错误的能力。
  • 官方资料和核心开源项目应作为长期入口,但正文必须记录自己的选型原则、接入边界和风险,而不是只保存链接。
  • 框架越重,越要关注团队理解成本、升级成本、调试成本、包体/内存成本和与 Unity 版本的耦合。
  • 新项目需要搭建客户端基础设施,确定资源、热更、配置、UI、异步和编辑器工具路线。
  • 老项目工具链分散,存在大量手工操作、重复脚本和不可复现构建。
  • 团队想引入 HybridCLR、YooAsset、Luban、ET、GameFramework、UniTask、MemoryPack 等工具,但需要评估边界。
  • 需要把补充仓库筛选成真正可落地的项目规范。

Unity-热更新与资源配置工程化笔记

  • Unity 热更新工程不要只看 HybridCLR,完整链路至少包含代码热更新、资源构建、资源分发、配置生成、版本管理和回滚策略。
  • HybridCLR 解决 C# 代码热更新和 AOT 补充元数据问题;YooAsset / xasset 更偏资源打包、分包、加密、下载和加载;Luban 负责把策划配置转成客户端和服务器可读的数据与代码。
  • 这几类工具应通过统一构建流水线串起来,而不是在 Unity Editor 里手工点按钮。
  • 正式项目需要把“生成代码/导表/构建资源/构建包体/上传 CDN/生成版本清单/灰度发布”拆成可重复执行的命令。
  • 项目需要在 IL2CPP 平台做代码热更新,同时要求配置和资源也可灰度发布。
  • 策划配置更新频繁,且客户端、服务器、工具链需要共享同一份 schema。
  • 包体要持续瘦身,需要首包/远端资源分离、增量更新和回滚能力。
  • 团队希望把“点按钮”的人工流程替换为 CI 可重复命令。

Unity-编辑器扩展与效率工具笔记

  • 编辑器扩展的价值在于把重复、易错、难检查的人工流程变成可复用工具。
  • Unity 编辑器工具主要分三类:Inspector/PropertyDrawer、EditorWindow/IMGUI、资源与编译流程工具。
  • Odin Inspector 适合快速提升 Inspector 表达力,IMGUI / UI Toolkit 更适合定制化窗口和复杂编辑器。
  • 工具链建设应关注迭代速度:编译耗时、Domain Reload、资源扫描、批量操作和错误可视化。
  • 配置、Prefab、ScriptableObject、技能、关卡、红点、UI 绑定等需要可视化编辑。
  • 项目中存在大量重复设置、手工拖引用、手工导出、手工检查。
  • 编译和 Domain Reload 时间过长,影响程序和策划迭代。
  • 需要做资源规范检查、依赖分析、内存/硬盘大小统计或批量修复。

博客园文章

参考链接

Unity 官方

GitHub 项目