问为什么使用"InvokeOnAppThread“？

EN

看起来，这是应该从断开的链接到达的页面。

从这一页：

现在，让我们仔细看看AppCallbacks类。创建它时，您指定您的游戏将在不同的线程上运行，出于向后兼容性的原因，您也可以指定您的应用程序可以在UI线程上运行，但这是不建议的，因为有一个来自Microsoft的限制--如果您的应用程序在5秒后无法响应，您将无法通过WACK ()，在这里阅读更多内容-- http://msdn.microsoft.com/en-us/library/windowsphone/develop/hh184840(v=vs.105).aspx，假设您的第一级很大，加载它可能需要大量时间，因为您的应用程序运行在UI线程上，UI将没有响应，直到您的级别完全加载。这就是为什么建议总是在不同的线程上运行您的游戏。

本质上，从WinRT/UWP运行时的角度来看，'UI线程‘是主线程。为了不阻塞该线程，所有特定于统一的代码-- MonoBehaviour脚本、协同器等--运行在一个单独的线程上，即“应用程序线程”，从团结引擎的角度来看，这个线程是主线程。

如果您是在联合的主线程上，并且想在Windows线程上做一些事情(例如，创建一个本机弹出)，您可以使用InvokeOnUIThread。如果您在UI线程上并希望封送回统一主线程(例如，启动一个协同线，实例化一个InvokeOnAppThread )，您可以调用GameObject。

我不太熟悉团结，但这是WinForms开发在您所使用的任何框架中的一个典型需求。

您可以在Control.InvokeRequired属性文档和此MSDN页面中找到有关此问题的详细描述。

解释说，控件的事件只应该由创建它们的线程来处理，否则它们就不是线程安全的。这与我在过去所理解的指导略有不同--您的主要UI线程只是侦听事件并将它们传递给ThreadPool进行处理，以便用户响应(即。(对鼠标/键盘事件的响应)永不停止，因为应用程序正在做一些事情。

Control.InvokeRequired检查应该告诉您是否在UI线程上，这样您就可以对另一个应该在不同线程上执行的事件排队，这样主UI处理线程就不会阻塞。不过，自从我上次处理这个问题以来，实现细节可能已经发生了一些变化。