跨端技术对比 ☆
跨端选型不是站队,而是在业务目标、团队能力、体验要求和长期维护成本之间做取舍。 面试中要能把 Flutter、React Native、Compose Multiplatform、WebView Hybrid、小程序容器、KMP 和原生开发放在同一张决策表里比较。
一、跨端技术解决的核心问题
跨端技术的目标通常有三类:降低多端重复开发、提升发布效率、统一体验或业务逻辑。但不同方案共享的层次不同,不能简单说“一套代码跑所有端”。
| 方案 | 主要共享内容 | UI 渲染 | 典型诉求 |
|---|---|---|---|
| Flutter | UI + 业务逻辑 | 自绘 Skia/Impeller | 高一致性 UI、快速迭代、多端统一。 |
| React Native / RN | UI 描述 + JS 业务逻辑 | Native 组件桥接/Fabric | Web/前端团队复用经验,保留部分原生体验。 |
| Compose Multiplatform | Compose UI + Kotlin 逻辑 | Compose 渲染 | Kotlin 技术栈统一,桌面/移动共享 UI。 |
| WebView Hybrid | Web 页面 + Native 容器能力 | WebView | 运营活动、内容页、快速发布。 |
| 小程序容器 | 小程序 DSL/运行时 | 容器渲染 | 生态开放、插件式业务接入。 |
| KMP | 业务逻辑/数据层/算法 | 原生 UI 或 CMP | 共享核心逻辑,保留平台体验。 |
| 原生开发 | 少量公共协议/设计规范 | Android/iOS 原生 | 极致体验、复杂平台能力、稳定长期维护。 |
选型时先问:要共享的是 UI、业务逻辑、数据层,还是发布能力?答案不同,方案就不同。
二、Flutter:自绘 UI 与高一致性
Flutter 使用 Dart 编写,通过自绘渲染实现跨平台 UI 一致性。它的优势是开发体验完整、热重载、组件体系统一、动画和复杂 UI 表达强。
| 维度 | Flutter 表现 |
|---|---|
| UI 一致性 | 强,同一套 Widget 在多端表现接近。 |
| 性能 | 大多数业务足够好,复杂页面要关注首帧、shader、列表和图片。 |
| 原生能力 | 通过 Platform Channel 接入,复杂能力需要原生桥接。 |
| 包体积 | 通常比纯原生更大,要评估引擎和资源成本。 |
| 团队要求 | 需要 Dart/Flutter 经验和原生兜底能力。 |
Flutter 适合 UI 一致性强、需要快速多端交付、团队愿意接受新技术栈的业务。不适合只想在原生 App 中轻量嵌几页,或大量依赖复杂原生 SDK 且团队没有桥接能力的场景。
三、React Native / RN:前端生态与原生桥接
React Native 用 JavaScript/TypeScript 描述 UI 和业务逻辑,通过桥接或新架构 Fabric/TurboModules 与 Native 交互。它的优势是前端生态、动态性和招聘/团队迁移成本。
RN 简化链路:
JS/TS 业务逻辑
-> React 渲染描述
-> Fabric/TurboModules/Bridge
-> Android/iOS Native 组件与模块
RN 的核心取舍是桥接成本和运行时复杂度。高频 UI 更新、复杂手势动画、大量 Native 模块通信都要谨慎设计。新架构改善了旧 Bridge 的一些瓶颈,但并不意味着所有性能问题自动消失。
适合场景:已有 React/前端团队、业务 UI 中等复杂、需要一定动态发布能力、原生模块边界清晰。不适合极致动画、重度图形、复杂平台底层能力密集的模块。
四、Compose Multiplatform 与 KMP
KMP(Kotlin Multiplatform)关注共享业务逻辑,Compose Multiplatform(CMP)进一步尝试共享 UI。二者都适合 Kotlin 生态团队,但成熟度和平台覆盖要按项目评估。
| 技术 | 共享层次 | 优势 | 风险 |
|---|---|---|---|
| KMP | domain、data、network、算法、平台抽象 | 保留原生 UI,共享核心逻辑,适合 Android 团队扩展 iOS | iOS 互操作、构建、调试、异常模型需要治理。 |
| Compose Multiplatform | Compose UI + Kotlin 逻辑 | Kotlin/Compose 技术栈统一,适合内部工具/桌面/部分移动场景 | 移动端生态和复杂平台 UI 适配仍需评估。 |
KMP 的成熟回答是:它不是替代 Flutter/RN 的“统一 UI”方案,而是“共享核心逻辑 + 平台 UI 自治”。如果团队最痛的是重复写接口、模型、业务规则和算法,KMP 很合适;如果最痛的是两端 UI 开发成本,则要考虑 Flutter、RN 或 CMP。
五、WebView Hybrid 与小程序容器
WebView Hybrid 依赖 WebView 承载页面,Native 提供 JSBridge、离线包、权限、路由和监控。它发布快、成本低,适合活动页、运营页、内容页和低复杂交互。
小程序容器则是更完整的运行时:用统一 DSL、组件、权限模型和包管理承载第三方或内部轻应用。
| 维度 | WebView Hybrid | 小程序容器 |
|---|---|---|
| 发布效率 | 高 | 高,且更标准化。 |
| 体验 | 受 WebView 和前端性能影响 | 比普通 H5 更受控,但仍受容器能力限制。 |
| Native 能力 | JSBridge 按需开放 | 权限模型和 API 网关更体系化。 |
| 适合场景 | 活动、内容、表单、轻业务 | 平台生态、商家/插件接入、可治理轻应用。 |
| 风险 | 白屏、Bridge 安全、缓存错配 | 容器研发成本、标准制定和生态治理。 |
面试时要强调 Hybrid 和小程序容器都是“受控运行时”,核心不只是加载页面,还包括离线包、预加载、权限、监控、灰度、回滚和安全边界。
六、原生开发仍然不可替代的场景
原生开发成本高,但在很多场景仍是最稳的选择:
- 高性能图形、音视频、游戏、实时通信、复杂动画。
- 深度系统能力:相机、传感器、蓝牙、支付、安全、风控 SDK、NDK。
- 对启动、内存、包体积、稳定性有极致要求的核心链路。
- 平台差异很大,强行跨端会制造大量条件分支。
- 长期维护团队以 Android/iOS 为主,跨端技术栈缺少 owner。
原生不是“落后”,跨端也不是“银弹”。成熟团队常见组合是:核心链路原生,活动和内容 Hybrid,业务逻辑部分 KMP,独立新业务可尝试 Flutter/RN。
七、选型决策框架
选型可以用“业务、体验、团队、工程、风险”五维评估。
| 维度 | 关键问题 | 倾向方案 |
|---|---|---|
| 业务形态 | 内容/活动/表单还是复杂交易/实时交互? | 轻业务 Hybrid/小程序;核心交易原生/KMP。 |
| UI 一致性 | 是否要求多端像素级一致? | 强一致 Flutter;平台体验优先原生/KMP。 |
| 发布效率 | 是否需要高频动态发布? | Hybrid/小程序/RN;高风险逻辑仍需原生发版。 |
| 团队能力 | 团队熟悉前端、Kotlin 还是原生? | React 团队 RN;Kotlin 团队 KMP/CMP;原生团队原生。 |
| 原生能力 | 是否大量调用平台 SDK/NDK/安全能力? | 原生或 KMP 共享逻辑,跨端 UI 慎选。 |
| 长期成本 | 是否有容器、监控、桥接、灰度 owner? | 没有治理能力时不要贸然引入重跨端。 |
一个可用于面试的简洁结论:如果要统一 UI,看 Flutter/RN/CMP;如果要共享业务逻辑,看 KMP;如果要快速发布轻业务,看 Hybrid/小程序;如果要极致体验和复杂平台能力,坚持原生。
高频面试题
Q1:Flutter 和 RN 最大区别是什么? Flutter 更偏自绘 UI,用 Dart 和自己的 Widget/渲染体系保证多端一致性;RN 用 JS/TS 和 React 思想描述 UI,更多依赖 Native 组件和桥接。Flutter UI 一致性强,RN 更容易复用前端生态,二者都需要原生能力兜底。
Q2:KMP 和 Flutter 怎么选? KMP 适合共享业务逻辑、数据层、协议和算法,同时保留 Android/iOS 原生 UI;Flutter 适合统一 UI 和多端一致体验。如果团队最痛是重复写业务逻辑,选 KMP;如果最痛是多端 UI 重复开发,再评估 Flutter。
Q3:Hybrid 为什么适合活动页但不适合所有核心链路? Hybrid 发布快、成本低,适合内容、活动、表单和低复杂交互。但它受 WebView 性能、白屏、Bridge 安全、离线包一致性影响,对强性能、强安全、复杂原生能力的核心链路要谨慎。
Q4:Compose Multiplatform 的定位是什么? 它尝试用 Compose/Kotlin 共享 UI 和逻辑,对 Kotlin 团队有吸引力。当前选型要看目标平台、组件生态、调试体验和团队经验,不能简单等同于成熟 Flutter 替代品。
Q5:跨端选型最重要看什么? 先看共享目标是 UI、业务逻辑还是发布能力;再看体验要求、原生能力复杂度、团队技术栈、治理能力和长期维护成本。不要为了技术流行牺牲核心链路稳定性。
易错点 / 追问
- 不要说跨端一定省成本:桥接、容器、监控、兼容性和人才成本都要算进去。
- 不要把 KMP 说成“一套 UI 跑所有端”;它更典型的价值是共享业务逻辑。
- 不要忽略原生兜底能力:Flutter/RN/Hybrid 都会遇到平台 SDK、权限、性能和稳定性问题。
- 追问“为什么不用全 Hybrid”:核心链路体验、白屏风险、Bridge 安全和复杂原生能力会限制它。
- 追问“团队怎么渐进式引入”:先选低风险模块试点,建立监控、桥接规范和回滚机制,再扩大范围。