SketchyBar 多空间管理中的事件竞争问题解析

问题现象

在使用SketchyBar进行macOS多空间管理时，用户发现当通过Homebrew服务启动时会出现以下异常现象：

1. 多个空间同时显示为"活动"状态
2. 空间高亮显示错误（例如浏览器空间高亮而实际打开的是编辑器空间）
3. 颜色显示异常
4. 插件输出结果不符合预期

有趣的是，这些异常仅在使用Homebrew服务启动时出现，直接命令行运行则表现正常。

问题根源分析

经过深入分析，发现这是典型的事件竞争条件问题，具体发生在以下两个事件的交互中：

1. space_windows_change事件 - 当空间窗口发生变化时触发
2. space_change事件 - 当切换空间时触发

在macOS 13+系统中，当创建/销毁空间时，这两个事件会被自动触发。问题的核心在于：

• 这两个事件是异步执行的
• 它们共享相同的状态变量（如SELECTED）
• 执行顺序无法保证

竞争条件详解

当用户请求空间切换时，会经历以下时序：

1. 触发空间切换请求
2. 系统发出space_windows_change事件，此时SELECTED变量仍保持旧状态
3. 系统发出space_change事件，更新SELECTED变量为新状态
4. 两个事件的处理脚本异步执行
5. 由于执行顺序不确定，最后处理的事件会覆盖颜色设置

如果space_change先处理而space_windows_change后处理，就会导致错误的高亮显示。

解决方案

最佳实践是将空间高亮逻辑与空间窗口逻辑分离：

1. 创建独立组件：专门处理空间相关事件

   • space_windows_change
   • space_created
   • space_destroyed

2. 避免状态共享：减少全局变量的使用，特别是那些会被多个事件处理器修改的变量

3. 逻辑解耦：将空间标签管理和空间选择逻辑分离到不同的处理函数中

实施效果

通过重构代码，将相关逻辑分离到独立函数后：

• 解决了颜色异常问题
• 消除了多空间同时高亮的现象
• 确保了正确的空间高亮显示
• 提高了整体性能（减少了不必要的计算）

经验总结

在开发SketchyBar插件时，特别是处理系统事件时，需要注意：

1. 理解事件的触发机制和时序关系
2. 避免在多个事件处理器中修改共享状态
3. 保持处理逻辑的单一职责原则
4. 对可能产生竞争条件的操作进行适当隔离

这种架构设计不仅解决了当前问题，也使插件更易于维护和扩展。