NDMF项目中的PreviewSystem重复刷新问题分析与解决方案

NDMF项目中的PreviewSystem重复刷新问题分析与解决方案

ndmf 项目地址: https://gitcode.com/gh_mirrors/nd/ndmf

问题背景

在NDMF（nadena.dev.modular-avatar）项目的PreviewSystem中，存在一个关于场景加载时渲染过滤器(RenderFilter)重复实例化的问题。该问题表现为在场景启动或PlayMode结束时，所有过滤器的实例化(instantiate)过程会被触发两次，导致性能浪费和潜在的错误。

问题现象

开发者在使用TTT AtlasTexture和SceneMeshUtils等插件时观察到以下现象：

1. 场景加载时，所有过滤器的instantiate过程会完整执行一次
2. 随后系统抛出UnityException异常，提示"get_gameObject can only be called from the main thread"
3. 异常处理后，相同的过滤器instantiate过程会再次执行
4. 当用户从场景中选择对象时，由于另一个已知问题(#376)，instantiate会第三次触发

这种重复实例化不仅影响性能，还可能导致渲染状态不一致等问题。

技术分析

从错误堆栈可以分析出问题的根源：

1. 线程安全问题：错误明确提示"get_gameObject can only be called from the main thread"，表明在场景加载线程中尝试访问只能在主线程中操作的GameObject属性。

2. 初始化时机不当：错误信息建议"Don't use this function in the constructor or field initializers"，说明有代码在构造函数或字段初始化器中执行了不合适的操作。

3. 异常处理后的重试机制：系统在捕获异常后似乎有自动重试机制，导致相同操作被重复执行。

4. ProxyPipeline构建问题：错误发生在NodeController.Create方法和ProxyPipeline.Build方法中，表明预览系统的代理管道构建过程存在缺陷。

解决方案

针对这一问题，NDMF项目团队通过以下方式进行了修复：

1. 线程安全改进：确保所有GameObject操作都在主线程中执行，特别是在场景加载期间。

2. 初始化时机调整：将敏感操作从构造函数和字段初始化器移动到Awake或Start等合适的Unity生命周期方法中。

3. 错误处理优化：改进异常处理逻辑，避免因错误导致不必要的重试操作。

4. 代理管道构建流程重构：优化ProxyPipeline的构建过程，确保在错误情况下能够正确恢复而不会重复执行相同操作。

技术启示

这个问题给Unity开发者提供了几个重要的技术启示：

1. 线程安全意识：在Unity开发中必须时刻注意线程安全问题，特别是涉及GameObject和组件操作时。

2. 初始化时机选择：构造函数和字段初始化器中的操作限制较多，复杂初始化应放在Unity的生命周期方法中。

3. 错误处理设计：良好的错误处理应该既能捕获问题，又能避免引发连锁反应。

4. 预览系统设计：对于编辑器预览这类复杂系统，需要特别考虑各种边界条件和异常情况。

总结

NDMF项目中PreviewSystem的重复刷新问题是一个典型的多线程和初始化时机问题，通过分析错误堆栈和系统行为，开发团队能够准确定位问题并实施有效修复。这类问题的解决不仅提升了系统稳定性，也为类似系统的设计提供了宝贵经验。对于使用NDMF框架的开发者来说，理解这些底层机制有助于更好地使用和扩展该框架的功能。

ndmf 项目地址: https://gitcode.com/gh_mirrors/nd/ndmf