跨端开发方案全景

2026/8/25大约 6 分钟

🌉 跨端开发方案全景

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

一、为什么要跨端

flowchart LR
    A[业务需求] --> B{两端开发?}
    B -->|是| C[原生双端<br>成本 ×2]
    B -->|否| D[跨端方案<br>一套代码]
    D --> E[Flutter]
    D --> F[React Native]
    D --> G[Compose Multiplatform]

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

二、三大方案核心原理

2.1 Flutter:自绘引擎

flowchart LR
    A[Dart 代码] --> B[Widget 树]
    B --> C[Element 树]
    C --> D[RenderObject 树]
    D --> E[Skia/Impeller 自绘]
    E --> F[GPU 渲染到屏幕]

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

2.2 React Native:原生桥接

flowchart LR
    A[JS 代码] --> B[React 组件]
    B --> C[JS Bridge 序列化]
    C --> D[原生组件<br>UIView/View]
    D --> E[原生渲染]

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

2.3 Compose Multiplatform:Kotlin 共享

flowchart LR
    A[Kotlin 代码] --> B[Compose UI]
    B --> C[Skiko 自绘]
    C --> D[各平台渲染]
    A --> E[KMP 共享逻辑]
    E --> F[Android/iOS/Desktop/Web]

特点	说明
渲染	自绘: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:共享业务逻辑,各端只写 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 共享层	内容
网络层	Ktor Client / 序列化
数据层	SQLDelight / Room KMP
业务逻辑	ViewModel / UseCase
状态管理	StateFlow / Compose 状态

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

五、选型决策框架

flowchart TD
    A{团队技术栈?} -->|Android/Kotlin| B{需要共享 UI?}
    A -->|JS 为主| C[React Native]
    A -->|新团队无包袱| D[Flutter]
    B -->|是| E[Compose Multiplatform]
    B -->|仅共享逻辑| F[KMP 共享逻辑 + 原生 UI]
    D --> G[性能要求极高?]
    G -->|是| H[仍考虑原生]

决策因素	权重
团队技术栈	最高(学习成本)
性能要求	高(游戏/重渲染→原生)
生态依赖	高(原生 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：跨端方案如何调用原生能力?