IntelliJ 平台 2020 年路线图
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
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
V8 发布 v8
V8 发布了 8.0 版本,此版本除了修复一些 bug,毫无疑问又带来了性能的提高。目前是预览,正式版将于几个星期后随Chrome 80Stable 一起发布。 性能改进 先看看性能改进,这包括内存占用减少与速度提升: 指针压缩 V8 堆包含整个项目所有东西,例如浮点值、字符串字符、编译的代码和标记值(tagged values),标记值代表指向 V8 堆的指针或小整型,开发团队发现这些标记值占据了堆的大部分空间。 标记值与系统指针一样大,对于 32 位架构来说,它们的宽度为 32 位,而在 64 位架构中,则为 64 位。在将 32 位版本与 64 位版本进行比较时,为每个标记值使用的堆内存是原来的两倍。 此版本通过一个方法减小了这一块内存:指针压缩。因为高位可以由低位合成,只需要将唯一的低位存储到堆中即可节省内存资源,经过测试,平均节省了 40% 的堆内存。 通常在减少内存的同时,也会牺牲速度性能,但是经过这一改进,V8 及其垃圾收集器中,都能够看到真实网站性能的提升。 优化高阶内置程序 此版本消除了 TurboFan 优化管道中的一个限制,该限制阻止了对高阶内置函数的优化。 ...
- 下一篇
每日一博 | 2020年 我要这样写代码
在 9102 年年初,一位室友问我一个问题,如何才能够提升写代码的能力? 可惜的是: 当时仅仅回复了一些自己的想法,如多看开源代码,多读书,多学习,多关注业界的动向与实践,同时也列了一些原则。但是这些并没有所总结,又或者说没有例子的语言始终是空泛的。所以在今年年底之际,对应着今年中遇到的形形色色的代码问题来一一讲解一下。 好代码的用处 实际上本书建立在一个相当不可靠的前提之上:好的代码是有意义的。我见过太多丑陋的代码给他们的主人赚着大把钞票,所以在我看来,软件要取得商业成功或者广泛使用,“好的代码质量”既不必要也不充分。即使如此,我仍然相信,尽管代码质量不能保证美好的未来,他仍然有其意义:有了质量良好的代码以后,业务需求能够被充满信心的开发和交付,软件用户能够及时调整方向以便应对机遇和竞争,开发团队能够再挑战和挫折面前保持高昂的斗志。总而言之,比起质量低劣,错误重重的代码,好的代码更有可能帮助用户取得业务上的成功。 以上文字摘抄于《实现模式》的前言,距离本书翻译已经时隔 10 年了,但是这本书仍旧有着很大的价值。同时对于上述言论,我并不持否认意见。但是我认为,坏代码比好代码更加的费财(...
相关文章
文章评论
共有0条评论来说两句吧...