共计 2441 个字符，预计需要花费 7 分钟才能阅读完成。
JetBrains 发文介绍了其 IntelliJ 平台 2020 年的路线图。
文章次要介绍了以后 JetBrains 在改良 IntelliJ IDEA 和基于 IntelliJ 平台的 IDE 方面所做的一些工作，次要包含性能和对古代开发工作流的反对两个方面。
改良后果将会在明年公布，其中一些会公布在秋季的 2020.1 版本中。
性能
索引性能
与 IDE 性能无关的两个次要痛点是启动性能，索引耗时较长的工具被认为是重量级的。JetBrains 示意，明年关注点将转向索引性能方面。
针对此问题官网采取了多管齐下的办法。首先，反对应用预建的索引块，这样每个用户 IntelliJ 实例都不用执行索引 java.lang.String 类的工作。
打算明年逐渐提供反对，从 JDK 开始，而后涵盖 Maven Central 的库以及其它 IDE 中的解释器和包。同时还在钻研反对团队或企业内我的项目源代码的索引块共享的办法，尽管这一块目前还没有任何具体打算。
其次，打算通过在索引时提供更多的 IDE 操作来缩小索引的破坏性。
第三，将检测并告诉用户无关索引异样的信息，包含索引破费工夫太长的文件、索引从新建设频率太高的文件以及异样导致的索引重建，目标是提供解决这些问题并进步 IDE 在我的项目上的性能的清晰步骤。
同时也打算反对进行旧性能优化，以确保索引零碎不会执行任何不必要的工作并且不会产生可防止的开销。
读 / 写锁线程模型从新设计
UI 卡死（freeze，解冻）是一个很大的问题。往年尽管曾经构建了用于报告此类卡死问题的根底，并进行了架构更改以修复许多相干问题，比方文件系统事件的异步侦听器，然而接下来的一年中，打算迈出更大的一步：将须要写锁定的操作移出 UI 线程。
早在 IntelliJ IDEA 晚期就做出了一项架构决定，该决定要求大多数操作须要批改 IDE 的外部数据结构能力在 UI 线程上运行，也就是包含基本操作（将字符插入文档中）和大规模操作（重新命名具备数千种用法的办法）。
这种架构的益处是简略的编程模型，然而显著的毛病是 UI 响应能力在许多状况下都会受到影响。
多年以来，官网始终在寻找办法来解决此架构的局限性，次要是将大型操作拆分为在后盾运行并利用于 UI 线程的局部。一个更根本的解决方案是齐全解脱 UI 线程的要求，然而直到最近，还不晓得如何在不对本人的代码和第三方插件进行重大重写的状况下做到这一点。
不过当初，JetBrains 曾经有了一个容许逐渐迁徙的架构解决方案，并且正在开始施行。明年将重构 IntelliJ 平台的根本 UI 组件和 API，以采纳新的线程模型。一旦新模型稳固并且能够看到改良，将在所有 IDE 中切换到新模型，从而使 UI 平滑且没有滞后。
无需重启即可加载和卸载插件
该个性曾经在 IntelliJ IDEA 2019.3 中预览，它使开发者不必重新启动就能够装置主题和键盘映射插件，无缝降级。2020.1 版本中会将此反对扩大到所有类型的插件。
打算将为大部分捆绑的插件提供反对，并且会为第三方插件开发人员提供反对阐明。
这项工作更有意义的中央在于，它的最终目标是 IDE 能够依据开发者关上的每个我的项目的大小自行调整大小，比方仅针对应用 Spring 的我的项目加载 Spring 插件，仅针对 Angular 我的项目加载 Angular 插件。
这样如果不应用某项技术，那么就不会看到与此相关的任何 UI 元素，也不会看到反对该技术的插件对性能或内存使用量产生任何影响。
工作流反对
协同编辑
协同编辑是问题跟踪器中投票最高的申请，目前 JetBrains 也在跟进这一性能。在目前采纳的办法中，将有一个主 IDE 在运行源代码的计算机上运行，其余用户可能将其 IDE 作为“瘦客户机”连贯到主 IDE，而无需间接进行源代码拜访。
每个连贯的用户都将具备本人的状态，包含关上文件集与插入号地位等，并且能够依据须要抉择“追随”另一个用户。
瘦客户机用户将有权拜访外围 IDE 性能，例如导航、补全和调试，但不能拜访残缺的功能集，例如，在初始版本中，瘦客户端可能无奈执行版本控制操作。
协同编辑反对基于 Rider 协定，因而很可能首先在 Rider 中公布，而后扩大到其它 IDE。不过这是一项长期工作，IntelliJ IDEA 2020.1 版本中临时还是看不是相干成绩的。
反对云执行
相当长一段时间以来，许多 JetBrains 产品都反对在容器内运行和调试代码，然而，在不同产品中这些性能的实现之间并没有太多相关性，甚至基本功能（如 Docker 反对）的 UI 也不统一。
当初 JetBrains 引入了指标环境的概念，该概念提供了一种可双向复制文件并在指标环境中启动过程的办法。在 IntelliJ IDEA 2020.1 中，受反对的环境将包含本地计算机、Docker 容器和通过 ssh 连贯的计算机。
在后续发行版中，打算对立反对围绕新架构的现有 Docker 和近程解释器。除此之外，还将提供更深刻的星散成。
从新设计我的项目模型
我的项目模型是 IDE 示意我的项目构造的形式：哪些文件属于该我的项目、它们如何相互依赖、应用哪些库……我的项目模型有肯定的局限性，首先，它不反对任意混合不同类型的我的项目。
例如，AppCode 能够关上 Xcode 我的项目，Rider 能够关上 Visual Studio 解决方案，然而无奈在同一 IDE 框架中关上 Gradle 我的项目和 Xcode 我的项目。
其次，我的项目模型在目录级别上工作，而不在文件级别上，并且它不能示意同一目录中具备不同依赖项的不同文件，这使得很难将诸如 Bazel 之类的构建系统集成到 IDE 中，同时也给其它场景带来了问题。
从新设计的我的项目模型（外部称为“工作区模型”）将打消这些限度。同时它还带来了其它益处，例如在我的项目关上期间进步性能、与 Maven 和 Gradle 进行更顺畅的同步以及更好的编程模型。
JetBrains 还示意接下来将公布更多打算信息，详情查看：https://blog.jetbrains.com/idea/2019/12/intellij-platform-roadmap-for-2020