Compose Multiplatform 开发架构与本地发布全流程从仓库组成到 publishToMavenLocal 实战【免费下载链接】compose-multiplatformCompose Multiplatform, a modern UI framework for Kotlin that makes building performant and beautiful user interfaces easy and enjoyable.项目地址: https://gitcode.com/GitHub_Trending/co/compose-multiplatform本指南以仓库 compose/README.md 为骨架系统讲解 Compose Multiplatform 在本仓库中的开发组织方式Core 核心库、Skiko 渲染层、Gradle 插件、附加组件与示例并完整还原将 Compose Multiplatform 库发布到本地 Maven 仓库的五个步骤结合 scripts 下三个发布脚本的真实实现与gradle-plugins、components、html的构建配置说明每个命令的底层原理。读完本文你将掌握如何使用COMPOSE_CUSTOM_VERSION环境变量驱动整套本地发布流程并理解版本号参数在子项目间的传递机制。一、开发组织概览本仓库与 Compose Multiplatform Core 的分工Compose Multiplatform 的开发并不是全部发生在本仓库内。根据 compose/README.md 的说明Compose Multiplatform 的**核心运行时Core**在独立的compose-multiplatform-core仓库中演进Compose Multiplatform 团队与贡献者在那里将 Jetpack Compose 移植适配到 iOS、DesktopJVM与 Web 等目标平台。本仓库则承担了核心运行时之外的配套部分包括Gradle 插件即org.jetbrains.compose插件的实现位于 gradle-plugins附加组件components如SplitPane、AnimatedImage、ui-tooling-preview等位于 componentsCompose HTML 库面向 Web 的声明式 UI 实现位于 html示例工程examples覆盖 Android、Desktop、iOS、Web 四大平台的完整可运行示例位于 examples。这种核心库独立、外围配套集中的仓库布局意味着若要在本地完整复现从源码构建一套 Compose Multiplatform 发行物必须先发布核心库再依次发布本仓库的插件、组件与 HTML 库——这正是发布章节五步流程的设计由来。二、渲染基石Skiko 在 Compose Multiplatform 中的角色理解 Compose Multiplatform 的架构绕不开 Skiko 这个底层依赖。文档明确指出Compose Multiplatform 使用 Skiko这是一个低层库作用是隐藏平台复杂性为渲染rendering、事件处理event handling、窗口管理window management等能力提供统一而简单的接口其图形 API 基于Skia。换句话说Skiko 是 Compose Multiplatform 跨平台 UI 得以运行在 JVM Desktop、iOS/macOS、Web 等不同宿主上的关键桥梁上层 Compose 组件树经过布局与绘制逻辑后最终由 Skiko 通过 Skia 在各平台绘制出实际像素窗口、输入事件等平台差异也被 Skiko 抽象收敛。从本仓库的组件构建配置也能看到这一点——components/settings.gradle.kts 的注释明确指出mavenLocal应排在第一位以便在本地构建时解析到正确版本的 skiko这印证了 Skiko 是各组件编译链接期即存在的硬性依赖。三、本仓库各组成部分速览3.1 Gradle 插件gradle-pluginsgradle-plugins/settings.gradle.kts 表明该多模块工程包含三个子项目:composeorg.jetbrains.composeGradle 插件本体源码位于 gradle-plugins/compose/src/main:preview-rpc用于 UI 预览Compose Preview的 RPC 模块gradle-plugins/preview-rpc/src/main:jdk-version-probe探测 JDK 版本的辅助模块gradle-plugins/jdk-version-probe/src/main。3.2 附加组件componentscomponents/settings.gradle.kts 收录了SplitPane、AnimatedImage、resources、ui-tooling-preview等独立组件库及其 demo 工程。这些组件依赖发布后的 Compose 核心版本见下文发布流程。3.3 Compose HTML 库htmlhtml 目录是 Compose Multiplatform 的 WebHTML实现包含html-core、html-svg、integration-core、compose-compiler-integration、test-utils、benchmark-core等子模块并在compose.web.buildSamplestrue时可联动构建 examples/html 下的 Web 示例详见 html/settings.gradle.kts。3.4 示例工程examplesexamples 提供了可实际运行的跨平台示例如 chat、codeviewer、imageviewer、issues、nav_cupcake 等每个示例都同时包含androidApp、desktopApp、iosApp与jsApp/webApp入口是验证本地发布结果的最佳测试载体。四、发布 Compose Multiplatform 库到本地 Maven4.1 为什么需要本地发布在日常开发或二次开发中修改核心库或插件源码后需要先将其安装到本地 Maven 仓库默认~/.m2/repository下游工程才能通过mavenLocal()解析到改动后的版本。发布流程以COMPOSE_CUSTOM_VERSION环境变量统一指定自定义版本号避免污染官方版本坐标。4.2 步骤 1设置 COMPOSE_CUSTOM_VERSION 环境变量export COMPOSE_CUSTOM_VERSION0.0.0-custom-versionCOMPOSE_CUSTOM_VERSION是整个发布流程的统一版本入口。该变量会被 compose/scripts 下的三个发布脚本读取并作为-Pcompose.version乃至-Pdeploy.version参数传给 Gradle从而覆盖子项目构建脚本中的默认版本。以本仓库默认配置为例gradle-plugins/gradle.properties 中预设了compose.version1.12.10-alpha01dev4472与deploy.version9999.0.0-SNAPSHOThtml/gradle.properties 中预设了compose.version1.10.1发布脚本会在命令行以-P属性覆盖这些默认值因此不修改任何gradle.properties也能产出指定版本。4.3 步骤 2发布核心库Core核心运行时库的发布需要依据compose-multiplatform-core仓库内MULTIPLATFORM.md的Publishing章节操作该仓库与本仓库相互独立发布核心库不在本仓库内执行。核心库发布完成后其产物会以COMPOSE_CUSTOM_VERSION对应的坐标出现在本地 Maven 中供本仓库后续步骤解析依赖。4.4 步骤 3发布 Gradle 插件./scripts/publishGradlePluginToMavenLocal执行该脚本前必须已经设置COMPOSE_CUSTOM_VERSION。查看脚本源码 compose/scripts/publishGradlePluginToMavenLocal其核心逻辑为检查COMPOSE_CUSTOM_VERSION是否为空为空则输出Must provide COMPOSE_CUSTOM_VERSION in environment并以退出码 1 终止进入 gradle-plugins 目录执行./gradlew publishToMavenLocal \ -Pcompose.version$COMPOSE_CUSTOM_VERSION \ -Pdeploy.version$COMPOSE_CUSTOM_VERSION这两个参数的分工可以从 gradle-plugins/buildSrc/src/main/kotlin/BuildProperties.kt 中确认composeVersion(project)优先读取环境变量COMPOSE_GRADLE_PLUGIN_COMPOSE_VERSION否则读取项目属性compose.version——它代表所配套的 Compose 核心版本被测试compose.tests.compose.version等逻辑引用deployVersion(project)优先读取环境变量COMPOSE_GRADLE_PLUGIN_VERSION否则读取项目属性deploy.version——它被用作插件自身的发布版本。在 gradle-plugins/build.gradle.kts 中所有子项目被统一设置为group org.jetbrains.compose、version BuildProperties.deployVersion(project)因此脚本传入的deploy.version决定了插件最终以哪个版本号安装到本地仓库。同文件还注册了一个聚合任务publishToMavenLocal它会遍历所有应用了maven-publish的子项目并级联触发各自的publishToMavenLocal因此一条命令即可发布:compose、:preview-rpc、:jdk-version-probe全部产物。4.5 步骤 4发布附加组件Components./scripts/publishComponentsToMavenLocal脚本源码 compose/scripts/publishComponentsToMavenLocal 会进入 components 目录执行./gradlew publishToMavenLocal \ -Pcompose.version$COMPOSE_CUSTOM_VERSION \ -Pcompose.useMavenLocaltrue这里与插件发布有两个关键差异只传入compose.version因为components是使用 Compose 的库而非插件本身它需要知道自己依赖的 Compose 核心版本号传入compose.useMavenLocaltrue查阅 components/gradle.properties默认compose.useMavenLocalfalse与 components/settings.gradle.kts当该属性为true时pluginManagement与dependencyResolutionManagement两个仓库列表都会插入mavenLocal()且依赖仓库中mavenLocal()被刻意放在最前面——注释明确说明这是为了在本地构建时解析到正确版本的 skiko。也就是说步骤 4 依赖步骤 2 发布的核心库也依赖本地已有的 Skiko 产物若解析不到构建将失败。4.6 步骤 5发布 Compose HTML 库./scripts/publishHtmlLibraryToMavenLocal脚本源码 compose/scripts/publishHtmlLibraryToMavenLocal 会进入 html 目录执行./gradlew publishToMavenLocal -Pcompose.version$COMPOSE_CUSTOM_VERSION同样只传compose.version。从 html/settings.gradle.kts 可见HTML 工程在插件解析阶段会读取compose.version通过resolutionStrategy将org.jetbrains.compose插件映射到本地坐标org.jetbrains.compose:org.jetbrains.compose.gradle.plugin:$COMPOSE_CORE_VERSION这再次印证了发布顺序必须先完成步骤 2 与步骤 3HTML 库才能在本地解析到对应版本的插件与核心运行时。html子模块html-core、html-svg、integration-core、compose-compiler-integration、test-utils等会一并发布benchmark-core默认参与除非通过compose.web.tests.skip.benchmarks跳过。五、发布后的验证与使用发布完成后可按以下方式验证与使用检查本地仓库产物查看~/.m2/repository/org/jetbrains/compose下是否出现了0.0.0-custom-version或你自定义的版本号对应的目录与 POM/JAR 文件在示例工程中切换版本将 examples 中某个示例如 imageviewer的gradle/libs.versions.toml或settings.gradle.kts中的 Compose 版本改为0.0.0-custom-version并确保构建脚本声明了mavenLocal()仓库即可针对本地产物运行示例验证改动回归确认本仓库的示例同时覆盖 Android、Desktop、iOS、Web 四种目标可分别运行对应的desktopApp、androidApp、iosApp、jsApp/webApp入口做跨平台验证。六、注意事项小结顺序不可颠倒核心库 → Gradle 插件 → 附加组件 → HTML 库后者都依赖前者已发布到本地的产物尤其是 Skiko 与org.jetbrains.compose插件坐标环境变量必须先设置三个脚本均以COMPOSE_CUSTOM_VERSION为空作为硬性失败条件exit 1忘记export会直接报错参数含义不同compose.version表示依赖/配套的 Compose 核心版本deploy.version表示插件自身的发布版本两者在插件发布时被设置为同一值但在组件与 HTML 发布时只涉及compose.versioncompose.useMavenLocal只用于组件工程它控制是否把本地 Maven 仓库插入依赖解析链并确保mavenLocal()优先于远程仓库从而让本地构建命中正确的 skiko。以上流程与脚本实现均可在 compose/README.md 及 compose/scripts 目录下直接核对若要深入插件的发布配置细节可继续阅读 gradle-plugins/build.gradle.kts 与 gradle-plugins/buildSrc/src/main/kotlin/BuildProperties.kt。【免费下载链接】compose-multiplatformCompose Multiplatform, a modern UI framework for Kotlin that makes building performant and beautiful user interfaces easy and enjoyable.项目地址: https://gitcode.com/GitHub_Trending/co/compose-multiplatform创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考