IntelliJ IDEA 2019.3提供了重大的性能和可用性改进，包括更快的启动，主题和键盘映射插件的安装更容易，增强的VCS工作流以及增加了对微服务框架，MongoDB等的支持。但是，这远远不够！我们想介绍一下我们当前在改进IntelliJ IDEA和基于IntelliJ平台的其他IDE方面所做的一些工作。这些努力的结果将在明年发布，其中一些将在**2020.1春季发布。它们围绕两个主要主题：性能和对现代开发工作流的支持。
性能
索引表现
与我们的IDE的性能有关的两个主要痛点是启动性能（索引耗时较长的工具被认为是重量级的）。在今年，我们做了很多工作来加快启动速度，明年，我们将注意力转向索引性能。
我们针对此问题采取了多管齐下的方法。首先，我们使使用预建的索引块成为可能，这样星球上的每个IntelliJ实例都不必执行相同的索引java.lang.String类的工作。我们计划在这一年中逐步提供支持，从JDK开始，然后涵盖Maven Central的库以及其他IDE中的解释器和包。我们还在研究支持团队或企业内项目源代码的索引块共享的方法，但是目前我们还没有任何具体计划。
其次，我们计划通过在编制索引期间提供更多的IDE操作来减少编制索引的破坏性。
第三，我们将检测并通知您有关索引异常的信息，包括索引花费时间太长的文件，索引重新建立频率太高的文件以及异常导致的索引重建。我们的目的是提供解决这些问题并提高IDE在您的项目上的性能的清晰步骤。
当然，我们计划投资进行良好的旧性能优化，以确保索引系统不会执行任何不必要的工作并且不会产生可避免的开销。
读/写锁线程模型重新设计
用户冻结的另一个主要问题是UI冻结。今年，我们构建了用于报告此类冻结的基础结构，并进行了体系结构更改以修复许多冻结问题（例如，文件系统事件的异步侦听器）。在接下来的一年中，我们计划迈出更大的一步，将需要写锁定的操作移出UI线程。
早在IntelliJ IDEA的早期，就做出了一项架构决定，该决定要求大多数操作修改IDE的内部数据结构才能在UI线程上运行。这意味着基本操作（将字符插入文档中）和大规模操作（重新命名具有数千种用法的方法）。这种架构的好处是简单的编程模型，但是明显的缺点是UI响应能力在许多情况下都会受到影响。
多年以来，我们一直在寻找方法来解决此体系结构的局限性，主要是将大型操作拆分为在后台运行并应用于UI线程的部分。一个更基本的解决方案是完全摆脱UI线程的要求，但是直到最近，我们还不知道如何在不对自己的代码和第三方插件进行重大重写的情况下做到这一点。现在，我们有了一个允许逐步迁移的体系结构解决方案，并且我们正在开始实施它。
明年，我们将重构IntelliJ平台的基本UI组件和API，以采用新的线程模型。一旦新模型稳定并且可以看到改进，我们将在所有IDE中切换到新模型，从而使UI平滑且没有滞后。
无需重启即可加载和卸载插件
对于此功能，您已经在IntelliJ IDEA 2019.3中看到了先睹为快的预览，该预览使您无需重新启动即可安装主题和键盘映射插件。在2020.1中，我们计划将此支持扩展到所有类型的插件。我们将为大部分捆绑的插件提供加载和卸载功能，而无需重启，并且会为第三方插件开发人员提供支持说明。在此阶段，最重要的用户利益将是无缝插件升级，而无需重新启动IDE。
这项工作的最终目标（对于2020.1之后的版本）是拥有一个IDE，该IDE可以根据您在其中打开的每个项目的大小自行调整大小。仅针对使用Spring的项目加载Spring插件，仅针对Angular项目加载Angular插件，依此类推。如果您不使用某项技术，那么您将看不到与此相关的任何UI元素，也不会看到支持该技术的插件对性能或内存使用量产生任何影响。
工作流程支持
协同编辑
协作编辑是问题跟踪器中投票最高的请求，我们很高兴地宣布我们正在对此进行努力。在我们目前采用的方法中，将有一个主IDE在运行源代码的计算机上运行，其他用户将能够将其IDE作为“瘦客户机”连接到主IDE，而无需直接源代码访问。每个连接的用户都将具有自己的状态（打开文件集，插入号位置，完成变体列表等），并且可以根据需要选择“跟随”另一个用户。
“客户机”用户将有权访问核心IDE功能，例如导航，完成和调试，但不能访问完整的功能集。（例如，在初始版本中，瘦客户端可能无法执行版本控制操作。）请注意，目前尚不确定为瘦客户端设置的完整功能，因此我们将无法回答有关何时或是否支持特定功能。
协作编辑支持基于Rider协议，因此很可能首先在Rider中发布，然后扩展到其他IDE。无论如何，请不要指望在IntelliJ IDEA 2020.1中发布有关此方向的任何工作–这是一项长期的工作。
还请注意，我们当前的协作编辑方法基于我们自己的协议，并且不支持与非JetBrains IDE的互操作性。
我们正在考虑将“瘦客户机”方法扩展到协作编辑之外的其他方案的可能性，例如在云中运行IDE后端，但是我们还不准备宣布该领域的具体计划。
云执行支持
相当长一段时间以来，许多JetBrains产品都支持在非您的计算机上或在容器内运行和调试代码。但是，在不同产品中这些功能的实现之间并没有太多共享，甚至基本功能（如Docker支持）的UI也不一致。
现在，我们介绍目标环境的一般概念，该概念提供了一种向其复制文件或向其复制文件并在其中启动进程的方法。在IntelliJ IDEA 2020.1中，受支持的环境将包括您的本地计算机，Docker容器或通过ssh连接的计算机。目标环境的选择最初可用于Java和Go运行配置。
在后续发行版中，我们计划统一围绕新架构的现有Docker和远程解释器支持。除此之外，我们还将提供更深入的云集成，因此您可以说该过程需要在云中的新VM上运行，而无需指定要连接的特定计算机的详细信息。
重新设计项目模型
项目模型是IDE表示项目结构的方式–哪些文件属于该项目，它们如何相互依赖，使用哪些库，等等。多年来，IntelliJ IDEA的项目模型为我们提供了很好的服务，但是它具有一定的局限性。首先，它不支持任意混合不同类型的项目。例如，AppCode可以打开Xcode项目，Rider可以打开Visual Studio解决方案，但是无法在同一IDE框架中打开Gradle项目和Xcode项目。其次，项目模型在目录级别上工作，而不在文件级别上工作，并且它不能表示同一目录中具有不同依赖项的不同文件。这使得很难将诸如Bazel之类的构建系统集成到IDE中，并在其他场景中提出了挑战。
重新设计的项目模型（我们内部称为“工作区模型”）将消除这些限制。它还带来了其他好处，例如在项目打开期间提高性能，与Maven和Gradle进行更顺畅的同步以及更好的编程模型。我们将从将内部实现更改为工作区模型开始，一旦这种情况稳定下来，我们将继续添加用户可见的功能，例如在同一IDE框架中组合任意类型的项目。
摘要
这篇文章中描述的工作只是我们团队一直在努力的一小部分，我们计划在假期后发布有关计划的更多信息。当然，所有这些都可能会发生变化，并且上述某些工作很可能不会发布，但是我们会为您提供其他很棒的东西。
如果您对IntelliJ IDEA2020.1有任何期待或想法，欢迎在评论区留言~