+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 技术方案说明
+ 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 全屏
+
+
