3

我最近编写了一个名为WindowTiler的实用程序，它使用全局快捷方式在当前聚焦的窗口中移动。我通过 AppleScript 在窗口中移动并使用以下脚本来获取焦点窗口的边界：

tell application "System Events"
  set appName to the first process whose frontmost is true
  set appWindow to the value of attribute "AXFocusedWindow" of appName
  set {w, h} to the size of appWindow
  set {x, y} to the position of appWindow
  set appBounds to {x, y, x + w, y + h}
end tell
{bounds:appBounds}

随着时间的推移，我意识到如果一段时间不使用我的应用程序反应很慢。在深入测量时间性能后，我发现显示的 AppleScript 的第二行是响应缓慢的原因。有时脚本需要一整秒才能执行（在 SSD 上，据我所知在 HDD 上更糟）。

我不知道为什么 AppleScript 需要这么长时间才能简单地查找最前面的进程——应该是对进程管理器的唯一请求。也许您知道它为什么这么慢和/或可以告诉我一种使脚本更快的方法。

PS：当我创建我的应用程序（“存档”）时，我将 Xcode 配置为预编译我的 AppleScripts。编译的脚本是只读的。

4

2 回答 2

0

在接收基于 Carbon 的事件热键时，我还没有看到这种滞后。您是否在代码中添加了日志记录以查看何时调用热键回调？这实际上需要几秒钟，还是您可能需要几秒钟来处理它？

查看DDHotKey以了解如何做好此操作（或者您可能只想使用Dave 的代码来替换您的代码）。

编辑

如果您在程序运行一段时间后遇到问题，您可能还想通过 Instruments 运行它。确保您没有泄漏大量内存或线程。这可能会给出您所描述的症状。

编辑2

为什么不加载脚本并将其保存在 ivar 或静态中，而不是按需加载呢？即使已编译，您仍然必须从磁盘读取它，解析它并构建数据结构。（此外，这个问题已经偏离了它的主题。你应该关闭它并开始一个关于 Applescript 性能的新问题。否则它会搞砸稍后寻找答案的人。）

于 2011-07-31T08:33:18.577 回答
0

如果您强制脚本接收进程（及其所有属性），那么它当然有时会很慢。尤其是调试的时候。更好更快的是只获得进程的名称。一个进程拥有的属性越多，通过只获取名称获得的收益就越大。此外，最前面进程的焦点窗口始终是窗口 1。

tell application "System Events"
    set appName to name of first process whose frontmost is true
    tell process appName to tell window 1 to set {{w, h}, {x, y}} to {size, position}
end tell
{bounds:{x, y, x + w, y + h}}
于 2021-09-27T17:51:08.987 回答