对于iOS应用程序，UI更新仅会在主线程中完成 - 不这样做不被建议且可能导致意外行为。
在watchOS中，操作系统以手表扩展和应用程序作为不同的“容器”进行结构化。通常，UI更新是从扩展中调用的，并且这些更新会更新应用程序容器中的某些内容。
是否适用相同的主线程逻辑来自手表扩展更新UI，或者可以从后台调用UI更新？
编辑 - 为了带来一些清晰度。从应用程序容器中，UI更新应该在主线程上发生（如大多数系统/操作系统中所发生的那样，如下所示）。问题实际上是watchOS是否为我们处理了这个问题，即在扩展的后台线程上调用UI更新是否会自动发布到应用程序容器的主线程上。
苹果公司的watchOS应用程序编程指南可能是权威指南，但我在其中找不到关于在主线程以外的线程上执行UI更新的参考。
如果从主线程调用UI更新很重要，那么人们会认为它会在某个地方明确说明（就像在iOS应用程序编程指南中，在线程和并发部分中所做的那样）：
涉及视图、核心动画和许多其他UIKit类的工作通常必须在应用程序的主线程上执行。当然，也有一些例外情况，例如基于图像的操作通常可以在后台线程上执行，但是如果有疑问，请假设工作需要在主线程上进行。fetchInfoWithCompletionHandler(_:) 方法在后台队列上调用其完成处理程序，然后返回到主队列以进行 UI 更新。
根据上述内容，我认为最好在主线程上进行更新，除非您确定这样做会对性能或其他方面产生影响。
在通过技术支持事件联系苹果后，收到了以下答复和解释。
简而言之：使用主线程。
All updates should be done from the main thread. This has always been the general recommendation for UIKit and that recommendation extends to watchOS.
It might be helpful to understand the underlying reason for this requirement. Keep in mind that, even with a centralized communication channel to serialize changes, many problems arise when you attempt to manipulate UI state from background threads. For example, while the serialization channel can prevent multiple UI commands from attempting to simultaneously execute, it can’t control the order in which unrelated commands will execute. Consider the following 2 blocks:
block 1 { DoUIChange1 DoUIChange2 } block 2 { DoUIChange3 DoUIChange4 }If both blocks are executed on the main thread, then the actual command stream is either:
DoUIChange1 DoUIChange2 DoUIChange3 DoUIChange4or…
DoUIChange3 DoUIChange4 DoUIChange1 DoUIChange2However, if both blocks are executed on their own threads, even more possibilities open up:
DoUIChange3 DoUIChange1 DoUIChange2 DoUIChange4or..
DoUIChange1 DoUIChange3 DoUIChange2 DoUIChange4or..
DoUIChange1 DoUIChange3 DoUIChange4 DoUIChange2etc…
Needless to say, if the UI code is at all complex the number of combinations quickly becomes enormous, making unexpected UI bugs basically unavoidable.
你应该始终在主线程上进行UI更新。否则，将导致UI渲染变慢或潜在的应用程序崩溃。这不仅适用于iOS或watchOS，几乎每种编程语言（C＃，Java，C ++等）都要求您在主线程上进行UI更新。
在watchOS 1中，您所建议的可能是有道理的，因为扩展位于iPhone上，而UI位于手表上。在这种情况下，应用程序确实作为两个单独的进程运行，并且您“可能”不需要调度到主线程以进行UI更新。但在watchOS 2中，情况就不同了。尽管watchOS扩展和UI具有不同的目标，但在watchOS 2中，它们不会在手表上作为单独的进程运行（您可以通过在Xcode中查看Apple Watch上运行的进程来验证这一点，并查看每个应用程序只有一个进程）。仅仅因为它被打包为两个单独的容器（甚至签名不同）并不意味着它们在手表上作为两个单独的进程运行。
