JetBrains Marketplace 向插件作者开放 UI 冻结报告

用户报告 IDE 停止响应，而你的插件是头号嫌疑对象。你按同样的步骤操作，一切却正常。如果没有更多细节，比如在卡死期间捕获的线程转储，就很难知道从何入手。

JetBrains Marketplace 现在让插件作者可以查看归因于其插件的 UI 冻结报告。要查看这些报告，打开你的插件管理页面，选择 Freezes 标签页。

有一个前提：你需要先在插件中启用 Marketplace 报告功能。希望这个标签页始终保持安静，但在你需要它之前把它配置好是值得的。

冻结报告里有什么？

Marketplace 按错误类型对冻结报告进行分组，并将相似的报告归入同一堆。每一堆显示一份代表性报告，这样你无需打开每一条记录就能发现反复出现的模式。

自动生成的线程转储摘录为你提供了一个起点，展示了被识别为与冻结相关的线程。它也是给编码 agent 的一个很好的初始输入：简短的摘录有助于它快速了解情况，同时比完整转储消耗更少的 token。如需更深入的调查，使用 analyze-freeze 技能，然后添加完整转储，让 agent 能够追踪线程或协程之间的关联。

dump-N.txt 文件包含在冻结期间每五秒捕获一次的完整线程转储。根据 IDE 能够捕获到的内容，报告还可能包括：

• snapshot.jfr，CPU 快照。
• report.txt，对捕获的线程栈的分析。
• open-telemetry-metrics.csv，涵盖 VFS 活动和 UI 响应性等方面的性能指标。

从一份报告开始

打开一份报告，在其摘录中找到事件调度线程（EDT）。它通常命名为 AWT-EventQueue-0 或包含 EDT。首先，检查 EDT 是正在忙于执行耗时操作，还是在等待其他事情完成。

要进一步调查，下载完整转储，并使用 IDE 中的 Search Everywhere 打开 Analyze Stack Trace or Thread Dump。粘贴转储文本并检查结果。在追踪是什么阻止 EDT 继续推进时，随时回看原始线程数据。如果有多个转储可用，比较它们，看看同一操作是否在多个采样中持续出现在栈上。

在下面的示例中，分析器识别出 EDT 上 org.xml.sax.helpers.XMLFilterImpl.parse 中的文件 I/O。

原因也可能出在后台线程上。一个长时间、不可取消的读操作可能持有写操作所需的锁，导致 UI 等待，即便耗时的工作实际上在别处运行。⁠UI Freezes and the Dangers of Non-Cancellable Read Actions in Background Threads 详细介绍了这种模式以及如何应对。

试试冻结分析技能

我们的同事 Patrick Scheibe 创建了 ⁠analyze-freeze 技能，帮助 AI 编码 agent 调查 IntelliJ Platform 线程转储。它包含了关于协程行为、Dispatchers.Default 饥饿以及其他常见冻结模式的指导，并附有修复建议。

试用方法：

• 将 gist 中的 SKILL.md 保存到你的调查文件夹中。
• 添加下载的完整线程转储，以及 report.txt 和协程转储文本（如果有的话）。
• 让你的 agent 阅读该技能并用以下提示分析这些文件：

阅读 SKILL.md 并将其 analyze-freeze 指令应用于所附的 IntelliJ Platform 线程转储。 从 EDT 开始，然后追踪是什么阻止它继续推进。 识别相关代码帧、参与的线程或协程、涉及的任何服务，以及可能的插件。 为每个结论引用转储证据。区分观察到的事实和假设。 如果摘录或转储不够充分，说明缺少哪些证据。 建议一个最小修复方案以及如何验证它。 暂时不要编辑代码。

在将转储分享给 AI 服务之前，请遵循你项目处理诊断数据的流程。使用 agent 的解释来指导你的调查，并在做出更改之前，对照完整转储和你的代码检查所引用的帧。

启用 Marketplace 报告

要使用 Marketplace 的内置报告功能，在 plugin.xml 中注册其错误处理器：

此处理器自 IntelliJ Platform 2023.3 起可用，无需自定义实现。对于支持 Split Mode 的插件，请在前端或共享插件模块中注册它。仅在后端注册将无法在前端使用。

用户可以通过 IDE 的错误报告 UI 提交报告，或启用 Send error reports to JetBrains automatically 以在后台自动发送。如果 Freezes 标签页为空，请检查你的处理器注册情况。报告还取决于用户的设置以及 IDE 是否识别出你的插件与此相关。

如果你维护自定义报告后端，⁠SDK error reporting guide 介绍了面向用户的 ErrorReportSubmitter API 以及用于自动后台报告的实验性 ErrorReportSink API。对于此处描述的内置 Marketplace 配置，你不需要自定义 sink。

如需视频概览，Patrick Scheibe 的 How IntelliJ Plugin Error Reporting Actually Works 比较了 Marketplace 报告与自定义 ErrorReportSubmitter。它还涵盖了提交了什么内容以及为什么附件对冻结报告很重要。

在选择修复方案之前检查证据

在将转储与你的代码匹配之前，检查它来自哪个插件版本。版本信息并不总是可用，这使得难以确定受影响的版本或对栈追踪进行反混淆。如果版本缺失，请将其标记为未知，而不是假设报告来自你的最新版本。

一旦你有了可能的原因，专注于阻止 UI 继续推进的操作。对于长时间的后台读操作，这可能意味着缩短访问模型的时间或选择可取消的读操作 API。将阻塞 I/O 保持在读操作之外，并确保任何可以重新开始的计算是安全可重试的。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）