← 返回

Flutter vs React Native

FlutterReact Native 有什么差异?
这里会对比它们的优劣势、支持平台和社区信息。

基本信息

  • 维护方

    Google
  • 首发时间

    2017 年 5 月 12 日
  • 维护方

    Facebook
  • 首发时间

    2015 年 3 月 26 日

社区

语言

  • Dart
  • JavaScript
  • TypeScript

目标平台

  • Web
  • macOS
  • iOS
  • Android
  • Windows
  • 已过时 · 不计入覆盖统计

    Flutter 官方不支持小程序。MPFlutter 等社区方案曾将 Flutter 编译到微信宿主,但项目已长期停更,无法跟上 Flutter 新架构与微信基础库更新,弃坑风险极高。

  • 其他平台
    iPadOS

    Flutter 官方 SDK 不支持 OpenHarmony。OpenHarmony SIG 维护适配版 Flutter SDK(flutter_flutter),需 DevEco Studio 与 HarmonyOS SDK,使用 flutter create --platforms ohos、flutter build hap 产出 HAP;常用插件需从 flutter_packages 以 Git 引入,版本与 pub.dev 不完全一致。华为 AppGallery Connect 提供 Flutter 应用接入文档。HarmonyOS NEXT 纯血设备不能依赖 Android 兼容层跑标准 Flutter APK;部分鸿蒙机上 Platform.isAndroid 仍为 true,需自行区分系统。

    感谢 fangqiu1992、Leon6868 提供的线索

    Linux
    Android Auto
    Android TV
    Tizen
    tvOS
    visionOS
    watchOS
    Wear OS
    QQ 小程序
    京东小程序
    快应用
    快手小程序
    抖音小程序
    支付宝小程序
    百度小程序
  • Web
  • macOS
  • iOS
  • Android
  • Windows
  • 已过时 · 不计入覆盖统计

    React Native 官方不支持小程序。Alita 曾将 RN 代码转换运行在微信小程序端,但项目自 2020 年起基本停更,无法跟上 RN 新架构与微信基础库更新;业界通常另选 Taro/uni-app 等做小程序端。

  • 其他平台
    iPadOS

    React Native 官方不支持鸿蒙。RNOH(React Native for OpenHarmony)由 OpenHarmony 社区维护,通过 Fabric/TurboModules 对接 ArkUI,目前仍在积极跟进 RN 新版本;但三方库需单独适配,升级与集成成本高于 iOS/Android。

    Linux
    Android Auto

    React Native 核心仓库不单独维护 Android TV。react-native-tvos 在同一 fork 中提供 Android TV 支持,预编译产物发布至 io.github.react-native-tvos Maven 组;Android 手机与 Android TV 可共用大部分 JS 代码,但 TV 端需适配 D-Pad 焦点导航等交互差异。

    Tizen

    React Native 核心仓库不包含 tvOS 支持,由 react-native-tvos 社区 fork 维护。需用 npm:react-native-tvos 替换官方 react-native 包(二者不可同时使用),版本号跟随 RN 核心发布(如 0.85.x-0);支持新架构 Fabric 与 Hermes,Podfile 仅支持 iOS 或 tvOS 单一目标。

    visionOS
    watchOS
    Wear OS
    QQ 小程序
    京东小程序
    快应用
    快手小程序
    抖音小程序
    支付宝小程序
    百度小程序

优势

  • 跨平台

    一套代码可覆盖多种平台,缩短开发周期、降低维护成本。

  • 性能

    引擎与框架针对各平台硬件做了优化,整体性能在跨平台方案里较突出。

  • 用户界面

    内置面向 iOS 与 Android 的 UI 组件,便于做出符合两端设计规范的界面。

  • 原生 API

    提供与原生 API 的桥接,可访问相机、加速度计等设备能力。

  • 社区活跃

    社区规模大,文档、教程与示例丰富,遇到问题相对好查。

  • 跨平台

    一套代码可同时面向 Android、iOS 等平台。

  • 原生 API

    在 JavaScript 与系统原生 API 之间提供桥接,可访问相机、通讯录、文件存储等能力。

  • 社区活跃

    社区体量大,文档、教程与示例丰富,生态成熟。

劣势

  • 学习曲线

    需要学习 Dart,对只熟悉 JavaScript/Type 的团队来说有一定门槛。

  • 安装包体积

    应用会打包 Flutter 引擎,安装包通常比纯原生应用更大一些。

  • 内存占用

    需随应用打包渲染引擎,内存占用在跨平台方案里通常偏高。

  • 文字排版

    自绘文字栈在复杂排版、与系统字体特性对齐等方面,往往不如各平台原生文本引擎。

  • Web 与热更新

    Web 端目前仅走 wasm 路线;无官方热更新方案,第三方(如 Shorebird)在国内稳定性一般。

  • 鸿蒙适配

    官方 SDK 不直接支持鸿蒙;需换用社区适配版工具链,三方库与 Google 版 Flutter 版本线可能滞后,分布式等鸿蒙特性需自行写 Platform Channel。

  • 性能

    JavaScript 与原生之间的桥接会带来一定开销,极端性能场景可能不如纯原生。

应用案例