技术方案说明
App 技术栈介绍
Flutter 与 uni-app / uni-app x 的技术路线、生态与落地情况
T-Systems
2026 年 8 月
目录
本次介绍分五个部分
| 01 | 跨端开发的技术路线 | 市面上的方案归类，四条路线的工作方式，界面由谁绘制 |
| 02 | 三个框架的定位 | Flutter、uni-app、uni-app x 各走哪条路线，各自为谁设计 |
| 03 | 生态与落地规模 | 开源程度、社区体量、在用的团队，以及两个整车厂案例 |
| 04 | 产品能力与工程链路 | 小组件与系统能力、原生工程的开放程度、构建发版、AI 工具链 |
| 05 | 结论 | 成本构成、uni-app x 更优的项、推荐方案 |
结论摘要
技术栈推荐 Flutter
01
界面在两端完全一致
Flutter 用自己的渲染引擎绘制界面，不依赖系统控件，也不依赖各机型的浏览器内核。同一份设计稿在 iOS 和 Android 上呈现一致，不需要为两端分别调样式。
02
系统能力没有额外限制
原生侧就是标准的 Xcode 与 Android Studio 工程。桌面小组件、Siri、系统级推送这类能力按常规原生方式实现，不需要再学一套框架方的插件规则。
03
大型 App 上有充分先例
BMW、大众汽车（安徽）、字节跳动、阿里巴巴、腾讯、美团、京东、贝壳、携程都在核心业务中使用。引擎与框架代码全部开源。
04
技术栈稳定
Flutter 自 2015 年起是同一条技术主线，没有发生过技术栈更替。uni-app 系历经 5+ App → nvue → uni-app x 两次更替，前两代已于 2024 年停止官方维护。
uni-app 与 uni-app x 是成熟且被广泛使用的框架，本次不做优劣评判，只对照两者与本项目形态的匹配程度。uni-app x 更优的三项在第 5 章列出。
结论摘要
三个框架的核心对照
| 维度 | Flutter | uni-app | uni-app x |
|---|---|---|---|
| 界面由谁绘制 | 框架自带的渲染引擎 | 机型自带的浏览器内核 | 系统原生控件 |
| 两端一致性 | 逐像素一致 | 受各机型内核版本影响 | 用系统控件，两端有差异 |
| 主要面向 | 独立 App | 小程序为主、App 为辅 | 已有小程序团队转做 App |
| 嵌入 F6 网页 | 通道由 App 侧建立，F6 无需改动 | 同左 | 需 F6 引入 DCloud 的 JS 文件 |
| 原生能力开发 | 强类型代码生成，支持命令行 | 原生插件已停止新增上架 | 只能经 HBuilderX，不支持命令行 |
| 开源程度 | 引擎 + 框架全开源（BSD） | 框架层开源（Apache-2.0） | 框架层开源，Runtime / SDK 闭源 |
| 大型 App 案例 | 字节 90+ 款、闲鱼、美团、京东、贝壳、携程、BMW、大众安徽 ID. UNYX | — | 未检索到同等量级公开案例 |
| 鸿蒙 | 社区分支，3.41 已发布 | 支持 | 一等公民 ✓ |
| 安装包与内存 | 约多 10 MB / 35 MB | — | 更小 ✓ |
| 首版投入 | 基准 | — | 差异在 ±10% 以内 |
最后三行是 uni-app x 占优的项。
01
跨端开发的技术路线
市面上的方案四条路线的工作方式界面由谁绘制
1.1 方案总览
市面上的方案，按底层原理只有四类
框架名字很多，但决定 App 能力和体验的是底层怎么把界面画到屏幕上。按这一点归类，选择面并不大。
| 路线 | 代表方案 | 什么情况下选它 |
|---|---|---|
| ① 原生双端 | Swift / SwiftUIKotlin / ComposeKotlin Multiplatform |
能力上限优先，接受两端各写一套 UI |
| ② 网页套壳 | CordovaCapacitoruni-appTaro5+ App / nvue |
小程序 / H5 是主要入口，App 是补充 |
| ③ 编译到系统控件 | React Nativeuni-app xKuikly（腾讯）.NET MAUI |
框架的翻译表能覆盖住需求范围 |
| ④ 自绘引擎 | Flutter |
要做两端一致、长期迭代的独立 App |
本次不展开的几个：React Native 的前提是团队已有 React 技术栈；Taro、Cordova、Capacitor 的重心仍是网页路线；Kotlin Multiplatform 只共享业务逻辑，界面仍由两端各自实现，严格说不属于跨端 UI 方案；Kuikly 是腾讯 2025 年开源的自研框架，目前主要在腾讯内部使用，对外生态尚早。灰色的 5+ App / nvue 是 DCloud 的上一代方案，已停止维护。
1.2 工作方式
四条路线，从代码到屏幕
路线 ①原生双端
代码Swift + Kotlin
两套
两套
↓
无中间层
直接调用系统 API
直接调用系统 API
↓
界面由谁绘制系统控件
系统给什么就能用什么，能力上限最高；两端各写一遍。
路线 ②网页套壳
代码HTML / CSS / JS
一套
一套
↓
WebView
（机型自带的浏览器）
（机型自带的浏览器）
↓
界面由谁绘制浏览器内核
开发最快；界面随机型内核版本变化，系统能力要靠插件从网页环境打通。
路线 ③编译到系统控件
代码JS / UTS
一套
一套
↓
框架桥接层
（翻译成原生控件）
（翻译成原生控件）
↓
界面由谁绘制系统控件
代码经框架的翻译表转成 Kotlin / Swift；表里没有的能力要自己补齐。
路线 ④自绘引擎
代码Dart
一套
一套
↓
Flutter 渲染引擎
（自带一块画布）
（自带一块画布）
↓
界面由谁绘制引擎自己绘制
界面自己画，不受机型影响；系统能力经通道调用两端的原生代码。
路线 ② 与 ③ 的界面最终都交给别人来画：一个交给浏览器内核，一个交给系统控件。路线 ④ 把这一层拿回到框架自己手里。
1.3 影响
"界面由谁绘制"影响三件事
| ① 原生双端 | ② 网页套壳 | ③ 编译到系统控件 | ④ 自绘引擎 | |
|---|---|---|---|---|
| 两端界面一致性 | 两套代码各自维护 | 受机型内核版本影响 | 控件本身两端有差异 | 逐像素一致 |
| 做一个设计稿上的特殊效果 | 自己实现，无限制 | 用 CSS 实现，复杂动效性能受限 | 受系统控件能力限制 | 自己实现，无限制 |
| 用一个新的系统能力 | 自己写 | 写原生插件 | 按框架方的插件规则写 | 写插件，原生工程完全开放 |
本项目的形态
要嵌入 F6 的网页业务、要用到扫码、定位、推送、相机、蓝牙等一批系统能力，同时要在两端保持一致的品牌体验。
对应到上表
一致性和系统能力这两列同时重要。路线 ④ 在这两列上都不受第三方约束，这是选择 Flutter 的技术出发点。
02
三个框架的定位
各走哪条路线为谁设计适用场景
2.1 技术路线
三个框架各走哪条路线
路线 ④ · 自绘引擎Flutter
开发语言Dart
↓
编译为机器码
AOT，无 JS 解释器
AOT，无 JS 解释器
↓
Flutter 渲染引擎
Impeller / Skia
Impeller / Skia
↓
界面引擎自己绘制
Google 主导，2015 年开源。引擎与框架代码全部公开（BSD-3-Clause）。
路线 ② · 网页套壳uni-app
开发语言Vue / JavaScript
↓
编译为小程序 / H5 / App
一套代码多端发布
一套代码多端发布
↓
App 端：WebView
或已停维护的 nvue
或已停维护的 nvue
↓
界面浏览器内核
DCloud 出品，2018 年开源。核心场景是同时发布小程序、H5 与 App。
路线 ③ · 编译到系统控件uni-app x
开发语言UTS / UVue
↓
编译为 Kotlin / Swift
保留 Vue 写法
保留 Vue 写法
↓
DCloud Runtime
闭源
闭源
↓
界面系统控件
DCloud 的新一代方案，让已有的 Vue / 小程序团队用熟悉的写法产出原生 App。
uni-app x 与 uni-app 是两套独立的技术栈，语言、运行时和渲染方式都不同，不是版本升级关系。
2.2 设计目标
三个框架各自为谁设计
| Flutter | uni-app | uni-app x | |
|---|---|---|---|
| 最初要解决的问题 | 一套代码做出体验接近原生的独立 App | 一套 Vue 代码同时发布小程序、H5 与 App | 让 Vue / 小程序团队产出真正的原生 App |
| 典型使用者 | 已有原生团队，要统一两端体验 | 以小程序为主要渠道的业务 | 熟悉 Vue、希望不换语言做 App 的团队 |
| 最擅长的场景 | 界面复杂、系统能力多、长期迭代的主力 App | 多渠道同时上线、以内容和交易页面为主 | 交互不复杂、以页面和接口为主的 App |
| 发布渠道 | iOS、Android（鸿蒙有社区分支） | 各家小程序、H5、iOS、Android、鸿蒙 | iOS、Android、鸿蒙、部分小程序 |
本项目的渠道范围
首版只发 iOS 与 Android 两个应用商店，不发小程序，也不需要 H5 版本。
已确定的能力清单
扫码、定位、推送、相机、蓝牙、文件、车牌与 VIN 识别等系统能力，以及对 F6 网页业务的嵌入与双向通信。
03
生态与落地规模
开源程度社区体量谁在用两个整车厂案例
3.1 开源程度与社区体量
代码开到哪一层，社区有多大
Flutter
业务框架层 开源
渲染引擎 开源
命令行与构建工具 开源
uni-app x
业务框架层 开源
Runtime 与原生 SDK 闭源
HBuilderX 与打包服务 闭源
主仓库提交数约 8.1 倍
Flutter
91,171
uni-app
11,216
Star 数约 4.3 倍
Flutter
178,643
uni-app
41,600
GitHub 数据核验于 2026-08-25，取自 flutter/flutter 与 dcloudio/uni-app；Fork 数为 31,002 与 3,709。star 数反映的是全球开源关注度，uni-app 在国内企业与政企项目中的落地量不体现在这项数据里。
3.2 落地情况
哪些团队在主力 App 上用 Flutter
A Flutter 官方站与 Showcase 收录
B 使用方自己公开披露
C 第三方对应用安装包的扫描统计
| 使用方 | App / 业务 | 证据 | 补充 |
|---|---|---|---|
| 字节跳动 | 90 多款应用：抖音火山版、飞书 Lark、Coze、掘金等 | A | 官方开发者故事，2026-06 更新 |
| 阿里巴巴 | 闲鱼，已推进到线上主链路 | A | 并开源了 FlutterBoost 等基建 |
| 腾讯 | 多个团队将应用完整迁移到 Flutter | A | 官方页：90% 代码多端复用 |
| 贝壳找房 | 主业务多平台 | A | Showcase 收录，2021-03 |
| BMW | My BMW App，覆盖 47 个国家 | A | 见下一页 |
| 大众汽车（安徽） | ID. UNYX App：购车定制、车联车控、社区、商城 | B | 见下下页 |
| 美团 | 外卖商家端 App，覆盖 90% 以上业务 | B | 美团技术团队博客，2021-03 |
| 京东 | JDFlutter：容器、工具链与组件平台 | B | 京东 EMOP 官方文档 |
| 携程 | 火车票、酒店等十多个核心业务的列表页与主流程 | B | 原生 + React Native + Flutter 混合 |
落地形态一致
这些团队都不是把整个 App 用跨端框架重写，而是原生工程为主体、Flutter 承载业务页面、系统能力仍走原生。本项目采用同样的形态。
第三方统计 C
Appfigures 对新上架应用的 SDK 扫描：Flutter 检出率 11.07%，React Native 6.75%（2024 年 1–10 月；2022 年同项为 10.15% 与 4.73%）。该统计口径不含 uni-app 系，不作对比。
3.3 案例一 · A Flutter 官方 Showcase 收录
BMW：My BMW App
BMW 原先 iOS 与 Android 各有一套 BMW Connected / MINI Connected，两端功能与设计逐渐分叉。2018 年启动跨端方案评估，选型时明确排除了基于浏览器的方案，最终选定 Flutter。
47
个国家、五大洲
双端合一，同时服务 BMW 与 MINI
双端合一，同时服务 BMW 与 MINI
96
每个构建自动生成、测试
并部署的变体数
并部署的变体数
>10,000
截至 2021-10
每个变体累计构建的版本数
每个变体累计构建的版本数
| 2018 年 | 确认双端分叉问题，启动跨端方案评估 |
| 2019 年 10 月 | 慕尼黑工程会议敲定方案 |
| 2020 年 7 月 | My BMW App 上线，从定案到发布不到一年 |
| 团队结构 | 按域拆分：车辆连接与通信抽象层 / 共享应用平台 / 面向客户的功能 |
远程车控、实时车况回传、车辆查找、充电桩与地图，全部落在系统 API 和车联网长连接上。这是一个原生能力密集、且要在多品牌多市场维持同一套体验的 App。
品牌主页
远程车控 · 电量与续航回传
公共充电 · 实时功率与费用
配图为 My BMW App 官方商店截图，用于说明该 App 的功能面，技术栈依据是 Flutter 官方 Showcase 页。BMW 集团 Offboard Platform 副总裁 Dr. Nicolai Kraemer 表述：新应用平台建立在三根支柱之上——易用性、安全性与可靠性。
3.4 案例二 · B 使用方官网合规披露
大众汽车（安徽）：ID. UNYX App
ID. UNYX 是大众汽车（安徽）面向国内市场的品牌 App，覆盖购车定制、车联车控、社区与商城。
大众安徽官网《第三方个人信息共享清单》列明 Flutter SDK（Google LLC），使用情形写作
「App 所有的 L1、L2、L3 页面开发语言」。
即：一级、二级、三级页面均由 Flutter 实现。
为什么用这条作证据
合规披露是法定义务，内容需与实际使用一致，可信度高于技术文章的转述。
同站另一份说明
另列有 React Native SDK，说明该 App 是混合形态，不是纯 Flutter。此处一并注明。
资讯与购车转化
车型与在线配置
车联车控
配图取自 ID. UNYX 应用商店官方截图，用于说明该 App 的功能面。与 BMW 一样，这类 App 的主干功能建立在定位、推送与车联网长连接之上。
04
产品能力与工程链路
小组件与系统能力原生工程的开放程度构建与发版AI 工具链
4.1 扩展能力
App 的形态不止"页面 + 接口"
桌面与锁屏小组件、系统语音助手、系统级多媒体与进度通知、各类 App Extension——这些是后续容易提出来的需求。
| 能力 | Flutter | uni-app x |
|---|---|---|
| iOS 桌面小组件 | 在自己的 Xcode 工程里按标准方式做 | 无内置 API。需在 Xcode 里做成 .appex，再放进 UTS 插件目录并额外配置 |
| Siri / App Intents | 标准原生实现 | 官方说明：仅靠 UTS 插件无法实现，建议走离线打包的原生工程 |
| 安卓桌面小组件 | 标准原生实现 | 三个 Kotlin 文件 + Manifest 注册 + 三个 XML 布局 + UTS 桥接层 |
| 改一次要重来多少 | 一次增量编译 | 官方教程：每次修改这些文件后必须重新制作自定义基座 |
| 取资源 ID 的方式 | 直接引用，编译期检查 | 不能直接引用 R 类，需在运行时按字符串查找 |
两条路线都做得到，区别在做的方式：Flutter 侧就是打开 Xcode 和 Android Studio 写原生代码；uni-app x 侧同样要写原生代码，并且还要额外走一遍 DCloud 的插件与打包规则。
uni-app x 侧内容取自 DCloud 官方文档，安卓小组件清单取自社区 2026-05 的一篇 UTS 插件实战教程，后者为社区记录，非官方文档。
4.2 打包方式
两项官方限制，同时满足不了
uni-app x 有云端打包与离线打包两种方式，部分能力只支持其中一种。以下两条都取自 DCloud 官方文档。
情形 A
要用插件市场上的加密付费插件
官方文档：「uts 加密插件只支持云端传统打包，不支持离线打包、也不支持安心打包」
⇒ 只能走云端打包
✕
互斥
情形 B
要做 Siri 快捷指令这类扩展
官方建议的实现路径：在离线打包的原生工程里实现
AppShortcutsProvider，再用 UTS 插件衔接业务逻辑⇒ 要求离线打包
而离线打包给到的，是一个围绕闭源二进制的壳工程
| 在这个工程里能改的 | 改不了的 |
|---|---|
| 包名、版本号、图标、启动图 | 页面怎么渲染 |
| Gradle 依赖、ABI、SDK 版本 | 页面容器与生命周期 |
| 权限项等清单配置 | UTS 与原生之间的通信机制 |
| 在壳外面加自己的原生模块 | 运行时的任何行为 |
Flutter 侧没有这个分支
只有一种构建方式，ios/ 与 android/ 目录就是两个完整的原生工程，源码级可控，能力之间不存在互斥。
加不加插件、上不上 Siri，都不影响出包方式。
壳工程的核心是 DCloud 预先编译好的一组 AAR，没有源码；自定义的应用类必须继承
DCloudApplication，官方另注明离线 SDK 不支持 Kotlin。另有两条商务约束同样来自官方文档：付费插件的授权绑定唯一的 appid 和包名，更换其一需重新购买；试用版只能用于自定义基座，不能用于正式发布。4.3 构建与发版
发版链路能不能全自动
| 环节 | Flutter | uni-app x |
|---|---|---|
| 出包命令 | flutter build，命令行完整 | 原生插件与 UTS 插件的编译需经 HBuilderX |
| 接入 CI 流水线 | 标准做法，构建机上无人值守 | 图形化 IDE 环节无法在流水线中自动执行 |
| 多渠道 / 多环境包 | 同一条命令批量产出 | 云端打包按次计费，自定义基座需重制 |
| 版本与产物追溯 | 产物在自己的构建机上，可完整留档 | 云端打包由 DCloud 服务完成 |
第 3 章 BMW 的数据可以作参照：每个构建自动生成、测试并部署 96 个变体，每个变体累计构建超过 10,000 个版本。这个量级的自动化建立在命令行完整、构建可无人值守的基础上。
这一栏关心的不是"能不能出包"，两者都能出包；而是出包这一步能否放进自动化流水线，由此决定多环境、多渠道版本的发布节奏。
4.4 AI 工具链
AI 编程工具的支持情况
两边都有官方 AI 工具，区别在能装到哪些工具上，以及公开语料的体量。
| Flutter / Dart | uni-app x | |
|---|---|---|
| 官方 skills | flutter/agent-plugins、dart-lang/skills，独立开源仓库 | 内置在官方 uni-agent 助手中 |
| 官方 MCP 服务 | Dart & Flutter MCP server | uni-app-x-mcp |
| 能用在哪些工具上 | Claude Code、Codex、Cursor 等，装到哪个都行 | 主要围绕自家生态与少数几个工具 |
| 能否自己扩展 | 仓库开源，可 fork、可加自己项目的 skill | 受限于官方提供 |
| 公开语料体量 | Dart / Flutter 近十年的全球公开代码 | UTS / UVue 为新语言，语料以中文官方文档为主 |
AI 生成代码的准确率与这门语言在公开代码里的沉淀量相关。uni-app x 插件市场的付费插件是加密分发的，这部分代码不会进入任何公开语料。
Flutter 的 skills 是任务粒度的，官方已列出十项以上：生成单元测试、生成集成测试、统计测试覆盖率、配置多语言、构建响应式布局、配置声明式路由等，仓库持续新增。
05
结论
成本构成uni-app x 更优的三项推荐方案
5.1 成本
首版投入的构成
占比区间是基于本项目形态的估算，不同团队会有出入。
45–55%
业务逻辑与外围系统
集成、联调
集成、联调
20–25%
UI 实现
10–15%
原生能力
与桥接
与桥接
10–15%
工程、CI、发布
可观测
可观测
— 业务集成：无差异（跟框架无关）
↓ UI 实现：uni-app x 略省（Vue 熟悉度高）
↑ 原生桥接：更贵
↑ 工程 CI：更贵
uni-app x 省在哪里
省在 UI 实现，也就是占比第二小的那一块。团队熟悉 Vue，页面写得更快。
额外成本在哪里
原生桥接与工程 CI 两块更贵。一加一减，首版总投入的差异在 ±10% 以内。
占比不含后续运维与迭代。业务逻辑与外围系统的集成、联调是最大的一块，这部分与选哪个框架无关。
5.2 对方更优的项
uni-app x 强于 Flutter 的三项
01
鸿蒙是一等公民
uni-app x 官方直接支持鸿蒙。Flutter 主线暂未纳入鸿蒙，目前走 OpenHarmony-SIG 的社区分支：3.41 已发布，3.44 预计 2026 年 9 月。
本项目首版范围是 iOS 与 Android，鸿蒙不在内。
02
安装包与内存更小
DCloud 官方实测：安装包 8.5 MB（Flutter 约 18 MB），运行内存 103 MB（Flutter 约 138 MB）。
Flutter 需要带自己的渲染引擎，这部分体积无法省去。
03
热更新
uni-app 系有成熟的整包与分包热更新方案。Flutter 的 Dart 代码是提前编译的机器码，同类能力受平台规则限制。
这三项是真实的技术差异。是否构成决定性因素，取决于产品对鸿蒙、安装包体积和热更新的实际要求。
uni-app x 的离线打包与嵌入式集成会额外增加体积：iOS 约 8.7 MB，Android arm64-v8a 约 8.1 MB。
5.3 推荐
推荐方案
技术栈采用 Flutter，原生工程为主体，
业务页面由 Flutter 承载，系统能力走原生。
业务页面由 Flutter 承载，系统能力走原生。
| 界面一致性 | 自绘引擎，不依赖系统控件与浏览器内核，两端与各机型呈现一致 |
| 系统能力 | 原生工程完全开放，小组件、Siri、系统级能力按标准原生方式实现，无第二套规则 |
| 工程链路 | 命令行完整，可接入 CI 无人值守构建与自动分发 |
| 先例充分 | BMW、大众安徽 ID. UNYX 等同类形态的 App 已在同一条路线上长期运行 |
版本基线 Flutter 3.44.9，首版发布 iOS 与 Android 双端。
附录
数据与事实来源
| 内容 | 来源 |
|---|---|
| 框架技术路线与能力 | Flutter 官方文档；DCloud uni-app / uni-app x 官方文档 |
| 开源程度与社区数据 | GitHub flutter/flutter 与 dcloudio/uni-app，核验于 2026-08-25 |
| 在用团队清单 | Flutter 官方站开发者故事与 Showcase 页；美团技术团队博客；京东 EMOP 官方文档；携程技术公众号 |
| BMW 案例 | Flutter 官方 Showcase 的 BMW 页，含时间线与工程数据；配图为 App 官方商店截图 |
| ID. UNYX 案例 | 大众汽车（安徽）官网《第三方个人信息共享清单》与 SDK 权限说明；配图为 App 官方商店截图 |
| 第三方框架分布统计 | Appfigures 对应用安装包的 SDK 扫描，2024 年 1–10 月与 2025 年 12 月两次口径 |
| 安装包与内存实测 | DCloud 官方发布的性能对比材料 |
| 打包与扩展能力限制 | DCloud 官方文档；安卓小组件交付清单取自社区 2026-05 的 UTS 插件实战教程 |
证据分级：A 框架方官方收录 · B 使用方自己公开披露 · C 第三方对应用安装包的扫描统计。凡检索不到近年官方更新的条目，均已就地注明。
谢谢
问题与讨论
T-Systems
App 技术栈介绍 · 2026-08
Flutter / uni-app / uni-app x
Flutter / uni-app / uni-app x
T-Systems
1 / 27
按 → 翻页 · O 缩略图总览 · F 全屏