今天，我们想谈谈IntelliJ平台团队的一些当前项目，这些项目将影响IntelliJ IDEA和基于我们平台的其他IDE。 这些项目的结果将在明年发布； 其中一些将已经在2020.1版本中发布，该版本将在春季发布。 我们要谈论的项目涉及两个大领域：生产力和对现代发展方案的支持。
性能表现
分度速度
目前，索引是我们IDE性能最棘手的地方之一。 我们计划从多个方向来寻求解决方案。
首先，我们计划支持
现成的索引片段 。 现在，我们可以为JDK提供一个现成的索引片段供下载，而不是为每个IntelliJ IDEA副本重新索引java.lang.String类，该索引片段可以下载使用，而无需额外的CPU开销。 除了JDK，我们还在探索为Maven Central中的库以及其他IDE中的解释器和包提供现成的索引片段的可能性。 我们还希望允许团队和组织将现成的索引片段用于他们的项目代码，但是我们尚无具体计划。
其次，我们计划通过在索引编制过程中提供更广泛的操作来减少索引编制
对工作的
阻碍 。
第三，我们计划检测
索引异常并将它们通知用户。 异常包括索引太长或太频繁的文件，以及由异常引起的索引重建。 我们的目标是提出解决该问题并提高IDE性能的具体步骤。
最后，我们继续处理良好的旧优化方法-确保索引不会获取不必要的数据，并且索引过程会使用尽可能少的资源。
对IDE数据结构的新的多线程访问
性能的另一个问题点是用户界面的冻结。 今年，我们建立了一个基础架构来收集有关此类问题的信息。 这使我们能够解决许多问题（例如，我们创建并使用了一种标准机制来异步处理来自文件系统的事件）。 明年，我们计划进一步采取
行动，并采取一些措施
来修改 UI流中的
数据结构 。
在IntelliJ IDEA诞生之初，就做出了一项架构决定，要求对UI流中的IDE数据结构进行所有修改。 这包括基本操作（将字符插入文档）和冗长的操作（重新命名从许多地方调用的方法）。 这种体系结构大大简化了编程模型，但显然降低了接口的响应能力。
在过去的几年中，我们已经学会了如何克服此模型的局限性，这主要是因为我们将冗长的操作划分为必要更改的后台计算，并尽快将这些更改应用于UI流。 理想的解决方案是完全消除在UI线程中执行操作的要求，但是直到现在，我们还不了解如果不重写整个IDE代码和第三方插件就如何实现这一目标。 现在，我们有了一个体系结构选项，使我们能够逐步将代码迁移到新的多线程模型，并且我们开始着手实现它。
明年，我们计划在关键的UI组件和平台API中增加对新的多线程模型的支持。 当我们看到新模型稳定运行并提供了预期的改进时，我们将切换到该模型，从而摆脱了UI冻结问题的主要根源。
下载并卸载插件，无需重新启动
朝此方向工作的第一个结果已经在
2019.3版本中 ，该版本允许您安装颜色主题和键盘布局的插件而无需重新启动。 在下一版本中，我们计划将此支持扩展到所有类型的插件。 我们将支持大多数自己的插件的加载和卸载，而无需重新启动，并且我们已经发布了针对第三方插件编写者的
支持说明 。
在此阶段，主要优势将是无需重新启动即可轻松完成的插件更新。 将来，我们计划实现一个更有趣的目标：一个IDE，该IDE仅针对您在其中打开的每个项目自动下载必要的插件集。 使用Spring-Spring插件正在加载，您需要Angular-该插件可以为您服务。 未使用的插件将被自动禁用，并且不会消耗资源和占用界面空间。
开发脚本支持
协同编辑
共同编辑支持的请求在我们的问题跟踪器中获得了最多的票，我们很高兴地宣布我们正在致力于此功能。 在我们当前的方法中，区分了在存储了已编辑源代码的计算机上运行的“主” IDE和可以连接至主IDE且不需要拥有自己的源代码副本的“瘦客户机”。 每个连接的客户端都有自己的状态（一组打开的文件，一个回车位置，一个自动完成选项列表等），但是如果需要，它也可以“跟随”另一个用户。
瘦客户端可以访问IDE的基本功能，例如导航，自动完成和调试，但不支持100％的可用功能。 （例如，初始版本的当前计划中不包括使用版本控制系统。）目前尚不确定确切的支持功能集，并且我们还不准备回答有关支持什么以及何时支持的问题。
对共同编辑的支持基于
Rider协议，因此很可能首先出现在此产品中，然后传播到其他IDE。 无论如何，这些都不会出现在IntelliJ IDEA 2020.1版本中-这是一个较长的计划。
另外，应该指出的是，由于当前的共同编辑实现使用我们自己的协议，因此它将与非JetBrains工具不兼容。
瘦客户端方法在其他情况下可能很有用，例如将IDE后端移到云中，但是我们还没有准备好宣布这一领域的任何计划。
云启动支持
在相当长的一段时间内，我们的许多产品都支持在远程计算机和容器中运行和调试代码。 不幸的是，这种支持几乎到处都是以自己的方式实现的，甚至诸如Docker支持之类的通用功能在不同的IDE中看起来也有所不同。
现在，我们在平台级别添加了“执行环境”的概念，该概念提供了一种向其复制文件或从中复制文件以及在其中启动进程的方法。 在IntelliJ IDEA 2020.1中，我们支持在本地计算机，Docker容器中以及通过ssh连接执行。 您可以选择要在Java和Go的启动配置中运行的环境。
在将来的版本中，我们计划基于新架构统一对Docker和远程解释器的支持。 此外，我们将提供与云的更好的集成，以便您可以在云中的新虚拟机上启动该过程，而无需指定要连接的计算机的特定地址。
新设计模型设计
项目模型是IDE表示项目结构的方式：哪些文件与之相关，它们如何相互依赖，使用哪些库等。 多年来，IntelliJ IDEA设计模型为我们提供了很好的服务，但我们已经开始遇到其局限性。 首先，它不允许随机混合不同类型的项目。 您可以在Rider的AppCode或Visual Studio解决方案中打开Xcode项目，但是没有这样的IDE可以在一个窗口中打开Gradle和Xcode项目。 其次，它在目录级别工作，并且不允许同一目录中的不同文件具有不同的依赖性。 这使与Bazel等构建系统的集成变得复杂，并在其他情况下产生了问题。
我们称为工作空间模型的新设计模型消除了这些限制。 它还提供了其他好处，例如更快的项目打开，与Maven和Gradle的更流畅的同步以及更方便的编程模型。
我们将从将现有功能的实现转移到新的项目模型开始，然后，当一切稳定运行时，我们将开始添加新功能，例如在一个IDE窗口中打开一组不同类型的项目。
总结
我们刚才所说的只是团队正在开展的工作的一小部分，我们计划在假期后进一步介绍我们的计划。 当然，所有这些计划都是可以改变的，很可能这个故事的某些内容将永远不会发布，但是我们会为您做出其他很不错的改进。
我们期待您的回音。 此外，我们邀请您参加我们的抢先体验计划，该计划将使您有机会在正式发布之前尝试其中的某些功能。