对话谢国：从 Flutter 到 KMP，跨平台框架正在从“代码复用工具”走向“生态连接器”

InfoQ：您从字节跳动 Flutter 团队负责人，到现在在华为主导鸿蒙上的 KMP 实践，这一路走来，您对“跨平台框架到底在解决什么问题”这件事的理解，有没有发生过比较大的变化？

谢国：在字节做 Flutter 的时候，我们当时的核心诉求很直接，就是尽可能消除双端差异——用一套代码同时覆盖 iOS 和 Android，实现降本增效，同时追求渲染一致性和性能表现。

过去更多是在成熟生态中做统一和优化，而面对鸿蒙这样的新生态，跨平台框架解决的已经不只是“多端复用”的问题，更承担着生态迁移和应用落地的重要角色。它更像是一种平滑迁移方案，让企业现有的移动端资产，尤其是业务逻辑代码，能够快速迁移过来，先解决可用性问题，再持续优化体验和性能。

因此，我的理解也从“技术层面的统一”逐渐转向“生态层面的连接”。尤其是 KMP，在很多场景下承担的正是帮助企业将 Android 侧的技术资产高效迁移到鸿蒙生态中的角色。

InfoQ：鸿蒙作为一个全新的操作系统生态，和当年在 iOS/Android 上做框架适配相比，您感受到最大的不同是什么？是技术层面的，还是更多是生态和协作层面的？

谢国：最大的不同其实是在生态和协作层面，技术反而只是表象。如果用一个词来概括，那就是“角色反转”。

当年做 iOS 和 Android 适配，本质上是在成熟生态中做优化。两个系统已经建立起完整的技术体系，我们作为框架开发者，更多是在既定规则下开展工作——Google 和 Apple 定义好了规则，我们需要做的是理解这些规则，并让框架能够顺利运行。社区有大量参考资料、成熟的 JNI 规范以及完善的 NDK 工具链，我们的主要工作是完成不同平台之间的适配与衔接。

但到了鸿蒙，情况有所不同。作为一个全新的操作系统生态，鸿蒙面对的是已经发展十余年的 Android 和 iOS 存量应用生态。借助跨平台框架，可以有效降低生态伙伴适配鸿蒙的成本和投入。鸿蒙的发展策略也比较务实：先解决兼容问题，再逐步构建差异化能力。

这种策略决定了我们在进行 KMP 适配时的很多思考方式，也带来了与以往不同的实践体验，主要体现在以下几个方面：

1. 协作层面的“合力破局”

以前做适配时，我们和手机厂商之间基本没有直接沟通，更多依赖开源代码和社区资料完成适配工作。但在鸿蒙生态里，我们更像是与华为以及广大 App 开发者共同推进生态建设的参与者。

当遇到鸿蒙底层的性能瓶颈时，我们会与合作伙伴一起分析问题、解决问题。因为 KMP 这样的方案能够帮助降低开发者迁移成本、丰富鸿蒙应用生态，各方在目标上具有较强的一致性。

这种“你中有我、我中有你”的协作密度，是在成熟生态里很难看到的。以前我们是“孤独的适配者”，现在我们是“生态共建者”。

2. 技术层面的“兼容优先”

鸿蒙从一开始就不是希望开发者“二选一”，而是实现“多栖共存”。例如，OpenHarmony 底层兼容 POSIX 接口，这与我们当年在 iOS 上推广 Flutter 时的环境并不相同。在成熟生态中，操作系统通常不会专门为某个跨平台框架调整底层能力；而在鸿蒙生态的发展过程中，系统层也在持续为跨平台框架提供更完善的支持。

回到技术本身，这种生态发展阶段的差异也直接体现在技术选型上。以前在 iOS 和 Android 生态中，我们更多是在既有规则下开展工作，需要让 Flutter 引擎适配系统运行机制，有时还需要处理一些平台能力上的限制，因此始终存在一定的不确定性，很难判断一次系统升级是否会带来新的兼容性问题。

调用鸿蒙 API 走的是官方支持的 FFI 路径。为了提升整体体验，系统层面也会持续优化相关链路，为跨平台方案提供更好的运行环境。

所以总结一下，最大的不同是，我们从“在存量市场里抢地盘”变成了“在增量市场里一起开荒”。鸿蒙需要我们的框架来降低开发者迁移成本，而跨平台技术也需要鸿蒙这样的新生态来拓展发展空间。这种相互促进的合作关系，是当年那场“三足鼎立”的技术竞争中从未有过的体验。

InfoQ：Flutter 在鸿蒙上的适配，您们在渲染和性能层面做了哪些比较有意思的探索？有没有哪个技术决策，让您觉得“这个思路是对的”？

谢国：在鸿蒙上做 Flutter 适配，其实是一次很难得的“后发优势”体验。因为鸿蒙是全新的系统，我们不用背负 Android 碎片化的历史包袱，可以在底层做很多激进的尝试。具体来说，有三件事让我们觉得特别有意思：

1.绕过 Skia，率先使能 Impeller

大家都知道，Flutter 官方在 iOS 上主推 Impeller，以解决“着色器编译卡顿”问题，但在 Android 上的推进相对缓慢，因为需要适配大量 GPU 驱动。

在鸿蒙上，我们做了一个较为激进的技术选择：直接绕过 Skia（Flutter 默认的渲染引擎），率先在鸿蒙平台完整使能 Impeller 后端，甚至早于 Flutter 官方在 Android 平台上的稳定支持。

Impeller 采用预编译着色器机制，不需要在运行时动态生成 GLSL 代码并等待驱动编译。在滑动、转场等典型场景下，光栅化耗时下降了约 30%，显著减少了因着色器编译导致的掉帧现象。

这个决策也让我更加确信一点：在硬件和系统条件允许的情况下，积极拥抱下一代技术架构，往往能够获得更大的优化空间。

2. 外接纹理“零拷贝”：视频/相机的渲染路径重构。

这是技术挑战较大的探索。在传统 Android 方案中，相机或视频播放器解码出一帧数据的路径为：GPU/Video Decoder -> 系统内存 -> CPU -> Flutter Engine -> GPU。数据在内存和显存之间来回拷贝，延迟高且 CPU 占用飙升。

我们在鸿蒙上利用了 HarmonyOS 的 HDI（硬件设备接口）层，实现了真正意义上的外接纹理零拷贝。具体做法为：不让 Flutter Engine 去“拿”数据，而是让鸿蒙的相机组件直接把数据渲染到一块共享的 GPU Buffer（图形处理器缓冲区）里，然后 Flutter 的渲染后端在合成时直接持有该 Buffer 的句柄，在最后的合成阶段（Composition）一次性提交给屏幕。

该机制可比喻为：以前是“我去仓库搬货”（多次拷贝），现在是“货运火车直接开进车间生产线”（Buffer 流转）。在视频通话场景下，视频画面可以与 Flutter UI 做到 60 帧的完美同步，无撕裂感。

InfoQ：KMP 在内存管理和 GC 这块，鸿蒙的环境带来了哪些新的挑战？目前的演进方向是什么？

谢国：这个问题非常核心，也是我们目前投入精力最多的领域。说实话，这是一场从“享受红利”到“重造轮子”的艰难旅程。

一、挑战：从“温室”到“荒漠”

在 Android 上做 KMP，内存管理基本无感，因为站在巨人的肩膀上——ART。ART 经过二十多年的工业级打磨，其 GC（垃圾回收）是一个集大成者：分代收集、并发标记、压缩整理、指针压缩……开发者只需 new 对象，ART 处理一切，极少出现长时间 STW（Stop The World，暂停所有线程）的情况。

二、演进方向：重构运行时基础设施

面对这些问题，我们没办法等待官方慢慢迭代，所以目前的重心是重构 KMP 在鸿蒙上 GC 依赖的三大基础设施：

方向 1：推进精确栈映射（Exact Stack Map）

在编译 Kotlin/Native 到字节码或机器码时，额外生成一份“栈映射表”。该表精确记录每个栈帧中哪些位置是引用、哪些是数值。GC 无需猜测，即可精确回收，同时支持移动式 GC。这是当前优先级最高的任务，没有精确栈扫描，后续所有优化均为空中楼阁。

方向 2：升级 CMS GC 为 并发拷贝 CMC 方案（Concurrent Mark-Copy）

在 KMP 的鸿蒙后端推进 CMC 算法的落地。这是一套完整的并发拷贝式 GC 解决方案，而非仅替换分配器。核心设计包括：

• 基于 Region 的 Bump Pointer 分配：将堆内存划分为多个 Region，每个线程认领一个 Region 作为私有分配区，分配时仅需移动指针，几乎无锁，效率极高。

• 并发标记：在应用线程运行的同时完成对象存活标记。

• 移动整理：将存活对象从零散分布的 From 区域复制到 To 区域，彻底消除内存碎片。

方向 3：实现指针压缩

这是相对独立的内存优化方向。正在鸿蒙的 KMP 上做指针压缩适配：将堆内存限制在 4GB 以内，所有句柄以 4 字节索引代替 8 字节指针。虽有限制，但在移动端场景下 4GB 通常够用，换得一半的内存占用。

该优化与 Moving GC 方案可并行推进，两者不冲突。目前在鸿蒙 KMP 内存管理上的工作，本质上是将 ART 过去二十年走过的路，以 Kotlin/Native 的方式在鸿蒙上重新走一遍。

InfoQ：您演讲里提到“跨语言调用优化”和“编译优化”，对普通开发者比较抽象。能不能用一个实际场景来说明，这些优化在用户体验上体现在哪里？

谢国：一、跨语言调用优化：让“跨国对话”变成“邻里串门”

优化前，Kotlin 与 ArkTS 之间的每一次数据传递，如同两个不同语言的外交官谈判——中间需要翻译官将数据序列化为通用格式（如 JSON 字符串），对方收到后再反序列化。该过程速度慢且 CPU 占用高。

采取三项措施改变局面：

1.对象免序列化共享方案（通过代理）

优化前：KMP 侧解析完一个 FeedItem 对象（包含文本、图片 URL、点赞数等 10 个字段）后，为传递给 ArkTS，需将该对象整体打包为 JSON 字符串。一个 Feed 流包含 20 条内容，需打包 20 次、解析 20 次。

优化后：我们实现了一套代理机制——KMP 侧对象不出境，而是向 ArkTS 侧返回一个“代理对象”。ArkTS 侧通过该代理直接访问 KMP 侧对象的字段，如同访问本地对象。数据无需打包和解包，仅传递一个轻量级“引用凭证”。

用户体验方面：首屏数据准备就绪至 UI 渲染完成的时间显著缩短。用户点击“点赞”按钮时，响应从“有点粘滞”变成了“像本地一样干脆”。

2. 字符串免拷贝共享方案

字符串是信息流中最频繁传递的数据类型（用户名、正文、标题）。优化前，每传递一个字符串，KMP 侧需将 UTF-8 字符串转换为 ArkTS 可识别的 UTF-16 字符串，涉及一次完整的内存拷贝。

优化后：KMP 侧与 ArkTS 侧直接共享同一块内存，字符串仅存储一份，双方通过偏移量和长度读取。一个包含 20 条内容的 Feed 流，字符串总长度可达数千字符，避免了每次刷新时拷贝数十至数百 KB 内存。

用户体验方面：滑动 Feed 流时帧率更稳定。优化前，滑动过程中突然加载新内容时，字符串拷贝导致 CPU 瞬时飙高并掉帧；优化后滑动全程更为流畅。

3. FFI 代码生成工具

该优化对开发者不可见，但作为前两个优化的基础设施。手写 Kotlin 与 ArkTS 之间的 FFI 绑定代码极其繁琐、易错，且难以实现高性能。

我们实现了一套代码生成工具，其输入为 ArkTS 源码与 ArkTS 装饰器或源码注解。工具解析这些信息，自动生成 Kotlin 侧的 FFI 代理对象源码。

与常见跨语言绑定工具不同，该方案无需编写.def 文件，也不生成 KMP 侧的导出代码、ArkTS 侧的声明代码或 C/C++桥接代码。仅生成 Kotlin FFI 代理对象源码，使 Kotlin 侧能够像调用本地对象一样调用 ArkTS 侧的能力。

无该工具时，人工编写的绑定代码性能参差不齐，易遗漏优化点。自动生成保证每条路径均为优化后的最优路径，用户感知为“稳定流畅”。

二、编译优化：让“工地施工”变成“工厂流水线”

1. LLVM IR Split 编译并行化

Kotlin/Native 编译为鸿蒙的.so 文件时，底层依赖 LLVM。传统编译方式将整个模块的 IR（中间表示）作为一个巨大整体进行优化和编译，如同单个工人砌整面墙——效率低、耗时长。

优化方案：将 LLVM IR 拆分为多个独立的编译单元，使其并行编译。一个大型 KMP 模块的编译效率可提升 2-5 倍。

2. 模块化构建技术

我们将 KMP 代码按业务边界拆分为数十个独立模块（登录、Feed、详情页、评论等）。仅改动过的模块需要重新编译，未改动模块直接复用缓存。

编译速度直接影响 CI/CD 流水线，慢编译会导致版本迭代缓慢、bug 修复迟滞。并行化使团队能够更快响应反馈，更新包下发速度提升。

InfoQ：您在演讲提纲里提到“从框架易用性到框架对 AI 的友好度”，这个转变您是怎么观察到的？在您的实践里，AI 对框架的使用方式带来了哪些具体的变化？

谢国：这一转变确实在发生。随着 AI 编码工具（如 GitHub Copilot、Cursor）的普及，开发者选框架时开始关注一个问题：AI 能否高效生成相关代码？

AI 翻译代码将降低跨平台框架的吸引力，因为它使“维护两套原生代码”的成本下降。这对框架设计者提出新要求：框架必须对 AI 友好。

AI 带来的具体变化有三点：

•  从“写代码”到“描述意图”：此前开发者关心 API 是否顺手；现在关心用自然语言描述一个功能后，AI 能否准确生成对应的框架代码。这要求框架的设计模式更标准化、可预测，而非充满“魔法”。

• AI 降低跨语言学习门槛：KMP 要求 iOS 团队学习 Kotlin，此前是一个门槛。但 AI 辅助编码使 Swift 工程师上手 Kotlin 共享层的周期从数周缩短至数天。这反过来支撑了“原生跨平台”（如 KMP）路线的可行性。

• 框架价值发生迁移：AI 将使初级跨平台适配工作自动化，但复杂的平台深度集成（相机、蓝牙、支付）仍需人工介入。因此，框架价值正从“节省代码量”转向“提供稳定的抽象层”，使 AI 能在抽象层之上安全生成代码。

InfoQ：AI 辅助代码生成这件事，您在团队里是怎么用起来的？对 Flutter 或 KMP 这类框架的开发效率，您觉得 AI 目前带来的改变有多大？

谢国：我们在团队里有尝试把 AI 用在胶水代码生成和跨语言绑定上。比如 Kotlin 与 ArkTS 之间的 FFI 桥接、序列化逻辑、简单 UI 组件的转换——这些重复性高、模式固定的工作，AI 完成得很好。

至于改变有多大，我的判断**：AI 目前是“效率倍增器”，但不是“框架终结者”。

“AI 分分钟把 iOS 代码翻译成 Android”。但现实是：

• 翻译不等于可运行：AI 可以把UITableView换成RecyclerView，但复杂的手势冲突、自定义动画、与系统组件的交互，翻译结果大概率需要大量人工修正。

• 持续迭代才是真问题：一次性翻译可行，但业务持续迭代，每次改动都要走“翻译→验证→修正”的流程。对于核心 App，这条路还很陡峭。

只要平台差异存在，只要 iOS 和 Android 有各自的运行时模型和 UI 范式，就需要某种形式的“跨端解决方案”——无论是框架、工具链，还是 AI 辅助的多端同步流程。

AI 改变的是开发效率，而不是框架的存在逻辑。至少在可预见的几年内，跨平台框架不会被 AI“干掉”，而是会与 AI 共存，互相塑造。

InfoQ：Flutter、KMP、React Native 三个框架，在鸿蒙生态和 AI 这两个新变量叠加之下，您觉得各自的位置会有什么变化？如果团队今天来咨询您做选型，您会怎么帮他们思考？

谢国： 我们在鸿蒙上的实际体感，这三个框架在“鸿蒙+AI”的叠加态下，分化会越来越明显。

1. React Native：面临新的竞争压力，但仍拥有广泛存量生态，新项目不推荐。

RN 的衰退是结构性的，不是 Bug 能修复的。

• 旧架构性能瓶颈明显，新架构迁移太漫长。

• 前端写移动端”这个核心优势正在被削弱——AI 降低学 Kotlin/Dart 的门槛，前端工程师不再必须死守着 JS。

• 连 Meta 自己的 App 都在迁离 RN，信号意义很强。

我的建议：存量 RN 项目可以继续维护，但新项目不建议选 RN。除非团队已经被 RN 深度绑定且迁移成本极高。

2. Flutter：从“万金油”变成“场景化工具”。

• 优势依然存在：自绘渲染带来像素级一致性，Impeller 解决 Jank 问题，适合设计驱动、视觉一致性要求极高的产品（如创意工具、内部工具类 App）。

• 天花板也明显：与原生组件的摩擦（键盘、无障碍、输入法）、Web/桌面的尴尬、Dart 的生态规模相较 Kotlin、JavaScript 仍相对有限。

我的建议：如果你的产品需要双端像素级一模一样，且不依赖复杂的平台特有能力，Flutter 依然是高效选择。但对于新项目，建议认真评估 KMP 路线，尤其是鸿蒙生态。

3. KMP：最匹配鸿蒙生态长期方向的方案。

KMP 的核心哲学——共享逻辑，原生 UI——恰好踩中了鸿蒙生态的几个关键点：

• 鸿蒙需要兼容，也需要差异化：KMP 让企业可以把业务逻辑（网络、存储、状态管理）在 Android 和鸿蒙之间共享，节省大量成本；同时 UI 各端原生，能充分原生比如鸿蒙的 ArkUI 特性。

• Kotlin 的通用性：开发者学 Kotlin，不止能写移动端，还能写服务端。团队投入有复利，这和 Dart 形成鲜明对比。

• 与现有代码库的渐进迁移：对于已有 Android 代码库的团队，KMP 可以逐模块迁移到鸿蒙，风险小于 Flutter 的一次性重写。

最后补充一点：AI 编码工具正在降低跨语言学习成本。以前 iOS 团队抗拒 Kotlin 是个真实门槛，现在这个门槛在快速变低。这是支持“走原生跨平台路线”的额外理由。

InfoQ：您觉得五年后，跨平台框架这个方向和今天相比会有哪些本质性的不同？您现在在鸿蒙上做的这些事，您希望它在这个演进过程里扮演什么角色？

谢国： 五年后，我觉得“跨平台框架”这个概念可能会被拆解成两层，和今天很不一样。

第一层：共享逻辑层的极致成熟

KMP 代表的“共享业务逻辑”路线会成为中大型 App 的标配。网络、存储、状态管理、业务计算——这些与 UI 无关的代码，会稳定运行在跨平台共享层上。开发者不再纠结“逻辑要不要共享”，因为工具链和 AI 已经让这件事成本极低。

第二层：UI 层的“原生优先 + AI 辅助”

UI 层的跨平台需求不会消失，但解决方案会变化：

• 原生 UI 框架会越来越强（SwiftUI、Compose、ArkUI），覆盖绝大部分需求

• Flutter 这类自绘 UI 会退到特定场景（如游戏 UI、极度定制化的创意工具）

• RN 的抽象层级可能被 AI 翻译工具部分替代（即直接翻译为原生代码的路线）。

“只要平台差异存在，就需要某种形式的跨端解决方案——无论是框架、工具链，还是 AI 辅助的多端同步流程。” 五年后，这种“解决方案”可能不再是一个单一的框架，而是一套 “原生 UI + 共享逻辑层 + AI 辅助同步” 的混合工作流。

如果五年后回头看，我希望我们现在在鸿蒙上的这些探索——KMP 底层的内存管理重构、跨语言调用的零开销优化、与 ArkUI 的深度融合——能成为这套未来工作流的“地基”之一。

具体来说：

• 让“鸿蒙+Android”的逻辑共享成为一种常识：就像今天没人觉得“共用后端代码”奇怪一样，五年后开发者会默认“我的业务逻辑应该跑在 KMP 共享层上，UI 交给各平台原生”。我们在鸿蒙上解决 KMP 的内存、性能、生态问题，就是在加速这个常识的形成。

• 为 AI 的深度介入铺路：我们在做的 FFI 代码生成工具、跨语言调用的标准化模式，本质上是为 AI 提供可学习的“语义锚点”。五年后，AI 能自动完成 90%的跨语言绑定和适配工作，前提是今天这些底层交互是有规范、可预测的。我们希望能贡献这套规范。

• 验证“原生跨平台”路线的可行性：鸿蒙是一个全新的生态，没有历史包袱。如果能在鸿蒙上证明“KMP + 原生 UI”这条路跑得通——性能好、体验佳、效率高——那对其他平台（包括 iOS、Android、甚至未来的新系统）会有很强的示范效应。

我希望我们现在做的这些“脏活、累活”——修 GC、搞零拷贝、压编译时间——能让五年后的开发者根本不需要关心“跨平台”这三个字。他们只需要写 Kotlin 业务逻辑，各端用最喜欢的原生 UI 框架画界面，AI 和工具链在背后默默搞定一切。从这个意义上看，当前在鸿蒙生态中的探索，不仅是在解决当下的兼容与性能问题，也是在为未来“原生 UI + 共享逻辑 + AI 协同开发”的新范式积累基础能力。

嘉宾介绍：

谢国，华为鸿蒙突击队 编程框架首席技术专家。拥有 10+年移动应用开发经验，主导多个互联网开源框架，曾任字节跳动 Flutter 团队负责人。

会议推荐