OSX下自定义协议启动的Java AWT应用无法释放焦点问题排查

这个问题我之前在排查OSX Java应用的窗口问题时碰到过类似情况，结合系统底层逻辑和Java AWT的特性，给你理清楚来龙去脉：

1. OSX中控制焦点的核心组件 #

• 全局窗口焦点的最终掌控者是WindowServer（属于CoreGraphics框架），它负责所有窗口的激活状态管理、焦点切换、用户输入事件的分发。
• LaunchServices的角色是处理应用关联、协议解析和启动流程（比如识别foobar:协议对应的应用并启动它），但它不直接干预焦点控制，只是启动过程会影响应用的初始化上下文。
• Java AWT本身是通过JVM调用OSX的Cocoa原生窗口API来创建窗口，AWT的焦点逻辑依赖于WindowServer，但JVM在不同启动场景下的初始化参数、窗口属性设置会有差异，这才是问题的关键。

2. 自定义协议启动 vs 常规启动的关键差异 #

当你通过open foobar:或浏览器点击协议链接启动应用时，LaunchServices会以后台启动上下文初始化应用，这带来了两个核心差异：

• 应用激活状态：常规启动（双击.app、open /Applications/My.app、java -jar）会让应用直接进入前台激活状态，窗口自动获得焦点；但自定义协议启动时，LaunchServices默认不会主动激活应用（因为协议处理通常被设计为后台响应操作）。这时候AWT窗口可能出现“抢住焦点却不释放”的异常——JVM在非激活启动的上下文里，错误地将窗口标记为“需要持续占据焦点”，导致WindowServer无法正常把焦点分发到其他应用。
• 配置加载差异：通过.app包或java -jar启动时，JVM会读取.app内Info.plist的配置（比如NSApplicationActivationPolicy这类窗口策略参数）；而自定义协议启动时，LaunchServices可能跳过部分.app配置的加载，或者传递不同的启动参数给JVM，导致AWT的窗口初始化逻辑出现偏差。
• 事件循环优先级：自定义协议启动的应用，事件循环可能被标记为后台优先级，但AWT却强行创建了前台窗口，这种矛盾会让WindowServer的焦点管理逻辑混乱，最终出现焦点锁死的情况。

3. 问题根源：Java AWT对非激活启动场景的适配缺陷 #

本质上是Java的AWT在OSX平台上，对LaunchServices触发的“非激活启动”场景处理不完善：

• 当应用以非激活状态启动却创建了AWT窗口时，JVM没有正确向WindowServer发送窗口激活的请求，也没有处理好焦点释放的逻辑，导致窗口一直霸占焦点，其他应用无法获取。
• 而常规启动时，应用是主动激活的，JVM的AWT初始化流程和WindowServer的逻辑完全匹配，所以不会出现问题。

临时解决思路（供参考） #

• 在AWT应用启动后，主动调用OSX原生API调整应用激活状态，比如通过JNA调用NSApplication的activateIgnoringOtherApps:方法并设置为NO，强制允许其他应用获取焦点。
• 修改.app的Info.plist文件，添加LSUIElement字段并设置为NO，强制应用无论以何种方式启动都以前台模式运行。

内容的提问来源于stack exchange，提问作者user1009908