WatchOS:是否应在主线程上调用扩展的UI更新？

Question

对于iOS应用程序,UI更新是专门从主线程完成的 - 不会这样做从不推荐,并且可能导致意外行为.

在watchOS中,操作系统的结构是手表扩展和应用程序 - 作为不同的"容器".通常,从扩展程序调用UI更新,这些更新在应用程序的容器中更新.

相同的主线程逻辑是否适用于从watch扩展更新UI,还是可以从后台调用UI更新？

---

编辑 - 带来一些清晰度.从应用程序的容器中,UI更新可能应该发生在主线程上(如大多数系统/操作系统中所发生的那样,如下所述).问题是watchOS是否为我们处理,即是否在扩展的后台线程上调用UI更新将自动发布到应用程序容器的主线程中.

Answer 1

通过技术支持事件联系Apple后，收到的答复和解释如下。

\n\n

TLDR：使用主线程。

\n\n

\n

所有更新都应该从主线程完成。这一直是 UIKit 的一般建议，并且该建议也延伸到了 watchOS。

\n\n

了解此要求的根本原因可能会有所帮助。请记住，即使使用集中式通信通道来序列化更改，当您尝试从后台线程操作 UI 状态时，也会出现许多问题。例如，虽然序列化通道可以防止多个 UI 命令尝试同时执行，但它可以控制不相关命令的执行顺序。考虑以下 2 个块：

\n\n

block 1 {     \n  DoUIChange1     \n  DoUIChange2     \n}\n\nblock 2 {     \n  DoUIChange3     \n  DoUIChange4     \n}\n

\n\n

如果两个块都在主线程上执行，则实际的命令流是：

\n\n

DoUIChange1   \nDoUIChange2   \nDoUIChange3   \nDoUIChange4\n

\n\n

或\xe2\x80\xa6

\n\n

DoUIChange3   \nDoUIChange4   \nDoUIChange1   \nDoUIChange2\n

\n\n

但是，如果两个块都在各自的线程上执行，则可能会出现更多\n可能性：

\n\n

DoUIChange3   \nDoUIChange1   \nDoUIChange2   \nDoUIChange4\n

\n\n

或者..

\n\n

DoUIChange1   \nDoUIChange3   \nDoUIChange2   \nDoUIChange4\n

\n\n

或者..

\n\n

DoUIChange1   \nDoUIChange3   \nDoUIChange4   \nDoUIChange2\n

\n\n

等\xe2\x80\xa6

\n\n

不用说，如果 UI 代码非常复杂，\n 组合的数量很快就会变得巨大，从而导致意外的 UI bug\n 基本上不可避免。

\n

\n