Gradle 软件模型的现状和未来
我们收到了很多关于 Gradle 软件模型 的状态和方向的询问，特别是来自构建原生库和应用程序的用户。
在这篇博文中，我们将解释软件模型的当前状态和未来，特别是它与使用 Gradle 的原生开发的关系。2017 年剩余时间计划进行许多激动人心的改进；请参阅 下面的路线图。
软件模型的现状
简而言之，软件模型是一种非常声明式的方式来描述如何构建软件以及在过程中需要的其他组件作为依赖项。它还提供了一个新的基于规则的引擎来配置 Gradle 构建。当我们开始实施软件模型时，我们给自己设定了以下目标
- 提高配置和执行时间性能。
- 使使用复杂工具链的构建定制更容易。
- 提供一种更丰富、更标准化的方式来建模不同的软件生态系统
在开发软件模型时，Gradle 工程团队不断尝试将这些概念应用到现有的软件生态系统中。用于构建原生应用程序的 Gradle 插件目前完全基于软件模型。类似地，针对 Android 和 Java 等生态系统开发了基于软件模型的实验性插件。
Gradle 在原生生态系统中的采用正在增加，我们的投资也在增加。自成立以来，Gradle 的原生支持 已证明自己是使用 Make 的构建的受欢迎的替代方案。凭借其声明性和表达性模型，对不同工具链和平台的支持以及并行编译等功能，它为构建原生库和应用程序提供了一种革命性的方式。
我们花费了比预期更长的时间来演进新的配置和软件模型，并使其与当前的 Java 和 Android Gradle 模型一样强大。与此同时，Gradle 的采用率激增，许多复杂的构建使用的是当前模型，并且存在一个由 1500 多个社区插件组成的充满活力的生态系统。我们低估了这些构建和插件迁移到新模型的复杂性，并看到了许多合作伙伴在进行此迁移时所表现出的可以理解的抵触情绪。
事后看来，新的软件和配置模型的范围太大了。这就是为什么在 2016 年的 Gradle 峰会上，Hans Dockter 宣布我们将把许多功能移植回当前模型。一年后，大多数针对 Java 和 Android 生态系统的功能都已移植回来。这包括变体感知依赖项解析和 Java 组件的 API 和实现分离。这些功能在 工作避免 和 性能 方面是游戏规则的改变者。此外，我们还找到了其他方法来大幅提高 Gradle 配置性能，并且还有更多改进即将推出。Gradle 构建配置方式不再需要发生任何重大且不兼容的改变。
前进的道路
因此，您可能想知道软件模型发生了什么变化。我们正在将原生支持的配置 DSL 移植到当前模型。因此，声明性性质和强大的建模语言将保持不变。软件模型中包含的规则引擎将被弃用。模型块下的所有内容都将作为当前模型的扩展进行移植。原生用户将不再拥有与 Gradle 社区其他用户不同的扩展模型，他们将能够使用新的变体感知依赖项管理。
路线图是什么样的？以下是今年年底之前的重点领域
- 当前模型对原生的支持。基于当前模型的新插件集正在开发中，并且随着每个夜间版本的发布而得到改进。它们还需要更多工作才能实现功能奇偶性和稳定性，但已经提供了许多功能。尝试一下并给我们反馈。
- 编译和链接任务默认并行化。通过默认启用编译和链接任务的并行化，我们计划提高原生生态系统的性能。这将对所有使用 Gradle 构建原生项目的开发者产生积极影响。
- 传递依赖解析。我们正在将这个强大的功能从 JVM 生态系统移植到原生生态系统，以帮助原生开发者在原生项目之间声明丰富的依赖关系。
- 基于当前模型的新原生插件。我们的计划是提供具有软件模型插件大部分功能的插件，同时还将提供一些重要的新功能，例如构建缓存和原生项目的外部源依赖。
- 改进的工具链支持。我们正在努力解决工具链声明中的一些问题，这对于嵌入式开发尤为重要。
有关最完整和最新的进展，我们建议您查看 gradle-native 项目，这是原生生态系统功能规划的中心。
从软件模型插件迁移到新插件的过程将非常无缝。所有核心原生任务都将被重用，工具链概念也将移植到当前模型。我们预计您的大部分构建逻辑可以简单地重用。我们将长期支持基于软件模型的插件，以确保每个人都能顺利迁移。
如果您目前正在使用或计划使用 Gradle 构建原生项目，请继续使用。Gradle 的原生支持已被证明比目前可用的工具更具性能、灵活性和易用性。
令人兴奋的事情正在发生
今天，我们正在开发 IDE 集成和 XCTest 支持，并提供开箱即用的 HTML 报告生成和 完整的构建扫描支持。工具链定义也将得到改进，以允许更轻松地与其他工具链系列集成；这对投资于嵌入式领域的使用者来说尤其令人兴奋。
对于多仓库开发者，您将很高兴地了解到 复合构建 将适用于所有原生项目。
新插件将与 Kotlin DSL 集成，为 Gradle 用户提供适当的 IDE 支持，包括自动完成和重构。
我们将首先在当前模型中实现完整的原生开发工作流程，没有任何自定义 - 即没有平台、构建类型或工具链配置。工作流程指的是与构建二进制文件相关的所有内容，以及测试、打包、部署和与您最喜欢的 IDE 集成。最初，工作流程将适用于最常见的情况。在后续版本中，我们将通过逐步向整个工作流程添加自定义来进行。
社区参与
我们的原生社区是 论坛 上最活跃和最积极的社区之一，我们希望鼓励并进一步发展这种参与度。请继续互相帮助在论坛中找到您正在寻找的答案，但也请通过以下方式与我们互动：尝试 各种原生示例项目，订阅 gradle-native 项目 并提交问题，对您认为最重要的问题进行投票，甚至考虑提交拉取请求，如果您想卷起袖子参与进来。
保持被动了解原生平台支持的最佳方式是订阅 每月通讯 或更频繁的 Twitter 公告。
我们期待与您合作开发最佳的原生构建工具！