对于 iOS 应用，UI 更新仅从主线程完成 - 不建议这样做，否则可能会导致意外行为。
在 watchOS 中，操作系统的结构包括 watch 扩展和应用程序 - 作为不同的“容器”。通常，从扩展中调用 UI 更新，这些更新会更新应用容器中的某些内容。
相同的主线程逻辑是否适用于从 watch 扩展更新 UI，或者可以从后台调用 UI 更新？
编辑 - 使之更加清晰。从应用程序的容器中，UI 更新可能应该发生在主线程上(就像在大多数系统/操作系统中发生的那样，如下所述)。真正的问题是 watchOS 是否会为我们处理这个问题，即在扩展的后台线程上调用 UI 更新是否会自动为我们发布到应用程序容器的主线程。
最佳答案
Apple 的 App Programming Guide for watchOS可能是权威指南，但我在那里找不到关于在主线程以外的线程上进行 UI 更新的引用资料。
有人会认为，如果从主线程调用 UI 更新很重要，那么它会在某处明确说明这一点(就像在 App Programming Guide for iOS 和 Threads and Concurrency section 中所做的那样):
Work involving views, Core Animation, and many other UIKit classes usually must occur on the app’s main thread. There are some exceptions to this rule—for example, image-based manipulations can often occur on background threads—but when in doubt, assume that work needs to happen on the main thread.
不过，上面的引述也可以解释为对 Watch 扩展的 UI 更新也是如此，因为它在 iOS 上运行。
综上所述，我认为没有任何 Apple 文档说明其中一种方式。
这里还有另一个数据点:Apple 的 Lister sample code现在包括一个 WatchKit 扩展，根据我对它的简要研究，它似乎正在将提取分派(dispatch)到后台队列(请参阅 ListInfo.swift:34)并通过分派(dispatch)回主队列来更新 UI(ListsInterfaceController.swift:98) .那里甚至有评论说它正在这样做:
The fetchInfoWithCompletionHandler(_:) method calls its completion handler on a background queue, dispatch back to the main queue to make UI updates.
我认为基于上述情况，我宁愿在主线程上进行更新，除非您确定这样做对性能或其他影响。
关于ios - watch 操作系统 : Should UI updates from the extension be called on the main thread?，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/35260461/