在WORD for Mac上使用更多context.sync()时更新内容控件的延迟

Question

我们更新任务窗格输入字段中键入的每个字符的内容控件。这样用户就可以看到word文档上的实时更新。

最近，我们增加了锁定内容控件的功能。这种情况发生在以下情况：

• 输入字段中的用户输入(键入字符)
• 我们搜索输入字段的内容控件(涉及context.sync)
• 解锁内容控件(涉及context.sync)
• 内容控制中的更新值(涉及context.sync)
• 锁定内容控件(涉及context.sync)

所有这些对windows来说都是很好的，没有问题。但苹果机器的Word (苹果机器)却非常(明显)慢。

我应该如何克服发生在Mac上的延迟？

Answer 1

正如胡安在评论中提到的，有一些重要的细节需要团队去调查。示例代码也会很好。

尽管如此，只要看一下您描述的内容，我认为您可以大大减少context.sync()语句的数量。在一个sync中应该可以解锁内容控件、更新其值和锁定它。

在我的书“sync-s”中，我有很多关于最小化使用Office.js构建Office外接程序的详细信息。引用其中的一节：

作为一个附加作者，您的工作是最小化context.sync()调用的数量.每次同步都是到主机应用程序的额外往返；当应用程序是Online时，每个往返的成本都会迅速增加。 如果您开始在原则上考虑到这一点来编写您的外接程序，您会发现您需要的sync调用数量惊人地少。事实上，在编写本章时，我发现我真的需要绞尽脑汁才能想出一个需要两个以上sync调用的场景。最小化同步调用的诀窍是，将应用程序逻辑安排成这样一种方式，即最初要为所需的任何信息抓取文档(并将所有这些信息排队等待加载)，然后进行一系列修改文档的操作(基于以前加载的数据)。您已经看到了这方面的几个例子:一个在介绍章节中，在描述为什么Office.js是异步的时候；最近在本章开头的“规范示例”部分。对于后者，请注意场景本身是相当复杂的:读取文档数据，处理它以确定哪个城市经历了最高的增长，然后创建一个格式化的表并从该数据中绘制图表。但是，鉴于代理对象的“时间移动”超能力，您仍然可以作为一组读取操作来完成此任务，然后是一组写入操作。 不过，在某些情况下，可能需要多个负载。事实上，在一些合理的情况下，即使进行额外的同步也是正确的--如果这样可以在加载一堆不需要的数据时进行保存。在本章后面，您将看到这方面的一个示例。