Hammerspoon中GUI应用执行导致卡死的解决方案

问题现象分析

在使用Hammerspoon自动化工具时，开发者可能会遇到脚本随机卡死或无响应的情况。从日志分析可以看到频繁的热键启用/禁用记录，但缺乏明显的错误信息。这种情况通常发生在执行特定热键操作后，特别是涉及GUI应用程序启动时。

根本原因

经过深入排查，发现问题源于对hs.execute函数的错误使用方式。在示例代码中，开发者尝试通过异步方式(false参数)启动GUI应用程序：

hs.hotkey.bind({ "cmd", "ctrl" }, "b", function()
    hs.execute('/path/to/application', false)
end)

这里存在两个关键问题：

1. 异步执行误解：虽然设置了false参数表示异步执行，但GUI应用程序的特殊性会导致Hammerspoon等待进程结束
2. 资源管理不当：未正确处理应用程序生命周期，导致事件循环阻塞

解决方案

方案一：使用专用API启动GUI应用

Hammerspoon提供了更合适的API来启动GUI应用程序：

hs.hotkey.bind({ "cmd", "ctrl" }, "b", function()
    hs.application.launchOrFocus("/Applications/YourApp.app")
end)

这种方法专为GUI应用设计，不会阻塞事件循环。

方案二：正确使用hs.execute

如果确实需要使用hs.execute，应该采用以下模式：

hs.hotkey.bind({ "cmd", "ctrl" }, "b", function()
    hs.task.new("/usr/bin/open", nil, { "-a", "YourApp" }):start()
end)

方案三：完善垃圾回收机制

为防止内存泄漏导致的问题，应该：

1. 确保所有watcher和hotkey对象被全局变量引用
2. 在脚本重新加载时正确清理旧对象

-- 全局存储
local obj = {}

obj.appWatcher = hs.application.watcher.new(function(appName, eventType)
    -- 处理逻辑
end)
obj.appWatcher:start()

return obj

最佳实践建议

1. 避免长时间阻塞操作：任何可能长时间运行的操作都应使用异步方式
2. 优先使用专用API：Hammerspoon为常见操作提供了专用接口，比通用执行更可靠
3. 完善错误处理：为关键操作添加错误处理逻辑
4. 日志记录：在复杂操作前后添加日志输出，便于问题追踪

总结

Hammerspoon作为强大的自动化工具，在使用时需要特别注意执行模式和资源管理。针对GUI应用程序的操作，应当选择专门的API而非通用执行命令。通过遵循这些最佳实践，可以显著提高脚本的稳定性和可靠性，避免卡死和无响应的问题发生。