Java开发人员请注意！IntelliJ IDEA 2020.1平台路线图您知道吗

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有任何期待或想法，欢迎在评论区留言~