Flutter、React Native 还是原生开发？企业移动应用技术选型

当您确定企业需要一款移动应用后，供应商或技术团队几乎一定会接着问：用 Flutter、React Native 开发，还是为 Android 和 iOS 分别做原生开发？对企业主来说，这个问题听起来非常技术化。但答案会影响前期成本、上线速度、用户体验质量、招聘开发人员的难易程度，以及未来多年的维护费用。

本文无意评选出唯一的赢家，每种方式都有适用的场景。更重要的是理解选择某种方式时您实际上在取舍什么，这样才能以批判的眼光评估供应商的建议，并做出符合业务需求、而非仅仅符合开发团队偏好的决定。

要点概览

• 原生开发意味着两套独立代码：iOS 用 Swift，Android 用 Kotlin，可完整调用设备功能，体验最贴合各自平台
• Flutter 和 React Native 用一套代码覆盖两个平台，对于两端功能相同的业务应用通常更经济
• Flutter 自行绘制界面，在所有设备上外观一致；React Native 则使用平台自带的界面组件
• Kotlin Multiplatform 是一条折中路线：共享业务逻辑，界面仍可保持原生
• 最佳选择取决于所需的设备功能、负责维护的团队、与其他系统的集成以及应用的长期规划

选择技术前要回答的问题

在比较技术之前，先确认移动应用确实是正确答案。对某些需求而言，网页应用或渐进式网页应用已经足够，维护成本也低得多。当用户需要频繁打开、依赖可靠的推送通知、大量使用相机或定位，或必须在无网络时工作时，从应用商店安装的移动应用才更有意义。

如果确实需要移动应用，请先回答以下问题。这些答案缩小选择范围的效果，远胜于阅读泛泛的技术对比。

• 用户是谁：普通消费者、合作伙伴，还是内部员工？
• 他们使用什么设备：以 Android 为主、以 iPhone 为主，还是两者都有？
• 需要哪些设备功能：相机、条码扫描、后台定位、蓝牙、NFC 或其他传感器？
• 应用的手感与各平台自带应用完全一致有多重要？
• 应用是否需要[离线工作](/blog/kapan-aplikasi-perlu-bekerja-offline)并在之后同步数据？
• 发布后由谁维护：供应商、内部团队，还是双方共同负责？

原生开发：两款应用，完全掌控

原生应用使用各平台官方的语言和工具开发：iOS 使用 Swift 和 SwiftUI，Android 使用 Kotlin 和 Jetpack Compose。这意味着需要分别开发、测试和维护两套代码，通常由两组技能不同的开发人员负责。

原生开发的优势在于可以直接调用设备和操作系统的全部能力。当苹果或谷歌发布新功能时，原生开发者可以立即使用，无需等待第三方框架提供支持。用户体验也最符合各平台的惯例，从导航、手势到无障碍功能皆是如此。

缺点也很明显：成本和时间。每个功能都要做两遍，每次修复缺陷都要在两套代码中检查。如果团队协作不够严谨，两个版本的行为还可能逐渐出现差异。对于以表单、列表和报表为主的业务应用，这部分额外成本往往得不偿失。

什么时候最适合原生开发

• 应用高度依赖复杂的设备功能，例如实时相机或音频处理、与专用硬件的蓝牙通信，或大量后台任务
• 性能和动画流畅度是产品的核心差异点
• 应用只面向一个平台，例如公司统一配发给外勤团队的 Android 设备
• 公司已有成熟的 iOS 和 Android 团队

Flutter：一套代码，视觉一致

Flutter 是由谷歌开发的开源框架，使用 Dart 语言。它最大的特点是不使用平台自带的界面组件，而是通过自身的渲染引擎绘制每一个按钮、文字和动画。因此，应用在不同设备和不同系统版本上的外观高度一致。

对于业务应用，这种一致性往往是优势。最初确定的设计在低端 Android 手机和最新款 iPhone 上看起来一模一样，视觉测试也更简单。Flutter 还以热重载功能著称，可以加快开发周期，并拥有丰富的插件生态，覆盖相机、地图、支付和通知等常见需求。

也有几点需要权衡。Flutter 应用的安装包通常比简单的原生应用更大，如果您的用户使用存储空间有限的低配手机，这一点就很重要。由于界面是自行绘制的，它不会自动跟随操作系统风格的变化，团队需要主动调整。此外，Dart 在 Flutter 生态之外很少使用，因此相关开发者通常不是从网页开发转过来的。

React Native：借力 JavaScript 生态

React Native 由 Meta 开发，使用 JavaScript 或 TypeScript，以及网页开发中广泛使用的 React 模式。与 Flutter 不同，React Native 显示的是平台自带的界面组件，因此按钮等元素在 iOS 和 Android 上分别带有各自平台的风格。

它最大的优势在于生态和团队。如果您的公司或供应商已经用 React 开发网站和管理后台，部分知识、工具乃至业务逻辑代码都可以共用。由于人才基数大，招聘熟悉 JavaScript 和 TypeScript 的开发者也相对容易。React Native 的新架构还改善了 JavaScript 与原生代码之间的通信，而这曾经是性能问题的常见来源。

另一方面，React Native 应用在设备功能上更依赖第三方库，而这些库的质量和维护水平参差不齐。当 React Native 或操作系统升级时，部分库可能跟不上，需要替换或修补。谨慎选择依赖项非常重要，这与软件供应链安全的原则一致。

Kotlin Multiplatform：共享逻辑，界面保持原生

越来越受关注的另一个选择是 JetBrains 推出的 Kotlin Multiplatform。它的思路不同：Android 与 iOS 之间共享的是业务逻辑，例如数据校验、价格计算、数据同步和服务器通信。界面仍可在各平台上原生开发，也可以借助 Compose Multiplatform 一并共享。

这种方式适合逻辑复杂、两端必须完全一致，同时又希望用户体验保持原生的应用。代价是团队仍需要具备 iOS 技能来开发 iPhone 界面，因此节省的成本不如完全跨平台的框架多。

从商业角度比较

前期成本与上线速度

对于 Android 和 iOS 功能相同的应用，Flutter 和 React Native 所需的工作量一般少于开发两款原生应用。但节省并不意味着成本减半。设计、后端、系统集成、真机测试，以及上架 App Store 和 Google Play 的流程仍然要为两个平台完成。诚实的估算会把这些都算进去，详见软件项目的真实成本一文。

用户体验质量

对于大多数业务应用，例如订购应用、客户应用、销售团队应用或考勤应用，用户分辨不出精心开发的 Flutter 或 React Native 应用与原生应用之间的差别。只有在复杂动画、高强度交互或高级设备功能的场景下，差异才会显现。团队的执行质量远比框架选择更具决定性。

长期维护

移动应用永远没有真正完工的一天。操作系统每年更新，应用商店不断调整要求，依赖库也需要升级。跨平台的一套代码意味着只需在一处更新，但也要依赖框架的发布节奏。原生应用不依赖第三方框架，但每次更新都要做两遍。无论选择哪种方式，都应从一开始就为上线后的维护编列预算。

开发人员供给与供应商依赖

想一想，如果现有供应商无法继续合作，谁能接手这项工作。在本地和国际人才市场都受欢迎的技术，可以降低被单一供应商锁定的风险。同时确保合同写明源代码、应用商店开发者账号和应用签名密钥归贵公司所有，详见软件开发合同的要点。

简明选型指南

• 两个平台功能标准、预算有限的业务应用：Flutter 或 React Native
• 团队或供应商擅长 React，并希望与网站或管理后台共享知识：React Native
• 定制化视觉设计必须在所有设备上完全一致，包括低端 Android 手机：Flutter
• 业务逻辑复杂且必须两端一致，同时希望界面保持原生：Kotlin Multiplatform
• 设备功能非常特殊、性能要求严苛，或只面向单一平台：原生开发

比框架更重要的事

许多应用项目出问题，并不是因为选错了框架，而是因为周边环节。仓促设计的后端和接口让应用缓慢且难以扩展；没有在慢速网络和真实设备上测试；初始范围过大，导致首个版本一再延期。采用从小处着手的最小可行产品方法，可以在大规模投入之前验证需求。

还要确保应用与现有系统良好对接，例如 ERP、客户关系管理系统或收银系统。缺乏集成的独立移动应用，往往会带来重复录入的工作。同时规划好推送通知与用户留存策略，让应用在下载后真正被持续使用。

向潜在供应商提出的问题

1. 01为什么针对我们的需求推荐这项技术？在我们的场景中它有哪些弱点？
2. 02哪些设备功能需要额外的原生代码或第三方库？
3. 03应用如何在真实设备上测试，包括低端手机和慢速网络？
4. 04操作系统或框架版本变化时如何更新，大致费用是多少？
5. 05源代码、应用商店账号和签名密钥归谁所有？
6. 06其他团队能否凭借移交的文档继续开发？

结语

Flutter、React Native、Kotlin Multiplatform 和原生开发都能打造出优秀的业务应用。正确的选择取决于您的用户、所需功能、负责维护的团队以及应用的长期规划。从业务需求出发，请供应商说明其建议的理由和弱点，并从第一天起就为维护编列预算。这样，技术决策就成了一个经得起推敲的商业决策。