Puerts项目中JsEnv与GenericDelegate的析构顺序问题分析

背景介绍

在Unity项目中使用Puerts进行JavaScript与C#交互时，开发者可能会遇到JsEnv与GenericDelegate析构顺序导致的异常问题。这个问题在新版NUnit测试框架下尤为明显，因为NUnit要求必须在OneTimeTearDown方法中显式Dispose JsEnv变量。

问题现象

当测试用例执行完毕后，如果按照NUnit的要求在OneTimeTearDown中Dispose JsEnv，可能会遇到"JsEnv has been disposed"的异常。这是因为GenericDelegate的析构函数会在JsEnv被Dispose之后才被调用，导致检查失败抛出异常。

技术原理

Puerts中的GenericDelegate是用于桥接JavaScript函数与C#委托的重要组件。它的生命周期管理依赖于JsEnv实例。当GenericDelegate被垃圾回收时，其析构函数会检查关联的JsEnv是否仍然存活。

在测试场景中，常见的执行顺序是：

1. 测试执行完毕
2. OneTimeTearDown调用JsEnv.Dispose()
3. 垃圾回收器运行，触发GenericDelegate的析构函数
4. GenericDelegate析构函数检查发现JsEnv已被Dispose，抛出异常

解决方案

目前有两种可行的解决方案：

1. 强制GC方案： 在Dispose JsEnv之前显式调用GC.Collect()和GC.WaitForPendingFinalizers()，确保所有GenericDelegate实例先被回收。这种方法简单直接，但可能影响性能。

public void Cleanup()
{
    GC.Collect();
    GC.WaitForPendingFinalizers();
    DefaultDontBindingEnv.Dispose();
}

2. 修改GenericDelegate检查逻辑： 更优雅的解决方案是修改GenericDelegate的析构函数逻辑，当发现JsEnv已被Dispose时，不抛出异常而是静默处理。因为这种情况下JsEnv的Dispose是开发者显式调用的，属于正常流程。

最佳实践建议

对于Puerts项目的开发者，建议：

1. 在单元测试中，按照NUnit规范在OneTimeTearDown中Dispose JsEnv
2. 如果遇到析构顺序问题，可以采用强制GC方案作为临时解决方案
3. 长期来看，应该考虑修改GenericDelegate的析构检查逻辑，使其更健壮
4. 在生产环境中，注意管理JsEnv和GenericDelegate的生命周期，避免内存泄漏

总结

Puerts作为连接JavaScript和C#的桥梁，其内部组件的生命周期管理需要特别注意。JsEnv与GenericDelegate之间的依赖关系可能导致析构顺序问题，开发者应当理解其内部机制，选择合适的解决方案。对于测试场景中的这类问题，最根本的解决方法是增强GenericDelegate的健壮性，使其能够正确处理JsEnv被提前Dispose的情况。