稳定性全面升级！Compose Multiplatform 1.11 RC 正式推送

本文首发于公众号"Android技术圈"

前言

JetBrains 在 2026 年 5 月 5 日发布了 Compose Multiplatform 1.11.0-rc01。

这是一个预发布版本，变更范围不大，但修的点都贴近真实开发：焦点行为默认值调整、RTL 文本 + IME 崩溃、Skia Path 内存泄漏、iOS / Desktop / Web 平台问题。

先看版本号

Gradle 插件版本是：

bash 复制代码

plugins {
    id("org.jetbrains.compose") version "1.11.0-rc01"
}

核心 Compose Multiplatform 库也对应到 1.11.0-rc01：

bash 复制代码

dependencies {
    implementation(compose.runtime)
    implementation(compose.foundation)
    implementation(compose.ui)
    implementation(compose.material3)
}

这次 release 是 从 1.11.0-beta03 之后的增量变化，不是一个功能堆叠版。已经在跟 1.11 线的项目，可以把它当成 RC 验证版本；还在稳定生产线上的项目，不需要因为这个版本立刻切主干。

焦点：鼠标按下清焦点默认关掉

这次唯一列在 Features 里的变更，是一个 prerelease fix：

isClearFocusOnMouseDownEnabled 默认值变成 false。

这个开关名字很直白：鼠标按下时，要不要把当前焦点清掉。

在桌面和 Web 场景里，焦点不是小问题。文本框、菜单、弹层、快捷键区域，都可能依赖当前 focus 状态。鼠标点一下空白处就清焦点，看起来像"符合直觉"，但放在复杂 UI 里，容易产生两个副作用：

• 文本输入流程被打断
• 组件内部的焦点状态和鼠标交互抢时序

把默认值改成 false，更像是把行为收回到保守侧。对开发者来说，重点不是"以后不会清焦点"，而是 不要把 RC 版本里的焦点默认行为当成最终不变量。

如果你的桌面端有下面这类逻辑，升级后要重点回归：

bash 复制代码

@Composable
fun SearchBox() {
    var keyword by remember { mutableStateOf("") }

    TextField(
        value = keyword,
        onValueChange = { keyword = it },
        modifier = Modifier.fillMaxWidth()
    )
}

这段代码本身没问题，问题在外围：如果页面里有点击空白关闭键盘、失焦隐藏候选项、失焦提交搜索这类逻辑，升级后需要重新确认鼠标按下和焦点状态变化的顺序。

RTL + IME：文本输入崩溃修了

Multiple Platforms 里修了一个更具体的问题：

从右到左选择文本后，再通过 IME 输入字符会崩溃。

这个问题影响面看起来窄，但它踩的是国际化输入链路。RTL 文本、选区、组合输入、IME 提交字符，这几件事叠在一起，最容易暴露文本引擎里的边界错误。

如果你的产品有阿拉伯语、希伯来语等 RTL 语言用户，或者有混排文本输入场景，这个修复比普通 UI bug 更关键。因为文本输入一旦崩溃，用户没有绕路方案。

可以在升级验证里加一个简单手测路径：

这类问题不适合只看 Android。Compose Multiplatform 的文本链路会跨 iOS、Desktop、Web，不同平台 IME 行为差异很大。真正要上线多端输入能力，最好把这条路径放进每个平台的验收清单。

Skia：Path 变更后的内存泄漏修了

另一个 Multiple Platforms 修复是：

迁移到 Skia m144 后，mutating Path 时出现的内存泄漏被修复。

这条对做自定义绘制的人更敏感。

Compose Multiplatform 底层大量绘制能力都依赖 Skia。Path 又是自定义图形、动画轨迹、图表、手写板、地图覆盖物里很常见的对象。只要你在高频动画或连续绘制里反复修改 Path，泄漏就会被放大。

典型代码可能长这样：

bash 复制代码

@Composable
fun Wave(progress: Float) {
    Canvas(Modifier.fillMaxSize()) {
        val path = Path().apply {
            moveTo(0f, size.height / 2)
            quadraticTo(
                size.width * progress,
                0f,
                size.width,
                size.height / 2
            )
        }

        drawPath(path, color = Color(0xFF2C6CB0))
    }
}

如果这类绘制在动画中每帧触发，泄漏会表现成内存缓慢爬升，最后变成卡顿、掉帧，甚至进程被系统回收。

升级到 1.11.0-rc01 后，建议把下面几类页面跑一遍长时间测试：

• 自定义图表
• 手势轨迹
• 画板 / 签名
• 地图上的动态覆盖物
• 带 Path morph 的动画

这类 bug 的麻烦在于短测不容易发现。最好开 profiler，或者至少做 10 到 30 分钟的持续交互观察。

iOS：WindowInsets.systemBars 横向 inset 修正

iOS 侧修了 WindowInsets.systemBars 在 iOS 26.0 上额外增加 horizontal insets 的问题。

这类问题通常不表现为崩溃，而是页面"看起来不对"：内容被挤窄、左右留白异常、全屏区域和系统栏避让不一致。

如果你的 iOS 端有沉浸式页面、底部导航、横屏页面，升级后要看这些地方：

bash 复制代码

Box(
    modifier = Modifier
        .fillMaxSize()
        .windowInsetsPadding(WindowInsets.systemBars)
) {
    // page content
}

WindowInsets 的问题最怕只在单机型上验。iPhone 刘海屏、灵动岛、横屏、iPad 分屏，都会影响最终布局。这个修复点明确指向 iOS 26.0，说明它和系统版本行为有关，不只是 Compose 自己的布局计算问题。

Desktop：ComposePanel 的 Metal 离屏渲染崩溃修复

Desktop 侧修的是一个比较具体的组合：

ComposePanel 在 compose.swing.render.on.graphics 模式下，绘制到 Software renderer 时，Metal offscreen rendering 崩溃。

关键词有三个：ComposePanel、Swing interop、Metal。

如果你的桌面应用是纯 Compose Window，这条未必直接影响你。但如果你在老 Swing 应用里嵌 Compose，或者有一部分界面还依赖 Swing 容器，这条就要看。

这类工程通常长这样：

bash 复制代码

val panel = ComposePanel().apply {
    setContent {
        App()
    }
}

frame.contentPane.add(panel)

Desktop 端的问题经常不是 API 用错，而是渲染路径叠加后出事。Swing、Skia、Metal、离屏缓冲、Software renderer，只要组合不同，表现就可能不同。

所以 Desktop 升级验证不要只跑"能打开窗口"。至少要覆盖：

• Swing 内嵌 Compose 的页面
• 弹窗 / Overlay / Popup
• 高 DPI 屏幕
• macOS Metal 渲染路径
• 截图、打印、导出图片等软件绘制路径

Web：移动浏览器和 Safari 交互修复

Web 侧这次有三条：

• 移动浏览器里 Fast Delete 处理修复
• iOS 26.4 上虚拟键盘每次点击后跳动的问题修复
• Safari 里拖放操作后，按钮需要第二次点击才响应的问题修复

这三条都属于"用户会觉得页面坏了"的交互问题。

Fast Delete 影响输入删除体验；虚拟键盘跳动会让输入框和页面位置不稳定；Safari 第二次点击才响应，则会直接破坏按钮反馈。

如果你的 Compose Web 页面有表单、搜索、评论、编辑器，升级后应该重点测移动端，而不是只在桌面 Chrome 上点一遍。

一个最低限度的 Web 回归清单：

这几步看起来普通，但正好覆盖这次 Web 修复的三个入口。

最后

1.11.0-rc01 没有太多新 API，重点是把 1.11 线里的跨平台交互和渲染问题继续压住。

Compose Multiplatform 真正难的地方也在这里：同一套 UI 代码要落到 iOS、Desktop、Web，每个平台的输入、焦点、键盘、渲染栈都不一样。RC 阶段修这些问题，比新增几个表层 API 更影响上线质量。

#ComposeMultiplatform #Kotlin #JetpackCompose #KMP #跨平台开发