2024 年有一个被反复讨论的话题：跨端框架已经"卷"出结果了吗？现在是 2026 年，答案依然是：没有。
不是因为这些框架还不够成熟，而是因为它们在各自的战场上都活得很好------Flutter 继续统治 UI 表现力，React Native 凭借 New Architecture 重回舞台，Kotlin Multiplatform 悄悄占据了"不想重写 UI 但又想共享逻辑"的细分市场，小程序在国内流量闭环里自成生态。而就在这些老玩家之外，腾讯开源的 Kuikly 正在悄悄进入更多人的视野------尤其是那些需要覆盖鸿蒙、同时又不想抛弃 Kotlin 技术栈的团队。
这篇文章的目的不是"评选冠军"，而是把 2026 年的技术现状摆出来，帮你做一个真实的技术选型判断。我会尽量给出明确的观点，而不是"都挺好都有适用场景"的废话结论。这篇文章篇幅较长，建议按目录跳转到你最关注的部分。
选型前的一个元问题
在进入各框架对比之前，有一个问题必须先回答：你想跨的"端"是什么？
这个问题听起来很基础，但实际选型中被忽视的频率高得惊人。"跨端"至少有五种完全不同的含义：
• Android + iOS（移动双端）
• 移动 + Web（三端）
• 移动 + Desktop（桌面端，包括 macOS/Windows/Linux）
• 移动 + 鸿蒙（这在国内是一个越来越无法回避的维度）
• 微信/支付宝/抖音等超级 App 内的小程序生态
不同的跨端目标，对应的最优解差异极大。鸿蒙这一项是 2024 年之前很多横评文章不认真对待的维度，但 2026 年来看，这已经是任何国内 ToC App 绕不开的话题。Kuikly 进入讨论，很大程度上就是因为这个背景。
Flutter：性能天花板，但生态成本是真实的
Flutter 的核心优势从诞生之初就没变过：自绘引擎 + Dart，完全绕开平台 UI 组件，在任何平台上渲染出一致的像素级效果。2026 年这个优势依然成立，在动效复杂、UI 高度定制的场景里，Flutter 仍然是我的第一推荐。
但有几个问题需要直说：
包体积问题从未真正解决。一个最简单的 Flutter App，Release 包在 Android 上依然接近 10MB 起步。对于独立 App 这不是大问题，但如果你是想把 Flutter 嵌入已有的 Native App（即 Add-to-App 模式），包体积带来的 APK 膨胀和 so 加载开销是真实的工程成本。
Platform Channel 的摩擦依然存在。自绘引擎的代价是与原生生态的隔离。每当你需要调用一个平台特有能力（相机、蓝牙、地图 SDK、推送 SDK），都需要通过 Platform Channel 或 Method Channel 搭桥，而这些三方插件的质量参差不齐------尤其是企业级 SDK（腾讯云、阿里系、各类支付 SDK），Flutter 适配往往比 React Native 慢半个身位。
Dart 的"独占性"是把双刃剑。前端工程师学 Dart 有一定成本，Android 工程师也不一定愿意切换。这在团队层面是真实的摩擦。
鸿蒙支持是薄弱项。Flutter 官方团队对鸿蒙的支持进展缓慢，目前社区层面有一些 fork 尝试，但完整度和稳定性远不如 Android/iOS 端。如果你的 App 需要覆盖鸿蒙，Flutter 当前不是好选择。
一个真实可用的 Flutter 跨平台组件示例，展示如何用 Platform Channels 调用原生能力：
// Flutter 侧：通过 MethodChannel 调用原生能力
import 'package:flutter/services.dart';
class NativeBridge {
static const MethodChannel _channel = MethodChannel('com.example/native');
// 调用原生获取设备信息
static Future> getDeviceInfo() async {
try {
final result = await _channel.invokeMethod('getDeviceInfo');
return Map.from(result);
} on PlatformException catch (e) {
debugPrint('Native call failed: ${e.message}');
return {};
}
}
}
// Android 侧（Kotlin）：注册 MethodChannel 处理器
class MainActivity : FlutterActivity() {
override fun configureFlutterEngine(flutterEngine: FlutterEngine) {
super.configureFlutterEngine(flutterEngine)
MethodChannel(
flutterEngine.dartExecutor.binaryMessenger,
"com.example/native"
).setMethodCallHandler { call, result ->
when (call.method) {
"getDeviceInfo" -> result.success(mapOf(
"model" to Build.MODEL,
"sdk" to Build.VERSION.SDK_INT,
"manufacturer" to Build.MANUFACTURER
))
else -> result.notImplemented()
}
}
}
}我的判断：Flutter 最适合新项目、UI 高度定制、团队可以接受 Dart 学习成本的场景。如果是存量 Native 项目局部接入，或者需要覆盖鸿蒙，或者对接企业级 SDK 较多，成本会显著高于预期。
React Native：New Architecture 是真正的转折点
React Native 在 2022-2023 年间一度被唱衰，性能问题、Bridge 瓶颈、社区碎片化......这些批评都有道理。但 New Architecture（Fabric + JSI + TurboModules）的全面落地，让 React Native 在 2025 年之后重新变得有竞争力。
New Architecture 最核心的变化是干掉了异步 Bridge。旧架构里，JS 和原生之间的所有通信都是异步序列化消息，这是性能问题的根源。JSI（JavaScript Interface）直接让 JS 持有原生对象的 C++ 引用，调用变成同步操作，手感完全不同。
// New Architecture：用 Turbo Module 实现类型安全的原生模块
// JS 规范文件（NativeDeviceInfo.ts）
import type { TurboModule } from 'react-native';
import { TurboModuleRegistry } from 'react-native';
export interface Spec extends TurboModule {
getDeviceModel(): string;
getBatteryLevel(): Promise;
// Codegen 会根据这个接口自动生成 Android/iOS 原生代码框架
}
export default TurboModuleRegistry.getEnforcing('NativeDeviceInfo');
// 使用时直接同步调用，无需等待 Bridge
import NativeDeviceInfo from './NativeDeviceInfo';
const model = NativeDeviceInfo.getDeviceModel(); // 同步，不阻塞 UI 线程
NativeDeviceInfo.getBatteryLevel().then(level => console.log(level));React Native 的核心优势在于：前端工程师零门槛入场，组件生态极其丰富，与 Web 技术栈共享人才。对于有前端团队的公司，这是最低摩擦的跨端路径。
但要说清楚的是：React Native 的 UI 是用平台原生组件渲染的，不是自绘。这意味着在不同平台上，相同代码可能渲染出略有差异的 UI------这既是它"更接近原生体验"的优势，也是像素级一致性的短板。
鸿蒙方面，React Native 社区有 react-native-harmony 项目在推进，但官方态度暧昧，完整度和维护持续性存疑。
我的判断：前端团队主导、需要快速迭代、对 UI 一致性要求不是极致严苛的业务场景，React Native New Architecture 是性价比最高的方案。但如果业务需要覆盖鸿蒙，需要保持关注并做好备份预案。
Kotlin Multiplatform：逻辑共享而非 UI 统一，这个定位值钱
KMP（Kotlin Multiplatform）一直被误解。很多人把它和 Flutter / React Native 放在同一个坐标系里比较，这是错的。KMP 从设计之初就不是要统一 UI，而是让业务逻辑、数据层、网络层在 Android / iOS / Desktop / Web 之间共享，UI 仍然交给各平台原生或 Compose 处理。
这个定位对存量项目来说非常珍贵。你不需要重写整个 App，只需要把共享逻辑提取到 KMP 模块：
// commonMain - 这段代码同时编译为 Android .aar 和 iOS .xcframework
// build.gradle.kts（KMP 模块配置）
kotlin {
androidTarget()
iosX64(); iosArm64(); iosSimulatorArm64()
sourceSets {
commonMain.dependencies {
implementation("io.ktor:ktor-client-core:3.0.0")
implementation("org.jetbrains.kotlinx:kotlinx-serialization-json:1.7.0")
implementation("app.cash.sqldelight:runtime:2.3.2") // SQLDelight 2.3.2
}
androidMain.dependencies {
implementation("io.ktor:ktor-client-okhttp:3.0.0")
implementation("app.cash.sqldelight:android-driver:2.3.2")
}
iosMain.dependencies {
implementation("io.ktor:ktor-client-darwin:3.0.0")
implementation("app.cash.sqldelight:native-driver:2.3.2")
}
}
}
// 共享的数据层逻辑
class ArticleRepository(private val db: AppDatabase, private val api: ArticleApi) {
suspend fun getArticles(forceRefresh: Boolean = false): List {
if (!forceRefresh) {
val cached = db.articleQueries.selectAll().executeAsList()
if (cached.isNotEmpty()) return cached.map { it.toDomain() }
}
val remote = api.fetchArticles()
db.articleQueries.transaction {
remote.forEach { db.articleQueries.insert(it.toEntity()) }
}
return remote
}
}2026 年 KMP 生态有几个值得关注的进展：
• SQLDelight 2.3.2 已经相当稳定，跨平台数据库方案不再是实验性质，Android/iOS/Desktop 共享数据层在生产环境是可行的
• Coil 3.4.0 完全拥抱 KMP，主流图片加载库的支持意味着 KMP 在 Android 生态中的"一等公民"地位越来越实
• Compose Multiplatform v1.11.10-alpha01（2026-04-14 刚发布）表明 JetBrains 在推进 UI 统一层面没有停步，lifecycle 2.11 和 navigation3 的多平台支持让 CMP 越来越接近可用状态
但 Compose Multiplatform 的成熟度需要区分对待：在 iOS 上，CMP 渲染仍然依赖 Skia/Skiko 绘制，和 Flutter 类似，存在与 iOS 原生组件的视觉差异问题。目前在 iOS 端的稳定性和第三方 SDK 接入体验，还不如直接用 SwiftUI。
我的判断：KMP 是"渐进式跨端"的最优路径，对 Android 工程师友好，不需要放弃现有 Native 代码。如果你的团队以 Android 开发为主，又需要向 iOS 扩张，KMP 共享逻辑层 + iOS Native UI 是目前风险最低的组合。
Kuikly：腾讯内部打出来的方案，鸿蒙时代的黑马
Kuikly 是腾讯大前端 Oteam（公司级）推出的跨端框架，底层同样基于 Kotlin Multiplatform，但它和"纯 KMP"走了一条不同的路：KMP 的定位是逻辑跨端，Kuikly 的定位是 UI + 逻辑全面跨端，同时把鸿蒙当一等公民来支持。
这不是一个新框架在实验室里跑出来的东西。官方数据：腾讯内部已有 20+ 业务深度使用，页面数 1000+，日活用户超 5 亿。QQ、搜狗输入法、鹅毛市集等产品都在用。这个数字放在这里，很多关于"不成熟"的担忧就可以降级处理了。
架构设计：两层分离
Kuikly 的整体架构分为两大块：
• KuiklyUI ：跨端 UI 层。Core 模块提供组件/动画/手势/布局等高级能力，Render 模块负责各平台渲染------关键区别在于，Kuikly 复用平台原生 UI 组件渲染，而不是自绘（这一点和 Flutter 根本不同，和 React Native 的原生渲染路径更接近，但不依赖 JS Bridge）。
• KuiklyBase：跨端逻辑基建层。侧重高性能逻辑跨端，兼容标准 KMP 生态，提供完整的多线程协程能力，并扩展了鸿蒙端支持。
DSL 方面，Kuikly 同时支持自研 DSL （已稳定）和标准 Compose DSL（Beta 版，腾讯内部已有业务落地），后续会以 Compose DSL 为主方向。这对于已经熟悉 Compose 的 Android 工程师来说是一个重要信号------未来学习成本会进一步降低。
// Kuikly 自研 DSL 示例（跨 Android/iOS/鸿蒙）
// 一套代码，原生组件渲染
komposeView {
column(modifier = Modifier.fillSize().background(Color.White)) {
text(
text = "Hello Kuikly",
modifier = Modifier.margin(top = 20f),
fontSize = 24f,
color = Color.Black,
fontWeight = FontWeight.Bold
)
image(
src = "https://example.com/banner.png",
modifier = Modifier.fillWidth().height(200f).margin(top = 16f)
)
button(
text = "点击跳转",
modifier = Modifier.fillWidth().margin(top = 20f),
onClick = {
// 跨端路由，各平台执行对应原生导航
KuiklyRouter.push("detail_page", params = mapOf("id" to "123"))
}
)
}
}
// Compose DSL（Beta）：对已有 Compose 经验的开发者更友好
@Composable
fun ProductCard(product: Product) {
Column(
modifier = Modifier.fillMaxWidth().padding(16.dp)
) {
Text(text = product.name, fontSize = 18.sp, fontWeight = FontWeight.Bold)
Text(text = "¥${product.price}", color = Color(0xFF07C160), fontSize = 16.sp)
KuiklyButton(
text = "立即购买",
onClick = { KuiklyRouter.push("order", mapOf("productId" to product.id)) }
)
}
}一码五端的真实情况
Kuikly 目前已开源的平台支持：Android、iOS、鸿蒙（OpenHarmony），Web（H5 + 微信小程序）为 Beta。五端里有几个值得拆开说：
鸿蒙支持是真正的差异化优势。Kuikly 在鸿蒙上做了深度优化------Kotlin/Native 直接编译为鸿蒙原生代码，减少桥接开销，渲染帧率和启动速度接近原生。这对于要在 2025-2026 年内完成鸿蒙适配的国内 App 来说，是实打实的工程价值。
Web（H5）方案与众不同 。Kuikly Web 不走其他跨端框架那种"自绘引擎 → WASM → 浏览器"的路，而是直接使用 DOM 渲染，产物只有 463KB，FCP（首屏绘制）在 MacBook M4 Pro Chrome 上测出来是 87ms，不到 Flutter Web / CMP Web 方案的一半。这是实测数据，不是宣传语。
微信小程序支持还在完善中。目前已接入腾讯多款业务（搜狗输入法、QQ小游戏等），但官方也坦承性能有优化空间，后续计划探索 WASM 预编译提升体验。这是如实说明，不是遮掩。
动态化：这个能力被低估了
Kuikly 支持页面级动态化，也就是说，页面逻辑可以通过下发更新，不需要发版。这对国内 App 来说是一个高频需求------运营活动、A/B 测试、紧急修复都需要它。Flutter 本身不支持动态化（有 Code Push 类方案但有限制），React Native 有 Code Push 但 Google Play 政策对此有约束，Kuikly 把动态化做进框架核心层，这是真实的架构优势。
包体积和性能
官方说"轻量化 SDK 体积"，实际上 Kuikly 复用原生组件渲染，不需要携带自己的渲染引擎，这和 Flutter 包体积从 10MB 起步形成了直接对比。在 Add-to-App 场景（已有 Native App 局部引入跨端页面）里，这个差距更明显。
我的判断：Kuikly 是 2026 年国内 Android 团队做跨端选型时最值得认真研究的新选项，尤其是满足以下任一条件的场景：（1）需要覆盖鸿蒙；（2）团队是 Kotlin/Android 背景，不想引入 Dart 或 JS；（3）动态化是业务硬需求；（4）有存量 Native App，需要渐进式接入跨端方案。它的短板是开源社区生态还在建设中，国际化场景基本不覆盖，非腾讯业务的踩坑经验相对少。
小程序：不是技术选型，是流量选型
把小程序放进跨端框架横评，其实有点奇怪------小程序不是你"选不选"的技术问题，而是"你的业务需不需要接入微信/支付宝/抖音这些超级 App 的流量生态"的商业问题。
Taro / uni-app 这类"小程序跨端框架的跨端框架"，让一套代码同时跑在微信/支付宝/抖音/H5，是工程效率的合理选择。但要清楚它的天花板：小程序的 WXML/WXSS 是静态化的，受限于宿主 App 的渲染能力，动效和交互复杂度有硬限制。
// Taro 3.x：用 React 写法，编译到微信/支付宝/抖音小程序
import { View, Text, Button } from '@tarojs/components'
import Taro from '@tarojs/taro'
export default function ProductCard({ product }) {
const handleBuy = () => {
Taro.navigateTo({ url: `/pages/order/index?id=${product.id}` })
}
return (
{product.name}
¥{product.price}
立即购买
)
}
// npx taro build --type weapp → 微信小程序
// npx taro build --type alipay → 支付宝小程序
// npx taro build --type tt → 抖音小程序
// npx taro build --type h5 → Web H5我的判断：小程序是流量分发的基础设施，不是技术架构的核心选择。对于 ToC 业务，它是必做的，不是可选的。但你的 App 核心体验不应该押注在小程序上------宿主 App 的运行时限制太多，长期来看要有独立 App 的备份。
读者常见争论点：直接给判断
每次跨端框架的文章下面，评论区都会出现几个高频争论。与其回避，不如直接给出我的判断：
争论一：Flutter 的动画效果就是比原生好，这点不接受反驳
部分成立，但被高估了。Flutter 自绘引擎在 60fps 复杂动效上确实有优势，因为它完全不依赖平台 UI 线程，不会被系统调度影响。但 2026 年 Android 和 iOS 的原生动画能力已经非常强------SwiftUI 的 withAnimation / Compose 的 Transition，配合硬件加速，绝大多数业务场景感知不到差距。Flutter 动画优势真正体现的场景是：粒子特效、极复杂的路径动画、游戏级别的 UI。这占多少 App 的比例？你自己判断。
争论二：React Native 性能就是不行，永远比不过原生
New Architecture 之前说这话是对的，之后这句话就过时了。JSI 之后 JS ↔ 原生的调用已经是同步 C++ 调用，Fabric 渲染器直接操作原生 shadow 树，性能瓶颈从"桥接"转移到了"JS 执行引擎本身"。在 Hermes 引擎下，普通列表滚动、页面切换、表单交互这些高频操作，React Native 和原生的差距已经非常小，肉眼难以区分。高负载场景（大量图片懒加载、复杂动效同屏）仍然有差距，但这不是 99% 业务的瓶颈。
争论三：Kuikly 不就是腾讯自用的轮子，出了腾讯没人维护
这是一个合理的担忧，但 2026 年的数据给了部分回答：GitHub 仓库 Tencent-TDS/KuiklyUI 已经开源，官方文档体系完整，Bugly + Shiply 配套工具链都有支持，公开 Roadmap 说明了 Q3 社区组件平台计划，Electron 支持在路上。腾讯内部 5 亿日活的业务压力证明了稳定性，但社区生态的深度确实还不能和 Flutter/RN 比。这里的风险不是"没人维护"，而是"你踩到的坑，社区上可能查不到答案"。对于有能力 fork 修改、有腾讯系 SDK 接入需求的团队，这个风险是可接受的。
争论四：KMP 只能共享逻辑，UI 还得写两遍，不算真正的跨端
这个批评本身是事实，但结论不一定成立。"写两遍 UI"的代价取决于你的 UI 有多复杂。对于很多业务型 App，80% 的代码是数据层、网络层、业务逻辑，UI 只是 20%。KMP 共享了那 80%，同时让你的 iOS UI 用 SwiftUI 写得 100% 原生，Android UI 用 Compose 写得 100% 原生------这是在不牺牲平台体验的前提下做到的最大程度复用，不是妥协，是取舍。如果你的 App 是设计驱动型（UI 是核心差异化能力），那确实应该考虑能统一 UI 的方案（Flutter 或 Compose Multiplatform）。
争论五：Kuikly 和 KMP 有什么区别，底层都是 KMP
这个问题很好。KMP 是技术基础设施，Kuikly 是基于 KMP 构建的完整产品框架。类比：Kotlin Coroutines 是技术，Ktor 是基于它的网络框架。KMP 给了你跨端逻辑共享的能力，但不告诉你怎么写 UI、怎么做动态化、怎么接鸿蒙、工具链怎么配。Kuikly 解决的是这些工程化问题。选 KMP 意味着你要自己组装技术栈（KMP + Compose Multiplatform / KMP + SwiftUI）；选 Kuikly 意味着你接受腾讯的整体技术路线，换来的是开箱即用的鸿蒙支持、动态化、完整工具链。
争论六：跨端框架最大的问题是升级维护，主框架一升级，插件全坏
这是真实的工程痛点，不同框架的严重程度不同。Flutter 的 Breaking Change 历史比较重（Dart SDK 升级、Gradle 版本绑定、Platform Channel API 变更），大型项目的升级成本是真实存在的。React Native 在 New Architecture 迁移期间插件兼容性问题一度很严重，现在基本稳定了，但仍然要预留升级窗口。KMP 因为复用原生生态，Kotlin 版本兼容性相对好处理，但 Gradle KMP 插件的 API 变更也经历了几次大调整。Kuikly 作为较新的框架，早期版本 API 变更频率可能更高，需要关注官方 Changelog。没有完美答案，只有"选一个你的团队有能力跟进"的方案。
争论七：RN 已经不行了，只要热更新需求在，RN 就永远有价值
这是评论区里一个很有代表性的观点，我部分同意。热更新（OTA 更新）确实是 React Native 的核心护城河之一，在海外市场尤其明显------Google Play 和 App Store 对插件化/动态加载有严格限制，而 RN 的 JS bundle 下发在政策层面相对友好。只要业务对"修复线上 bug 不发版"有强需求，RN 的这个优势就不会消失。
但也要补充一句：有读者提到 Remote Compose（服务端驱动 UI），说它可以替代 RN 的热更新。我的判断是：Remote Compose 更接近 SSR（Server-Side Rendering），它对服务器的实时依赖比 RN bundle 下发还高，离线场景基本无解，且延迟敏感性更强。两者的适用场景不同，不是替代关系。Kuikly 的页面级动态化走的是另一条路------预下发逻辑包，本地执行，兼顾了离线可用和动态化，这可能是这三种方案里最均衡的工程解。
争论八：KMP 凭什么比 C++ 跨端更好？LLVM 支持的语言都能跨端
这个问题很尖锐，也是 KMP 被质疑最多的技术点之一。观点本身是对的：理论上 C++ 写一份共享库，Android 直接 JNI 调用，iOS 也可以直接 link，性能上甚至比 KMP 更好（KMP Kotlin/Native 编译的产物比 C++ 慢，某些场景比 OC 也慢）。
那 KMP 的价值在哪？工程化成本和开发者门槛。C++ 跨端方案对开发团队的要求极高：你需要会写高质量 C++，需要处理内存管理、平台 ABI 差异、NDK/JNI 调试、C++ 标准库版本兼容......这在 2026 年是大多数 App 团队支撑不起的成本。KMP 用 Kotlin 写业务逻辑，编译工具链帮你处理平台差异，开发体验接近写 Android 代码。这不是"技术更先进"，而是"工程复杂度可控"。
所以结论是：如果你的团队有 C++ 能力，且性能是第一优先级（游戏引擎、音视频处理、复杂算法库），C++ 跨端仍然是更好的选择**。如果你是普通 App 的业务逻辑层**，KMP 的工程性价比更高。Kuikly 在这个基础上再加了 UI 层，进一步降低了门槛。
争论九：AI 写 UI 代码已经很好了，跨端框架重要性在降低
这是 2025-2026 年新出现的争论维度，值得认真对待。AI 辅助写 UI 确实大幅降低了"写两遍 UI"的人力成本------Cursor、GitHub Copilot、各家 IDE AI 插件在给定设计稿后生成 Compose/SwiftUI 代码的质量已经相当高，某些场景效率提升是 10x 级别的。
但有一个反驳要说清楚：写 UI 代码只是跨端成本的一部分，而且不是最大的那部分。真正让人头疼的是：两套 UI 的行为一致性测试、两套 UI 的 bug 修复、两套 UI 响应产品变更......这些都是 AI 写一遍代码搞不定的。更关键的是，AI 生成的 UI 代码通常还是需要人工 Review 和调整，在"高还原度"要求下（比对设计稿像素级调整），AI 写逻辑比 AI 写 UI 更靠谱。所以 AI 降低了跨端的 UI 开发成本，但没有消除跨端框架的价值------维护成本、一致性成本、测试成本依然存在。
Compose Hot Reload：跨端开发体验的新变量
Android Weekly #722 重点介绍了 Compose Hot Reload，这个特性值得单独说一下。
Hot Reload 对于跨端开发的意义在于：UI 迭代的反馈循环从"改代码 → 编译 → 安装 → 找到对应页面"（30 秒起步）缩短到"改代码 → 即时更新"（秒级）。Flutter 靠 Dart VM 一直有这个能力，而 Compose Hot Reload 让 Kotlin 原生开发也追上来了。
更重要的是，这个能力在 Compose Multiplatform 上同样可用------意味着你在 Desktop 上用 Hot Reload 快速打磨 UI，同一份代码最终部署到 Android/iOS/Desktop 多端。Kuikly 支持 Compose DSL 之后，这个能力也会逐步受益。
当前限制：类结构变更（新增方法、修改类层次）不支持热重载，只有函数体内的逻辑修改和 Composable 内容变更可以即时生效。这和 Flutter 的 Hot Reload 限制基本一致。
五个框架的横向对比
| 维度 | Flutter | React Native | KMP | Kuikly | 小程序(Taro) |
|---|---|---|---|---|---|
| UI 一致性 | 极高（自绘） | 中（原生组件） | 各平台原生 | 高（原生组件渲染） | 受宿主限制 |
| 性能天花板 | 高（动效突出） | 中高（New Arch） | 原生级别 | 原生级别 | 中 |
| 技术栈 | Dart | JS/TS + React | Kotlin | Kotlin | JS/TS |
| 存量项目接入 | 成本高 | 中等 | 低（逻辑层） | 低（页面级接入） | 新建为主 |
| 鸿蒙支持 | 弱（社区 fork） | 弱（社区维护） | 无官方 UI 支持 | 原生级，深度支持 | 无 |
| 动态化 | 弱（Code Push 有限） | 有（Code Push） | 无 | 内置，页面级 | 天然动态（宿主更新） |
| 三方 SDK 生态 | 中（靠 Channel） | 高 | 高（复用原生） | 高（复用原生） | 受宿主限制 |
| H5 包体积 | 大（WASM 自绘） | 中 | --- | 小（463KB，DOM渲染） | 小 |
| 社区生态 | 极强（全球） | 极强（全球） | 强（JetBrains） | 成长中（国内为主） | 强（国内） |
| 最适合 | 新项目/高 UI 要求 | 前端团队主导 | Android 团队渐进扩 iOS | 鸿蒙必须/动态化强需求 | ToC 流量分发 |
2026 年真实的技术选型流程
不给具体判断的技术文章都是在耍流氓。这里给一个我实际会用的决策路径：
决策树（从上往下，命中即停）
第一问：需要覆盖鸿蒙吗？
是，且团队是 Kotlin/Android 背景 → Kuikly，鸿蒙支持是目前最成熟的跨端方案
是，但团队是前端背景 → 暂时用独立 Native 方案做鸿蒙，正面等 React Native Harmony 社区成熟
第二问：动态化（不发版更新页面逻辑）是硬需求吗？
是 → Kuikly（内置页面级动态化）或 React Native + Code Push
第三问：你的主力团队是什么背景？
前端/Web 团队 → React Native（New Architecture），顺带覆盖 Web
Android 原生团队，需渐进式扩展 iOS → KMP 共享逻辑 + iOS SwiftUI；若需要 UI 统一考虑 CMP
全新项目 + UI 高度定制 + 无鸿蒙需求 → Flutter，Dart 学习曲线接受的话这是体验天花板
附加问：ToC 业务需要流量入口吗？
是 → 小程序必做（Taro 跨多小程序平台），但不要让它成为核心载体
特殊情况：需要 Mobile + Desktop（macOS/Windows）→ Flutter 或 CMP，两者是目前最成熟的选择；Kuikly 的 Electron 支持在 2026 下半年路线图内
一个容易被忽视的趋势：AI 集成正在改变跨端框架的竞争格局
KotlinConf'26 的演讲阵容里，AI 与 Multiplatform 的交汇是一个明显的信号。Kotlin Blog 3 月月报里也专门提到了 AI 集成方向的进展。Kuikly 官方文档甚至专门开了一个 AI 编程入口（/AI/），可见端侧 AI 已经成为跨端框架的标配诉求。
这背后有一个逻辑：本地 LLM 推理（ONNX Runtime、Core ML、TensorFlow Lite、MediaPipe）正在成为 App 的标配能力，而不同框架对这些能力的接入成本差异很大。
• Flutter 需要通过 Platform Channel 调用，每新增一个推理后端就要写一层桥接
• React Native 类似，但 JS 侧有更丰富的 AI SDK（ONNX.js、TensorFlow.js 等 Web 生态）
• KMP / Kuikly 可以直接复用原生 ML 框架，理论上接入成本最低，也是性能最可控的路径
如果你的 App 在接下来 1-2 年有集成端侧 AI 能力的计划，这一点值得在选型时权衡进去。Kotlin 系（KMP / Kuikly）在这个维度上有天然优势。
结语
2026 年的跨端框架格局，不是一个"谁赢了"的故事，而是一个"各就各位"的格局------并且队伍里多了一个国产玩家。Flutter 守住了 UI 表现力的领地，React Native 靠 New Architecture 打了一场漂亮的翻身仗，KMP 用渐进式策略拿下了最务实的工程师群体，Kuikly 凭鸿蒙支持和动态化在国内市场建立了自己的壁垒，小程序则在流量分发的赛道上自成一派。
选型不需要纠结"哪个更好"，需要回答的是"谁更适合我的团队、我的业务、我的时间窗口"。
下一步值得持续关注的方向：
• Kuikly 的社区生态建设进展------Q3 社区组件平台上线后生态丰富度会是关键变量
• Compose Multiplatform 在 iOS 端的稳定性演进------JetBrains 投入力度大，预计 2026 年底有显著改善
• 各框架对端侧 AI 推理能力的接入成本------这将是下一个选型维度
• 鸿蒙生态在国内市场的份额走势------这直接决定"覆盖鸿蒙"这道题的优先级权重
如果这篇对你有帮助，欢迎转发给正在做跨端选型的同事。