Compose Multiplatform 发布流程实战指南：从 Skia/Skiko 升级到 Maven 发布与 Docker 镜像构建

Compose Multiplatform 发布流程实战指南从 Skia/Skiko 升级到 Maven 发布与 Docker 镜像构建【免费下载链接】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 Multiplatform 仓库中的 ci/release.md 为骨架完整讲解该项目的端到端发布流水线从更新底层 Skia 渲染库、发布 SkikoSkia 的 Kotlin 绑定层、把新版本 Skiko 引入 Compose到最终发布 Compose Desktop 组件与构建 CI 所用的 Docker 镜像。读完本文你将掌握每一环节的操作步骤、关键配置参数如dependencies.skia.windows/dependencies.skia.linux、SKIKO_VERSION、验证命令如./gradlew publishToMavenLocal以及背后涉及的仓库源码与脚本佐证可直接用于参与或复现 Compose Multiplatform 的发布过程。发布链路全景Compose Multiplatform 的三层依赖体系Compose MultiplatformCMP的桌面渲染栈是一条典型的自底向上依赖链SkiaC 图形库→ Skija/SkikoSkia 的 Kotlin/JVM 绑定→ Compose MultiplatformUI 框架。SkiaGoogle 开源的 2D 图形引擎负责所有实际的绘制、文本排版与光栅化工作。Compose 桌面端在渲染时并不直接调用 Skia而是经由其绑定层间接使用。Skija/SkikoJetBrains 维护的 Skia 绑定项目。Skija 侧重 JVM 侧原生绑定Skiko 则是 Compose Multiplatform 真正依赖的渲染层提供SkiaLayer、Surface、PictureRecorder等 API。Compose Multiplatform本文所在的仓库本体通过 Maven 坐标引用特定版本的 Skiko从而获得跨 JVM/原生/Web 的渲染能力。因此每次发布新版 Compose 之前通常都要先完成一次渲染层升级这也是 ci/release.md 中四大部分更新 Skia、发布 Skiko、在 Compose 中更新 Skiko、发布 Compose Desktop按顺序串成一条流水线的原因。此外发布环节还依赖 TeamCity CI 上的发布配置JetBrains 公共项目下 Compose/Skiko 相关的PublishRelease构建配置以及内部 Docker 镜像文中相应小节会一并说明。第一步更新 SkiaSkija 子模块升级Skia 的版本更新发生在Skija 仓库中而不是 Compose Multiplatform 仓库本身。发布流程的第一步是在 Skija 中推进third_party/skia子模块升级子模块在 skija 仓库中更新third_party/skia子模块指向的提交。验证构建运行skija_root/script/build.sh确认 Skija 构建没有被破坏。这一步是硬性门禁——只有本地三平台构建通过才允许进入后续发布环节。同步分支与版本变量如果使用的 Skia 分支发生变化例如从chrome/m85切换到chrome/m86需要同步更新三个平台构建脚本中的VER变量script/build_skia_linux.shscript/build_skia_windows.shscript/build_skia_macos.shVER变量直接决定 CI 拉取哪个 Skia 发行包分支切换而版本号未更新会导致拉取到错误产物。部署到 Bintray在 TeamCity 的JetBrainsPublicProjects_Compose_Skia_PublishRelease构建配置中点击Deploy或点击 ... 自定义发布选项把 Skia 产物发布出去。固定构建发布完成后在 TeamCity 上Pin该次构建以保留其产物不被清理策略回收保证后续 Skiko 构建能够稳定引用。在 Skiko 中同步版本更新skiko仓库skiko/gradle.properties中的以下参数dependencies.skija.git.commit—— Skija即 Skia 绑定的 Git 提交dependencies.skia.windows—— Windows 平台的 Skia 包版本dependencies.skia.linux—— Linux 平台的 Skia 包版本dependencies.skia.macos—— macOS 平台的 Skia 包版本release.md 原文中该行笔误重复写为windows按构建脚本与平台划分第三个应为 macOS 对应的版本参数。验证方式在skiko_root/skiko目录执行./gradlew publishToMavenLocal把 Skiko 发布到本地 Maven 仓库确保基于新 Skia 的 Skiko 可以正常构建并被本地方案引用。跨平台复查仅在本机验证往往不够例如本地是 Linux无法覆盖 Windows/macOS。可在 TeamCity 的JetBrainsPublicProjects_Compose_Skiko_BuildCheckManualTrigger构建配置中发起一次全平台构建检查点击 ...方式一在Changes标签页选择要验证的分支或提交方式二在General标签页勾选 run as a personal build 上传自定义 patch即可在提交正式代码前用补丁跑一遍全平台构建。第二步发布 SkikoSkiko 是 Compose 依赖链上真正对外发布的一环发布前必须先确认一切就绪发布就绪检查与团队成员确认所有必要变更均已合入并发布确定本次发布对应的 Git 提交branch/commit验证 sample 项目可正常运行例如cd skiko ./gradlew publishToMavenLocal cd samples/SkijaInjectSample ./gradlew run由于个人通常无法覆盖全部平台跨平台验证可以请对应平台的同事协助测试。执行发布在 TeamCity 的JetBrainsPublicProjects_Compose_Skiko_PublishRelease构建配置中点击Deploy并设置发布参数在Parameters标签页把 Skiko Release Version 设置为新的发布版本号例如0.1.6在Changes标签页选择要发布的分支/提交小技巧如果时间紧张可在General标签页勾选 put the build to the queue top把该构建插入到构建队列最前面优先执行。确认产物在 Skiko 的 GitHub Releases 页面检查新版本是否已正确发布。值得注意的是发布产物最终落到 JetBrains 的 Space Maven 仓库https://packages.jetbrains.team/maven/p/ui/dev这类 dev 仓库这是后续在 Compose 中更新 Skiko环节能够拉取到新版本的前提。第三步在 Compose 中更新 Skiko新版本 Skiko 发布后需要把它引入 Compose Multiplatform 的构建依赖。这一步通过 AOSPAndroid Open Source Project的importMavenArtifacts工具完成——Compose 的 Maven 依赖以 prebuilt 形式保存在 AOSP 的prebuilts/androidx/external仓库中使用androidx-dev-master/frameworks/support/development/importMaven/import_maven_artifacts.py脚本下载 Maven 产物# 如果本地 build.gradle.kts 的 repository 段还没有该仓库需要先添加 # maven(https://packages.jetbrains.team/maven/p/ui/dev) export SKIKO_VERSION0.1.6 import_maven_artifacts.py --name org.jetbrains.skiko:skiko-jvm:$SKIKO_VERSION import_maven_artifacts.py --name org.jetbrains.skiko:skiko-jvm-runtime-linux:$SKIKO_VERSION import_maven_artifacts.py --name org.jetbrains.skiko:skiko-jvm-runtime-windows:$SKIKO_VERSION import_maven_artifacts.py --name org.jetbrains.skiko:skiko-jvm-runtime-macos:$SKIKO_VERSION这里需要同时导入skiko-jvm本体与三个平台的 runtime 构件linux/windows/macos。它们各自携带对应平台的原生库是桌面端跨平台运行的基础。将变更提交到androidx-dev-master/prebuilts/androidx/external仓库并上传 CLchange list等待合入。仓库内的自动化佐证skikoAospCommit 脚本仓库的 compose/scripts/skikoAospCommit 脚本把上述导入 提交过程完全自动化可作为理解该环节内部细节的参考它要求通过环境变量AOSP_COMPOSE_SOURCE指定 AOSP 源码根目录并把 Skiko 版本作为命令行参数传入如./updateSkikoInAosp 0.4.15脚本会在prebuilts/androidx/external与frameworks/support两个仓库中基于aosp/androidx-main各创建skiko版本分支通过sed更新frameworks/support/gradle/libs.versions.toml中的skiko ...版本号随后删除旧的org/jetbrains/skikoprebuilt 目录并用 Gradle 的 importMaven 任务一次导入完整的 Skiko 构件清单包括skiko、skiko-awt以及 linux/macos/windows 的 x64/arm64 runtimeorg.jetbrains.skiko:skiko:$SKIKO_VERSION,\ org.jetbrains.skiko:skiko-awt:$SKIKO_VERSION,\ org.jetbrains.skiko:skiko-awt-runtime-linux-x64:$SKIKO_VERSION,\ org.jetbrains.skiko:skiko-awt-runtime-linux-arm64:$SKIKO_VERSION,\ org.jetbrains.skiko:skiko-awt-runtime-macos-x64:$SKIKO_VERSION,\ org.jetbrains.skiko:skiko-awt-runtime-macos-arm64:$SKIKO_VERSION,\ org.jetbrains.skiko:skiko-awt-runtime-windows-x64:$SKIKO_VERSION最后分别在两个仓库中git commitframeworks/support的提交信息为 Update Skiko to $SKIKO_VERSION并附上验证命令./gradlew jvmTest desktopTest -Pandroidx.compose.multiplatformEnabledtrue。这与 release.md 手写流程一一对应可作为发布时参考的完整实现。注意该脚本会写 AOSP 侧仓库仅供维护者使用本文仅作原理讲解。第四步发布 Compose Desktop当 Compose 侧已经切换到新版本 Skiko、所有测试通过后即可发布 Compose Desktop 组件本身在 TeamCity 的JetBrainsPublicProjects_Skija_JetpackComposeMpp_Dev即 Compose 构建配置中启动一次新构建。这一构建会产出 Compose Multiplatform 桌面端的所有 artifacts并发布到 JetBrains 的 Maven 仓库。后续开发者只需在build.gradle.kts中声明对应版本号即可使用。本地验证与发布辅助工具仓库中还提供了与发布相关的本地工具链可用于发布前的验证本地发布验证与 Skiko 一样Compose 自身也可以通过publishToMavenLocal在本地验证。仓库提供了封装脚本 compose/scripts/publishComponentsToMavenLocal其核心命令为./gradlew publishToMavenLocal -Pcompose.version$COMPOSE_CUSTOM_VERSION -Pcompose.useMavenLocaltrue通过-Pcompose.version指定自定义版本号、-Pcompose.useMavenLocaltrue让依赖解析优先使用本地仓库即可在完全离线的本地环境验证组件可发布性。发布辅助库ci/build-helpers/README.md 说明存在一个专门帮助 CMP 项目及其依赖向 Maven Central 发布 artifacts 的辅助库例如对 Skiko 执行./gradlew publish即可发布它会在 CMP 源码发生变更时由 CI 任务自动发布到https://packages.jetbrains.team/maven/p/cmp/dev。本地使用时既可以./gradlew publishToMavenLocal发布到本地也可以直接从源码以参数化方式执行./gradlew -pcli reuploadArtifactsToMavenCentral -Pmaven.central.signtrue \ -Pmaven.central.coordinatesorg.jetbrains.compose*:*:%version.COMPOSE%,org.jetbrains.compose.material:material-navigation*:%version.COMPOSE_MATERIAL_NAVIGATION% \ -Pmaven.central.stageorg.jetbrains.compose \ -Pmaven.central.descriptionCompose %version.COMPOSE% and associated libs \ -Pmaven.central.staging.close.after.uploadtrue发布后的清理从 Space 仓库删除旧包发布过程中JetBrains 的 Space Maven 仓库会积累大量历史版本尤其是各种-preview-*快照。仓库提供了专门的清理工具 ci/delete-packages-from-space/README.md其流程如下环境要求JDK 9生成个人 token在 Space 中创建带ReadRepository、WriteRepository、ViewProject权限的 token创建配置cp template.local.properties local.properties然后设置space.server.url与space.auth.token查询 ID运行./gradlew listProjectsAndPackageRepositories找出space.project.id与space.repo.id并填入配置生成删除清单运行./gradlew generateListOfPackagesToDelete -Pspace.package.version0.4.0-preview-*按版本通配符生成待删包列表写入build/packages-to-delete.txt人工确认取消注释要删除的包再运行./gradlew deletePackages执行删除。第五步构建与维护 Docker 镜像CI 构建离不开容器环境。release.md 中 Docker 镜像部分明确了两类操作本地构建Linux 镜像的本地构建说明见 docker/linux/README.md 对应的文档release.md 原文指向docker/linux/README.md与docker/windows/README.md当前仓库中可确认存在 Linux 测试镜像的 DockerfileWindows 镜像说明对应仓库中的docker/windows/README.md历史路径当前仓库已不再包含该目录说明 Windows 镜像构建已从本仓库移除。更新内部镜像当需要更新 JetBrains 内部 Docker registry 上的镜像时在对应 TeamCity 构建配置中发起构建LinuxJetBrainsPublicProjects_Compose_Docker_LinuxWindowsJetBrainsPublicProjects_Compose_Docker_Windows镜像内容参考Linux 测试镜像 Dockerfileci/docker/linux-tests/Dockerfile 展示了 CMP CI 测试环境的完整依赖栈可以帮助理解为什么 CI 需要这些基础环境基础系统ubuntu:24.04安装binutils、curl、fakeroot、libgl-dev、maven、python3、unzip、wget、xvfb虚拟 X server无头环境跑 GUI 测试必需、git、xz-utils等JDKOpenJDK 21openjdk-${JAVA_VERSION}-jdk并设置JAVA_HOMENode.jsNode 22供 Web/JS 目标与前端工具链使用UTF-8 环境LANGen_US.UTF-8、JAVA_TOOL_OPTIONS-Dfile.encodingUTF-8避免跨平台构建出现编码问题JetBrains RuntimeJBR安装jbr_jcef发行版内含 JCEF用于 Compose 桌面端嵌入 Chromium 的 WebView 场景Android SDK通过 commandline-tools 安装android-37.0平台浏览器与驱动安装固定版本的 Google Chrome ChromeDriver 与 Firefox GeckoDriver供 Web 目标的端到端/UI 测试使用。这套镜像内容与 release.md 中构建 Docker 镜像的环节互相印证CI 上的 Compose 构建需要同时覆盖 JVM 桌面、Android 与 Web 目标因此镜像必须提前备齐 JDK、Android SDK、浏览器驱动与虚拟显示环境。发布链路中的源码佐证Skiko 渲染 API 在 Compose 中的使用release.md 反复强调更新 Skia/Skiko 后必须验证构建与渲染没有回归。那么 Skiko 的 API 到底在 Compose 中扮演什么角色以基准测试模块为例benchmarks/multiplatform/benchmarks/src/skikoMain/kotlin/MeasureComposable.skiko.kt 直接展示了 Compose 与 Skiko/Skia 的交互方式代码直接 importorg.jetbrains.skia.Surface、org.jetbrains.skia.Color、org.jetbrains.skia.PictureRecorder、org.jetbrains.skia.Rect说明 Compose 的 Skiko 目标在渲染层直接对接 Skia 对象GraphicsContext接口要求实现类提供surface(width, height): Surface创建 Skia Surface与awaitGPUCompletion()等待 GPU 完成用于 GPU 时间测量mimicSkikoRender方法按 SkiaLayer 的渲染逻辑模拟一帧渲染用PictureRecorder录制 Compose 场景绘制命令为Picture清空画布后drawPicture到 Surface再flushAndSubmit提交给 GPU——其注释还说明如果跳过中间 Picture 录制基准测试结果可能产生 ±10% 的偏差文件顶部注释明确该方法复刻自 Skiko 的SkiaLayer.awt.kt渲染逻辑并提示如果新版 Skiko 不再使用 picture这里也需要同步删除。这段代码生动地说明Skia/Skiko 的任何一个渲染行为变化Surface 语义、Picture 录制、GPU 提交方式都会直接影响 Compose 的渲染正确性与性能因此 release.md 中升级 Skia → 重建 Skiko → 全平台验证的门禁流程绝非可有可无。总结一次完整发布需要执行的关键动作清单阶段核心动作关键参数/命令验证手段更新 Skia升级 skija 的third_party/skia子模块VER三个平台构建脚本script/build.sh发布 SkiaTeamCity PublishRelease 配置点 Deploy并 Pin 构建—保留产物可被后续引用同步 Skiko 依赖更新skiko/gradle.propertiesdependencies.skija.git.commit、dependencies.skia.windows/linux/macos./gradlew publishToMavenLocal BuildCheck 全平台构建发布 SkikoTeamCity PublishRelease 点 DeploySkiko Release Version 设置为新版本号sample 项目./gradlew runCompose 引入新 Skikoimport_maven_artifacts.py导入 artifacts 并提交 prebuiltsSKIKO_VERSION如0.1.6可参考 skikoAospCommit 自动化脚本发布 Compose DesktopTeamCity Compose 配置发起新构建—本地可用 publishComponentsToMavenLocal 预验证清理旧包可选Space 仓库删除历史版本space.package.version通配符见 delete-packages-from-spaceDocker 镜像本地构建或 TeamCity 更新内部镜像Linux/Windows 对应配置见 linux-tests/Dockerfile整体来看Compose Multiplatform 的发布是一条渲染层先行、平台全量验证、CI 统一发布的严谨流水线任何一层的版本推进都必须以构建与渲染回归验证为前置条件。对想要参与 Compose 生态贡献、或者在自己的项目中维护基于 Skia/Skiko 渲染栈的开发者而言理解这条链路就等于掌握了整个桌面 UI 生态最关键的一根升级主动脉。【免费下载链接】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），仅供参考