跨端开发方案全景

2026/9/14大约 7 分钟

跨端开发方案全景

跨端开发的目标:一套业务逻辑、多端运行。Flutter、React Native、Compose Multiplatform 是当前三大主流方案,本文从渲染原理、性能、生态、选型多维度剖析。

一、为什么要跨端

跨端方案的整体取舍流程如下：

跨端带来的核心收益如下：

痛点	跨端收益
双端人力成本高	一套代码双端运行
双端逻辑不一致	共享业务逻辑
迭代节奏不同步	同步发版
维护成本翻倍	单代码库维护

二、三大方案核心原理

2.1 Flutter:自绘引擎

Flutter 自绘渲染的完整链路如下：

Flutter 方案的核心特点说明如下：

特点	说明
渲染	自绘:不依赖原生组件,直接 GPU 绘制
语言	Dart(单线程 + Isolate)
性能	高:渲染完全可控,接近原生
与原生通信	Platform Channel(异步消息)

2.2 React Native:原生桥接

React Native 原生桥接的整体流程如下：

React Native 方案的核心特点说明如下：

特点	说明
渲染	原生组件:JS 控制,原生渲染
语言	JavaScript/TypeScript
性能	中:JS-Bridge 通信有开销
生态	强:React 生态 + npm

2.3 Compose Multiplatform:Kotlin 共享

Compose Multiplatform 的自绘与共享链路如下：

Compose Multiplatform 方案的核心特点说明如下：

特点	说明
渲染	自绘:Skiko(Skia for Kotlin)
语言	Kotlin(与 Android 无缝)
性能	高:声明式 UI,接近原生
优势	Android 团队零学习成本,KMP 共享逻辑

三、方案对比

三大方案的全面对比说明如下：

维度	Flutter	React Native	Compose Multiplatform
渲染方式	自绘引擎	原生组件	自绘引擎
语言	Dart	JS/TS	Kotlin
性能	高	中	高
生态成熟度	高	高	中
热更新	支持(需配置)	支持	一般
原生交互	Platform Channel	Bridge/JSI	expect/actual
Android 团队上手	需学 Dart	需学 JS	零门槛
适用场景	重 UI 应用	已有 JS 团队	Android 团队跨端

四、KMP 逻辑共享(趋势)

KMP 共享逻辑的 expect/actual 实现如下：

Java

// KMP:共享业务逻辑,各端只写 UI 壳
// expect/actual 是 Kotlin 多平台专有能力,Java 中可用接口 + 平台实现表达

// 共享层:定义抽象(相当于 expect)
public interface PlatformNameProvider {
    String platformName();
}

// Android 实现(相当于 actual)
public class AndroidPlatformNameProvider implements PlatformNameProvider {
    @Override
    public String platformName() {
        return "Android";
    }
}

// iOS 实现(相当于 actual)
public class IosPlatformNameProvider implements PlatformNameProvider {
    @Override
    public String platformName() {
        return "iOS";
    }
}

Kotlin

// KMP:共享业务逻辑,各端只写 UI 壳
// commonMain 共享代码
// expect/actual 处理平台差异

// commonMain/Network.kt
expect fun platformName(): String

// androidMain/Network.kt
actual fun platformName(): String = "Android"

// iosMain/Network.kt
actual fun platformName(): String = "iOS"

KMP 可共享的各层内容如下：

KMP 共享层	内容
网络层	Ktor Client / 序列化
数据层	SQLDelight / Room KMP
业务逻辑	ViewModel / UseCase
状态管理	StateFlow / Compose 状态

趋势判断:Kotlin Multiplatform 是 JetBrains/Google 共同推动的方向,Android 团队可以"先用 KMP 共享逻辑,再上 Compose Multiplatform 共享 UI",渐进式跨端。

五、选型决策框架

跨端方案选型的完整决策流程如下：

各决策因素的权重说明如下：

决策因素	权重
团队技术栈	最高(学习成本)
性能要求	高(游戏/重渲染→原生)
生态依赖	高(原生 SDK 依赖)
交付节奏	中(跨端省人力)
长期维护	中(框架升级风险)

六、跨端常见问题

跨端开发的常见问题说明如下：

问题	说明
原生能力缺失	需写平台插件(Bridge/Channel)
性能瓶颈	复杂动画/列表需优化
版本碎片化	框架升级兼容性
调试复杂	双端环境 + 框架层
包体积增大	引擎体积(Flutter ~5MB+)
与原生混编	跨端嵌入原生模块

Flutter 自绘引擎:UI 直接由 Skia/Impeller 绘制到 GPU,不经过原生组件系统,渲染路径完全可控、每帧重绘可预期,所以性能接近原生(60/120fps 稳定)。RN 通过 JS Bridge 把组件映射到原生组件,通信有序列化开销,复杂场景易卡顿(新版 JSI 有改善)。本质区别:Flutter 是"自绘",RN 是"原生组件 + 桥接"。Flutter 渲染一致(双端 UI 完全一致),RN 更贴近原生体验但双端细节有差异。

Q2：Compose Multiplatform 和 Flutter 怎么选?

查看答案

团队因素优先:Android/Kotlin 团队选 Compose Multiplatform——语法与 Jetpack Compose 一致,零学习成本,KMP 可先共享逻辑;重 UI、跨端一致性要求高选 Flutter——生态成熟、性能稳定、社区大。技术因素:Flutter 单引擎跨平台(包括 Web/桌面)更成熟;CMP 目前 iOS 支持较好、桌面 Web 成熟度不一。实践:很多公司采用组合——KMP 共享业务逻辑,UI 各端原生或 Compose。

Q3：跨端方案如何调用原生能力?

查看答案

Flutter:Platform Channel——Dart 通过 MethodChannel 发消息,原生端(MainActivity/AppDelegate)注册 MethodCallHandler 处理,支持方法调用与事件流(EventChannel)。RN:原生模块导出方法给 JS 调用(JSI 时代性能提升)。CMP:expect/actual 声明平台 API,KMP 编译器生成各平台实现。注意:频繁跨端通信是性能瓶颈,批量传输、减少调用次数;复杂原生能力(相机、推送、地图)一般走三方插件或自研插件。

三大方案:Flutter(自绘)、RN(原生桥接)、CMP(Kotlin 自绘)
选型核心:团队技术栈 > 性能要求 > 生态
KMP 共享逻辑是趋势,渐进式跨端
原生能力通过 Channel/Bridge/expect-actual 调用
跨端不取代原生,按场景混合选型
质量保障:共享层测试 + 分层架构 + APM 监控

进阶阅读：Jetpack Compose 布局系统 | 架构设计演进 | Kotlin 协程原理

跨端开发方案全景

跨端开发方案全景

一、为什么要跨端

二、三大方案核心原理

2.1 Flutter:自绘引擎

2.2 React Native:原生桥接

2.3 Compose Multiplatform:Kotlin 共享

三、方案对比

四、KMP 逻辑共享(趋势)

五、选型决策框架

六、跨端常见问题

七、高频面试题

Q1：Flutter 为什么性能接近原生?和 RN 的区别?

Q2：Compose Multiplatform 和 Flutter 怎么选?

Q3：跨端方案如何调用原生能力?

Q4：跨端开发会取代原生吗?

Q5：跨端项目如何保证质量和性能?

小结