SketchyBar中space_windows_change事件的JSON键重复问题解析

问题背景

在macOS窗口管理工具SketchyBar中，space_windows_change事件用于通知用户当前空间窗口变化情况。该事件会返回一个JSON格式的数据，包含空间编号和应用程序信息。然而，用户在使用过程中发现，当同一应用程序的多个窗口存在时，JSON数据中会出现重复键的问题。

问题现象

当用户使用Alacritty终端模拟器打开多个窗口时，space_windows_change事件返回的JSON数据如下：

{
  "space": 1,
  "apps": {
    "Brave Browser": 1,
    "Alacritty": 1,
    "Alacritty": 1,
    "Alacritty": 1
  }
}

这种数据结构存在两个技术问题：

1. JSON规范中键名应该是唯一的，重复键会导致解析问题
2. 使用jq等工具处理时，重复键会被自动去重，导致窗口计数不准确

技术分析

通过查看SketchyBar源码，发现问题源于app_windows.c文件中的实现逻辑。该模块在统计窗口应用时，以应用名称为键，但未考虑同一应用多个实例的情况。

在macOS系统中，应用程序可以有两种运行方式：

1. 单进程模式：所有窗口共享同一进程
2. 多进程模式：每个窗口使用独立进程

Alacritty默认采用多进程模式，因此系统会为每个窗口创建独立进程，导致SketchyBar将它们识别为不同应用实例。

解决方案

SketchyBar开发者确认这是一个实现上的疏忽，并提供了两种解决思路：

1. 修复计数检测（推荐方案）

   • 对同名应用进行计数累加
   • 保持API向后兼容
   • 修改后数据结构示例：

     {
       "space": 1,
       "apps": {
         "Brave Browser": 1,
         "Alacritty": 3
       }
     }
     

2. 改变数据结构格式

   • 使用窗口ID作为键
   • 或改用对象数组存储窗口信息
   • 这种方案会破坏现有API兼容性

额外建议

对于Alacritty用户，开发者建议可以配置为单进程模式：

• 减少进程创建开销
• 提升性能表现
• 避免窗口管理工具中的识别问题

技术思考

在处理JSON数据时，开发者应当注意：

1. 严格遵循JSON规范，确保键名唯一性
2. 考虑数据结构的前后兼容性
3. 对于可能产生重复的场景，预先做好聚合处理

对于bash脚本处理JSON数据，虽然可以使用jq工具，但在性能要求高的场景下，可以考虑使用更直接的进程通信方式，如SketchyBar提供的mach port接口。

这个问题也提醒我们，在设计事件通知系统时，应该充分考虑各种边界情况，确保数据结构的健壮性和可靠性。