APP 跨端框架以及技术选型

太子釢
6 阅读11分钟

一、背景

我打算做一个 GitHub 客户端 App，目标是在 iOS 和 Android 双端，且未来大概率要扩展到鸿蒙（HarmonyOS）生态。项目没有热更新需求，属于"一次开发、多端分发、后续逐步铺开"的典型场景。

候选技术有 5 个：React Native、Flutter、UniApp、KMP（Kotlin Multiplatform）、KMP + CMP（Compose Multiplatform）。本文从性能体验、社区活跃度、各平台兼容性（重点是 iOS/Android/鸿蒙三端）、开发成本、热更能力、内存占用、包大小八个维度逐一评估，最后给出选型结论。

需要先说明：GitHub 客户端这种应用，界面复杂度不高、网络请求为主、重业务逻辑轻渲染，对性能的绝对要求并不极端，真正决定成败的往往是生态成熟度和开发效率。

二、候选技术画像

2.1 React Native（RN）

React Native 是 Meta 出品的跨端框架，采用 JS/React 渲染原生组件。社区规模大：GitHub 约 120K stars，Stack Overflow 上日常开发者使用率约 8.40%（2024 年 7 月数据）[15]。

在鸿蒙支持上，React Native 走的是社区驱动路线：OpenHarmony-SIG 开源了基于 RN 0.72.5 的 ohos_react_native，适配 OpenHarmony API 15+，支持 DevEco Studio 5.1.1 调试 [7][6]。2026 年 1 月，RN 核心贡献方 Software Mansion 宣布与华为合作，将 React Native 支持带到 HarmonyOS NEXT [8]。整体处于"可用但仍偏早期"的阶段 [11]。包大小方面，比 Flutter 略小，但仍明显大于原生和 KMP，主要来自 JS 引擎（Hermes）和 React Native 框架本体。

性能与内存表现属于中等：UI 渲染基于原生组件，新架构（Fabric + JSI + TurboModules）已消除旧的异步桥接瓶颈，但 JS 线程仍是性能关键路径，重度动画和复杂交互场景存在卡顿丢帧风险，冷启动受 JS bundle 解析影响偏慢；运行时需要常驻 JS 引擎，叠加 React 渲染树，内存占用在图片、长列表较多时偏高，但对普通列表类应用影响可控。

2.2 Flutter

Flutter 是 Google 出品的自绘引擎框架。社区活跃度在所有候选里最高：GitHub 约 170K stars，Stack Overflow 日常开发者使用率约 9.40%，提交量也多于 React Native [15]。

鸿蒙支持是三家里最成熟的：2026 年 1 月 OpenHarmony 成立 Flutter SIG 工作组，3 月发布 Flutter 3.35 Release，全量适配上游特性并对性能负载做了深度优化 [4]；华为官方也提供了 Flutter 应用适配鸿蒙的开发指南 [5]。已被认为是低成本迁移鸿蒙的可行路径 [3]。

性能与内存表现是它最大的优势也是最大的代价：自绘引擎 + AOT 编译带来稳定的 60FPS 动画、跨端一致的表现和较快的冷启动，重度动画场景尤其流畅；代价是引擎层本身有较高的内存基数，低端 Android 设备上内存压力较大，需要开发者主动做内存优化。包大小也不占优：是四个被测方案中最大的，主要因为要内置自绘引擎的 Skia 渲染库。

2.3 UniApp

UniApp 是 DCloud 出品的国内跨端框架，基于 Vue 语法。自 HBuilderX 4.27 起官方支持 Harmony Next 平台的 App 开发，不过目前仅支持 vue3 项目编译到鸿蒙 [1]。从 v3.1.0 开始正式支持鸿蒙平台，可将 Vue 代码编译为鸿蒙原生应用（HAP 包），支持原生渲染（通过鸿蒙原生组件渲染界面，性能接近原生开发）和调用鸿蒙系统 API [2]。

它的优势在于国内生态和"一套代码多端分发"（App、小程序、H5），但对纯 iOS/Android 的 GitHub 客户端来说，核心优势（小程序/多端投放）用不上；其渲染机制各端实现差异较大，鸿蒙端已支持原生渲染 [2]，iOS/Android 端则沿用 uni-app 一贯的 WebView 渲染路线（另有 nvue/uni-app x 等原生渲染方案，但需额外的约束与学习成本），重度交互场景的体验需按端单独验证。

2.4 KMP（Kotlin Multiplatform）

KMP 是 JetBrains 推出的代码共享方案，核心思路是共享业务逻辑而非共享 UI：Android、iOS、桌面、Web、服务端均可达到高达 80% 的代码复用 [9]。官方声明对 Android、iOS、桌面、Web、服务端均已生产就绪 [13]。

鸿蒙是它的差异化优势：Kotlin 是 Android 原生语言，Android 项目可低成本改造成 KMP 结构；KMP 可把共享业务逻辑编译到鸿蒙端复用，哔哩哔哩已据此启动鸿蒙原生应用的业务逻辑开发 [9]。但需注意：纯血鸿蒙（HarmonyOS NEXT）基于 OpenHarmony，官方开发语言是 ArkTS/ArkUI，Kotlin 不能直接运行，KMP 通常只能共享逻辑层，UI 层仍需用 ArkUI 重写，不能与 Android 共享界面。

性能与内存是它的明显优势：业务逻辑编译为各平台原生代码，无 JS/Dart 解释器开销，运行效率与原生几乎一致，内存占用在已评测方案中处于最低梯队；UI 由原生实现，性能上限就是各平台原生应用自身。包大小同样优秀：与原生几乎持平，明显小于 RN 和 Flutter，因为业务逻辑编译成各平台原生代码，不内置自绘引擎或 JS 引擎。

2.5 KMP + CMP（Compose Multiplatform）

CMP 是 KMP 的 UI 层方案。2025 年 5 月发布的 1.8.0 版本将 iOS 支持提升到 Stable 生产可用，KMP 由此成为"共享 UI + 原生体验"的完整移动端方案 [12][13]。

但鸿蒙是明显短板：JetBrains 目前没有对 HarmonyOS 的官方支持，社区提交了支持请求（issue #4155），只能靠社区或自行适配 [14]。

三、八维对比

维度React NativeFlutterUniAppKMPKMP+CMP
技术架构JS/React 编写 UI，Fabric 将组件树映射为各端原生组件，逻辑运行在 JS 引擎（Hermes）中，AOT 字节码预编译Dart 编写，Widget 树自建渲染，AOT 编译为原生机器码，不依赖系统组件，Impeller 作为默认渲染后端，自持渲染层Vue 编写，iOS/Android 编译为 JS 运行于 WebView，通过桥接调用原生能力；鸿蒙端编译为 HAP 由 ArkUI 原生组件承载Kotlin 共享业务逻辑（编译为各端原生代码），UI 用各端原生技术（Jetpack Compose / SwiftUI / ArkUI）分别实现Kotlin + Compose 共享逻辑与 UI，仅 app 壳与平台服务为各端实现
绘制引擎无自绘引擎，控件绘制完全交由系统（iOS 由 UIKit/CoreAnimation 绘制、Android 由 View 系统绘制），框架只负责调度与更新自绘引擎（Impeller/Skia）直接调用 GPU（Metal/OpenGL/Vulkan）逐像素绘制，跨端像素级一致，不经过系统组件无自绘引擎，iOS/Android 由 WebView 内核（WebKit/Blink）绘 DOM；鸿蒙端由 ArkUI 原生组件绘制 [2]无共享绘制引擎，UI 用各端原生控件（Jetpack Compose / UIKit / ArkUI）绘制，绘制完全交由系统自绘引擎（Skia/Skiko）直接绘制，两端像素级一致，与 Flutter 同源渲染方案
性能体验中：原生组件渲染、新架构消除桥瓶颈，但重度动画/复杂交互存在卡顿丢帧风险，冷启动偏慢（受 JS bundle 解析影响）优：自绘引擎 + AOT，动画流畅、跨端一致、冷启动快，但引擎层内存基数高鸿蒙端原生渲染后接近原生 [2]，iOS/Android 端走 WebView 渲染路线，重度交互体验受限优：逻辑编译为原生代码，性能与原生一致；UI 为原生实现，上限就是原生自身同 Flutter 的自绘方案（CMP 无独立实测，推测与 Flutter 相近）
社区大：120K stars、SO 使用率 8.40% [15]大：170K stars、SO 使用率 9.40%（两者对比中占优）[15]国内活跃，国际化较弱中：JetBrains 官方 + 大厂背书 [9]新兴：JetBrains 官方，生态待成长 [12]
双端兼容性优优优优优（iOS 已 Stable）[12]
鸿蒙兼容性可用偏早期：社区开源 + Software Mansion×华为 [6][7][8]最成熟：官方 SIG + Flutter 3.35 [4][5]官方支持（HBuilderX 4.27+）[1]逻辑层可复用（ArkTS/ArkUI 需另写 UI）[9]无官方支持，仅社区 issue [14]
开发成本低（前端工程师即可）低（需学 Dart）低（Vue）中（逻辑共享 + 双端 UI 各写一遍）中（逻辑 + UI 一次写，但需学 Kotlin/Compose）
热更支持（CodePush 类生态方案）官方不支持原生热更支持（wgt 热更新）不支持不支持
内存占用中：JS 引擎 + React 渲染树有固定开销，图片/长列表场景偏高低-中：引擎层基数高，低端设备压力大；普通列表应用可控视渲染路线而定：WebView 路线内存开销较大，原生渲染路线接近原生优：接近原生（业务逻辑原生编译）同 Flutter 的自绘引擎开销，无独立实测
包大小偏大：较 Flutter 略小，但明显大于原生与 KMP偏大（被测方案中最大）无公开实测数据优：接近原生水平同 KMP（无独立实测）

四、风险与局限

  1. 性能与内存结论依赖具体实现：本文性能、内存为定性评估，实际表现受机型、应用形态、代码实现影响较大（如 Flutter 的低端机内存压力、RN 的重度动画丢帧），上线后需在目标设备上实测验证。
  2. 纯血鸿蒙下 UI 层无法复用：HarmonyOS NEXT 的开发语言是 ArkTS/ArkUI，Kotlin 不能直接运行，KMP 只能共享逻辑层，鸿蒙端 UI 仍需用 ArkUI 完整重写一份 [9]。
  3. CMP 的鸿蒙缺口是硬伤：若以"未来上鸿蒙"为必要条件，CMP 目前无官方支持 [14]。
  4. 开发成本与生态略逊：iOS（SwiftUI）与 Android（Jetpack Compose）双端 UI 各写一遍，工作量高于 Flutter/RN 的单套 UI；生态规模也不及 Flutter，遇到问题时的可检索性稍差，更适合以 Kotlin/原生能力为主的团队。

五、结论

综合评估，我的最终选择是 KMP（Kotlin Multiplatform）：

  • 性能、内存与包大小均为原生水平：业务逻辑编译为各平台原生代码，无 JS/Dart 解释器开销，运行效率与原生几乎一致，内存占用处于最低梯队，包大小接近原生；对 GitHub 客户端这类 API 数据驱动的列表/详情应用，体验上限就是原生自身。
  • 视觉体验纯原生：UI 用 Jetpack Compose / SwiftUI 等原生组件实现，界面观感、手势、动效、主题乃至无障碍行为都与系统原生应用一致，不经过自绘（Flutter/CMP）或 WebView（UniApp）中间层，用户拿到的就是"纯原生"的体验。
  • 架构约束倒逼工程质量：逻辑层要跨 iOS/Android/鸿蒙共享，就必须把业务与 UI 彻底解耦、把平台差异收敛到 expect/actual 等标准化边界上，对模块拆分与接口设计的要求远高于"一套代码写到底"的方案；短期是开发成本，长期换来的是更清晰、更健康的工程架构。
  • 鸿蒙路线基于官方生态：Kotlin 是 Android 原生语言，Android 项目可低成本改造成 KMP 结构；未来上鸿蒙时共享业务逻辑层可直接编译复用，哔哩哔哩已有实践 [9]。即便需用 ArkUI 另写 UI，业务层仍能做到三端共享，这是其他跨端方案不具备的。
  • 排除 CMP 的决定性理由：CMP 能连 UI 一起共享，但 JetBrains 目前没有鸿蒙官方支持 [14]，与本项目"未来大概率上鸿蒙"的目标冲突；KMP 只共享逻辑层，反而没有绑定某套 UI 技术。
  • 权衡与代价：iOS 与 Android 的 UI 各写一遍（SwiftUI / Jetpack Compose），开发工作量高于单套 UI 方案；社区生态小于 Flutter，遇到问题时的可检索性稍差，更适合以 Kotlin/原生能力为主的团队。

一句话总结：以 Kotlin/Android 技术栈为主、兼顾未来鸿蒙三端业务逻辑复用，选 KMP；它用双端 UI 各写一遍的开发成本，换来了与原生一致的性能、资源占用和鸿蒙技术栈一致性。

来源

avatar
文章
阅读
粉丝