脚本 API
随着Sketch版本40的发布，我们正在逐步推出我们的 Javascript API，作为在插件中使用 Sketch 模型的更好方法。
作为此项工作的一部分，我们已更新此网站以包含 API参考部分。
API本身仍处于开发阶段，不应被视为完全固定或准备好黄金时段。
但它已经到了那里，如果你开始研究新的插件，你可能要考虑尝试一下。
在接下来的几个版本中，我们将进一步开发API，更新所有现有的 插件示例 以使用API，以及 添加一些新的例子。
NSAppTransportSecurity
使用 Sketch 的下一个版本，我们计划完全采用 Apple 之前称为 App Transport Security 的更改。 这与 HTTP 连接的安全性有关，并要求所有这些请求都使用 https： 而不仅仅是普通的 http：。
到目前为止，我们已禁用此功能，但很快我们就会启用它。
除非您的插件从网页请求内容，否则它不应受此更改的影响。
但是，如果您从网页中获取数据或资源，则需要在URL中使用 “https：” 切换。
我们还建议每个人都使用 https： 来更改插件清单文件中指定的任何URL。 Sketch的未来版本可能会使用这些URL。
在过去的几周里，我们一直在努力工作，对 Plugin 系统进行了一些更新。
其中一些将与即将发布的 3.8 版本 现在处于测试阶段 一起推出。 其他人将在稍后出现，但在这两种情况下，我们都希望给开发者社区中的每个人一些预警。
弃用的 API
正如你们许多人所知，我们经常需要在内部更改代码，这有时意味着我们已经公开的API已被弃用。 到目前为止，我们还倾向于将旧的API留在代码中，并让他们吐出一个控制台消息，说它们已被弃用。
向前迈进，我们打算开始实际删除这些API。 我们会给你一个或两个版本的通知（所以如果我们弃用 3.7 中的东西，我们不会删除它直到 3.9），但是你应该知道弃用将不再意味着 “你可以忽略它”，现在意味着 “你真的应该停止使用这个”。
传统插件
在类似的说明中，回到3.3版本，我们为插件引入了一种新的捆绑格式。 它有很多好处，但为了简化过渡，我们继续支持旧的单文件插件。
为了简化我们的代码并允许我们添加新的脚本功能，我们打算弃用然后删除对旧插件的支持。 从版本3.9开始，旧式插件提供的任何命令都将分组到菜单中的“Legacy”标题下。
接下来，更高版本的Sketch将不再加载旧插件。
我们建议您立即将插件移至新格式！ 这是一项非常简单的工作，它将为您提供面向未来的证明。
我们确信你现在已经完全卖掉了这个变化，但还有一点点推荐，以防万一：如果你想在我们的网站上推出你的插件，你需要将它们改成新的格式！
Action API
使用3.8，我们为插件引入了很多请求的能力，以便能够响应用户在Sketch中执行的操作。
We have posted some documentation and example Plugins for action support.
我们现在要清楚地表明这是行动支持的1.0版本，接下来会有更多内容。 我们意识到它现在的工作方式存在一些不一致之处，并不是用户可以做的所有事情都可以开始使用。 值得一提的是，出于性能原因，某些事情可能永远不可用作动作。
Even having said that though, this feature should greatly expand the range of things that Plugins can usefully do, and we look forward to seeing what you do with it. Please send us feedback on how it works for you, and what you’d like to see change.
Scripting API
正如你们中的一些人可能已经注意到的那样，我们在 3.7 中尝试添加一个只能使用 JavaScript 的 API，这是插件可以调用的。
这样做的目的是直接从 JavaScript 创建一个更小，更稳定的插件功能集。 每次我们发布 Sketch 的新版本时，我们都会尝试确保 API 继续有效。 这应该使用 API 来限制使用 API 的当前情况，他们被迫使用内部 Sketch 代码，然后在我们更改代码时破坏。
版本 3.8 确实包含稍微更新的版本，但我们认为它不适合黄金时段，并且没有正确记录。 API 的设计在这一点上也肯定不稳定，我们不建议使用它，因为类和方法的名称可能会改变。
考虑到这是一个早期的警告，它即将到来，请再次 发送反馈 了解您希望如何运作。
Sketch is a great tool for humans, but sometimes (especially in larger teams), we want to let the robots get in on the action too.
Making apps, websites, even icons is all about iteration: make it, try it, debug it, refine it, rinse and repeat.
Whilst we can’t automate the creative stuff, there are some steps in each of these iterations that are just drudge work. Exporting assets at a particular set of sizes and formats is an obvious example here, but maybe you are also supposed to extract certain measurements each time, or fire off certain exports in an email, or submit them to source control, or perform some other simple jobs.
We’ve done our best to make things like exporting a pain-free process from within Sketch itself, but even so, these jobs are often ripe for a more complete form of automation.
Wouldn’t it be nice if you could write scripts that are able to parse sketch files, extracting data and exporting images then doing things with the results?
Wouldn’t it be even nicer if these scripts could run unattended, maybe in response to your document changing, perhaps on a server where Sketch isn’t installed?
In some cases, there may be existing chains of tools and scripts in place as part of your (or your company’s) workflow. Wouldn’t it be nice if you could integrate Sketch with these?
This is why we made sketchtool.
它不是什么
First, it’s probably sensible to say what sketchtool doesn’t do.
For now, at least, sketchtool cannot create new Sketch documents, nor can it modify existing ones.
We may support a broader range of features at a later date, but for now, sketchtool is all about extracting things from existing documents.
这是什么
Essentially sketchtool lets you do three categories of thing:
- get a list of pages, artboards, slices
- export pages, artboards, slices or arbitrary layers
- get a full description of the entire document
清单
Given a sketch document called Test.sketch, you can list the pages in it like this:
sketchtool list pages Test.sketch
This will output a JSON record describing the name, id and bounds of each page.
Similarly
sketchtool list artboards Test.sketch
sketchtool list slices Test.sketch
does the same for the artboards and slices (and exported layers) in a document.
出口
Getting information from a document is all very well, but what you probably want is to export images.
To extract everything that has been marked for export in a document, you can do:
sketchtool export layers Test.sketch
Similarly:
sketchtool export pages Test.sketch
sketchtool export artboards Test.sketch
sketchtool export slices Test.sketch
You can also modify the output using various options.
The --output option lets you specify the output folder for the export.
The --formats option lets you specify a list of formats to use for the export (e.g. “svg,png”).
The --scales option lets you specify the scales to export at (x1, x2 etc).
The --items option lets you list just one or more items to export, by name or id.
Options such as --save-for-web, --overwriting, --compact, --trimmed, and --compression also let you tailor the output.
倾倒文件
目前使用 sketchtool 的最后一个选项是 dump命令：
sketchtool dump Test.sketch
这将输出文档的完整JSON描述。
该描述非常详细，因此输出变得很快，很快。 它还公开了很多关于底层模型的内部细节，因此它将来会发生变化，如果你在脚本中使用这个命令，你应该为它们可能会破坏一天做好准备。
在许多情况下，如果使用 list 命令无法获取您尝试提取的信息，那么您的下一个最佳选择可能是使用 SVG 导出，并解析它，因为它是一种稳定的格式。
如果这不起作用，您可以使用 dump 命令获取所需的信息。
未来
将来，我们可能会扩展 sketchtool 来做更多事情。
如果您有功能请求，错误报告或仅讲述您正在使用它做的很酷的事情，请与我们取得联系。
您可以下载最新版本的 sketchtool here。
(For comments, I’m @samdeane on Twitter)
我们已经 照顾 模型中KVO的开销，而 Undo 之类的东西现在已经硬编码并且 “快速”。 但是让我们来看看我们如何使用 undo，并在不需要它时绕过它。
目前在 Sketch 中，模型中的每个 setter 方法都会注册自己的反向撤消操作。这是一个易于理解的概念，适用于简单的对象图。
性能在 Sketch 中至关重要，一些用户可以轻松地在图形中创建具有 10K + 对象的巨大绘图。当图形变得那么大时，快速对树进行更大的修改变得非常重要。
一个例子是将复杂的 PDF 文档拖入 Sketch; 在解析它之后，我们可能已经创建了几千个新对象。在此过程中为所有调用者注册撤消操作是不必要的，也是一个很大的性能开销。
解决这个问题很容易; 我们只是将整个导入块包装在 disable-undo-registration 块中。但是我们仍然会调用所有这些方法，在撤消管理器决定将它们扔掉之前复制原始对象值。不好。
那么我们该如何解决这个问题？让我们沿着 ‘shouldRegisterUndo’ 的行为每个模型对象添加一个标志。但是现在我们在每个对象上都有一个额外的实例变量。这很浪费，容易出错; 我们必须以某种方式保持所有这些属性同步。
让我们再试一次。我们在根模型对象上创建一个静态 BOOL “shouldRegisterUndo”。现在我们遇到麻烦，如果我们想在后台线程上进行异步导入。所以我们使用 NSThread 的 threadDictionary 来保存这些值。呸。
不，让我们有一个 setX 和 setPrimitiveX。前者调用后者，但做了一些额外的事情，如撤销注册。导入和其他大型操作可以调用 setPrimitiveX，一切正常。除了setter可以做其他事情，如果那些进入 setX，我们必须记住每个模型对象上的每个属性是否有任何其他副作用。啊。
副作用这个词可能是关键所在。 我们应该尽可能地避免它们，并且让安装者只是设置者。 撤消是控制器的任务，在我们的 烤宽面条堆栈 中升级一层。 保持我们的水平彼此正确分离是很重要的，每个水平都有明确定义的角色。
我到底该怎么做才不知道，但至少它显然不属于这里。 未完待续…。
(For comments, I’m @pieteromvlee on Twitter)
Pieter 在上一篇文章中提到，最初我们使用 KVO 注册作为通用机制来支持我们模型中的撤销。
基本上，这里发生的是任何模型对象注册以观察自身，然后使用它收到的更改通知来记录撤消管理器的操作。
这个 KVO 系统的优点是它很好而且通用。它避免了我们不得不在每个模型类中编写重复代码来执行基本相同的操作。
缺点是同一枚硬币的另一面。通用是通用的，代码必须比自定义setter需要做更多的工作，特别是对于具有原始值的属性。我们来看一个像 cornerRadius 这样的简单 CGFloat 属性的例子。
自定义 setCornerRadius：setter 可以简单地向 Undo 管理器注册一个调用，调用自己将角半径设置回旧值 - 它可以在用新值删除它之前读取它。任务完成。
通过 KVO 的通用解决方案必须通过 observeValueForKeyPath:ofObject:change:context: 方法提供所有内容。旧的和/或新的值必须在字典中传递，对于像 CGFloat 这样的原始类型意味着它们也必须被装箱为 NSNumbers。此外，相同的方法充当每个属性的每个更改的入口点，因此属性名称必须作为字符串（键路径）传递。 KVO还可能调用各种其他相关方法，例如 willChange / didChange，再次增加开销。最后，实际的 KVO 注册必须在某个时刻完成，这显然会在幕后更多地摆弄 - 更多的开销。
现在所有这些在大多数情况下并不繁重，并且当按照预期的方式使用时，KVO 是一个很好的解决方案，适用于许多任务。
问题
以我们的方式使用它，我们遇到了一些问题。这些在我们的代码中至少部分是设计问题，但它们的作用是使 KVO 不是最有效的撤销方法。
最大的问题是，在我们的设计中，KVO 注册过早完成，主要是在我们创建对象时。这意味着创建一个新的对象集群以构成图形的一部分 - 例如从磁盘加载文件时 - 会产生所有这些撤销相关的开销，即使我们从未需要 “撤消” 加载。
同样，在导入 SVG 或 PDF 文件时，我发现我编写的用于创建图层并设置其属性的代码花费了大量时间来完成与 KVO / Undo 系统相关的不必要的工作。
此外，在Sketch的正常使用中有 次，其中一次对许多对象进行更改 - 例如，如果用户执行全选，然后拖动周围的东西。在这种情况下，有许多问题需要解决，但是对KVO失去额外的性能并没有那么有用……
最后，我实际上应该在这里提到KVO代码不仅仅是撤销注册，它还跟踪图中哪些对象已经改变 - 一旦它变得更复杂和异步，我们的渲染所需的信息（更多也许在后面的文章中。
由于各种原因，我们无法同时解决每个设计问题，但我们确实需要提高性能。
解决方案
所有这一切的结果是我们作为通用解决方案从KVO转移到了更多手工编码的东西。
然而，我们决定编写一个代码生成器来为我们完成工作 - 而不是像 Mogenerator 那样，但不依赖于 Core Data。
这里的基本思想是描述我们的模型类，然后让生成器为我们创建所有样板代码。这可以解决撤销注册问题，还可以解决编码，解码以及我们想要在一系列模型类中应用通用解决方案的任何其他问题。
这不仅为我们提供了更多的性能（或者在某些情况下更多），它为我们提供了一些面向未来的能力。
我们基本上为每个模型对象提供了大量的样板代码，但是当我们需要进行设计更改时，我们所要做的就是编辑代码模板并重新编译。
这使我们能够灵活地一次完成一些更基本的设计问题，安全地知道我们不会对每个问题进行可怕的手动更改。
这个代码生成工具顺便称为 Coma，它是开源的。现在它很没有文档，只有勇敢。我正在计划一个关于它的后续帖子……
还有一件事…
从概念或哲学的角度来看，我认为另一件事值得在这个主题上说。
代码随着时间的推移而增长和发展，特别是当你有一个发货产品时，有时你最终会在某个你不太想要的地方。
我完全不相信Undo注册和变更跟踪之类的东西应该以任何方式与模型纠缠在一起。很多时候我们可能想要操纵对象图，并且只有部分时间需要撤消注册。
这个东西对我来说就像控制器代码（在MVC意义上），我认为它应该存在于一个单独的层中。需要撤消注册的代码，或需要知道某些操作发生时已更改的内容的代码，应该要求此“模型操作”层执行模型更改，而不是直接执行。
可以通过多种方式实现：KVC，代表实际模型对象的代理对象，或其他一些自定义协议。实际的技术解决方案对我来说并不像概念分离那么重要。天真的KVO方法或模型类本身的自定义设置器的问题在于没有分离，并且您实际上必须以特殊方式编码以在不需要时关闭撤消注册（感觉像以错误的方式做事，并且往往涉及令人讨厌的全局或非线程安全的黑客攻击）。
正如我在上面暗示的那样，这些东西是我们仍在使用Sketch的东西。我们的代码按照当前的方式运行，因为当时很多逻辑决策都很有意义，但现在我们想稍微改变轨道。这种事情总是在任何重要的代码库中发生。我们没有奢侈的消失在一个黑暗的房间，并在一两年后出现完全重写，我们已经足够老了（并且希望足够明智）知道这通常会如何结束。
相反，我们正在做的是建立良好的单元测试套件，并慢慢削减设计，同时保持产品出货。
这种情况有时可能会让人感到痛苦，因为当诱惑只是潜入撕裂的时候。虽然这是正确的方法，但实际上可以非常令人满意地看到设计和代码慢慢转移，像油轮一样，进入新的标题……
(For comments, I’m @samdeane on Twitter)