Guangfox的博客

目标：理解 Unity 的更新流程要求使用文章中的打印完整的 PlayerLoop 结构Awake在哪个阶段？Update在哪个阶段？在哪个阶段？LateUpdate在哪个阶段？Frame N:ms] Update目标：掌握 PlayerLoop 注入的基本方法要求在UpdateTimeframeCount创建一个 MonoBehaviour，在 Update 中打印日志观察自定义系统是否在 Update 之后执行预期输出。

Unity脚本执行顺序解析 核心问题 脚本初始化顺序不确定导致依赖问题 常见陷阱：Awake中访问未初始化组件、OnEnable多次触发、场景加载顺序不一致 关键解决方案 使用Start替代Awake：确保所有Awake已完成 设置Script Execution Order：明确指定关键脚本的执行优先级 延迟初始化：通过协程等待一帧完成初始化 避免OnEnable中的重复注册：使用标志位防止多次订阅事件 最佳实践 关键系统(如GameManager)设置为负值优先执行 复杂初始化逻辑放在Start中 对于

Unity PlayerLoop 系统深度解析 本文深入探讨了 Unity 的 PlayerLoop 更新机制，对比了传统 MonoBehaviour.Update 与自定义 PlayerLoop 系统的优劣。主要内容包括： 通过工厂流水线类比，解释 PlayerLoop 的分阶段执行原理 详细拆解 Unity 帧循环的完整架构，展示 Initialization、EarlyUpdate、FixedUpdate 等核心阶段 揭示 MonoBehaviour.Update 的底层实现原理及其性能瓶颈 提出自定

Unity 内存管理：GC卡顿与优化策略 核心问题 Unity采用双层内存架构，托管内存（C#堆）由GC自动管理，原生内存（引擎资源）需手动释放。GC卡顿主要由于Boehm GC的Stop-The-World机制，尤其在关键帧触发时影响更大。 关键发现 内存架构：C#对象与引擎资源分属不同内存空间，存在跨层引用关系 GC机制：传统GC导致卡顿，增量GC可分散回收压力 优化方向：减少托管堆分配、控制GC触发时机、正确处理跨层引用 实用建议 使用对象池减少分配 配置增量GC时间片 避免在Update中频繁分配内

Unity序列化机制解析：常见字段丢失问题与解决方案 摘要 Unity序列化机制特殊且复杂，开发者常遇到字段丢失问题。本文揭示其核心规则：1)支持基本类型、UnityObject引用、标记为Serializable的自定义类、数组和List；2)不支持Dictionary、多维数组、复杂泛型等；3)public字段自动序列化，private字段需[SerializeField]标记；4)存在7-10层的嵌套深度限制。通过理解Unity的三层序列化架构和底层C++扫描逻辑，开发者可避免常见陷阱，如静态字段、常

Unity资源依赖与打包优化指南 核心问题：Unity包体无故增大常由资源依赖关系管理不当导致，表现为重复打包、冗余依赖和隐式引用问题。 关键发现： Unity资源引用分三层：文件GUID→对象FileID→隐式依赖 打包时递归收集所有依赖，未显式管理的共享资源(如Shader/图集)会被重复打包 常见陷阱包括：Shader冗余、图集复制、长依赖链导致资源雪崩 解决方案： 使用Unity内置工具或AssetBundle Analyzer分析依赖树 显式分配共享资源到独立Bundle 通过依赖分析脚本定位问题

Unity 的 Addressables 和 AssetBundle 是两套资源加载系统，设计哲学迥异。AssetBundle 提供底层 API，需要开发者手动管理依赖、引用计数和卸载逻辑，灵活但繁琐；而 Addressables 在其基础上构建了高级框架，自动处理依赖关系、实现引用计数和智能卸载，简化开发但增加系统开销。核心区别在于：AssetBundle 强调控制力，Addressables 侧重易用性。Addressables 并非替代 AssetBundle，而是通过中间层封装复杂逻辑，为开发者提供

ScriptableObject 是 Unity 中能持久化数据的特殊对象，其本质是继承自 UnityEngine.Object 的资源型对象。与 MonoBehaviour 不同，SO 独立于 GameObject 存在，以.asset 文件形式存储，通过 Unity 序列化系统转换为 YAML 格式保存。SO 适合用于配置数据、全局事件系统和运行时共享数据，其特性包括：字段标记序列化、独立生命周期、跨场景引用和内存共享。关键区别在于 Mo