Continental-AG/conti-docs
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

update flutter vs uniapp

Browse Source
This commit is contained in:
Guangfei.Zhao
2026-08-26 09:49:28 +08:00
parent 4fc7c99bff
commit 334032aa4e
2 changed files with 128 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+2 -2
View File
@@ -113,9 +113,9 @@ V1.1 相对 V1.0 的主要变化：第 4 章拆分到 [`prd/modules/`](./prd/mod
| 文档 | 内容 |
| --- | --- |
| [tech-selection/前端技术路线评估-Flutter-vs-UniApp.md](./tech-selection/前端技术路线评估-Flutter-vs-UniApp.md) | Flutter / uni-app / uni-app x 三条路线对比，结论**推荐 Flutter**。六章：① 市面跨端方案清单与四条架构路线 ② 三者定位与架构对比 ③ 结合本项目业务的技术评估 ④ 生态、社区与 AI 工具链 ⑤ 构建发布与可扩展性 ⑥ 结论（含成本口径：首版 ±10% 基本持平，差异在五年周期）。含非技术读者可读的通俗解释与术语表 |
| [tech-selection/前端技术路线评估-Flutter-vs-UniApp.md](./tech-selection/前端技术路线评估-Flutter-vs-UniApp.md) | Flutter / uni-app / uni-app x 三条路线对比，结论**推荐 Flutter**。六章：① 市面跨端方案清单与四条架构路线 ② 三者定位与架构对比 ③ 结合本项目业务的技术评估 ④ 生态、社区、落地规模与 AI 工具链 ⑤ 构建发布与可扩展性 ⑥ 结论（含成本口径：首版 ±10% 基本持平，差异在五年周期）。附录 A 来源清单、附录 B 术语表、**附录 C 对 DCloud 官方对比材料的逐条核验**（含热更新、包体、内存这几条对我方不利项的主动列出）。含非技术读者可读的通俗解释 |
与 `flutter-app/` 的分工：**技术结论仍以 `flutter-app/01-14` 为准**，本目录只做对外解释与论证，不产生新的技术决策。文中所有对 uni-app x 的判断都在附录 A 给出了官方文档链接，便于客户自行复核（核验日期 2026-08-25，日后引用前建议重新抽查）。
与 `flutter-app/` 的分工：**技术结论仍以 `flutter-app/01-14` 为准**，本目录只做对外解释与论证，不产生新的技术决策。文中所有对 uni-app x 的判断都在附录 A 给出了来源链接，其中仅 5.4 节的安卓小组件交付清单取自社区实战记录（已就地标注），其余均为官方文档，便于客户自行复核（核验日期 2026-08-25，日后引用前建议重新抽查）。
## 已知文档间差异（已在 PRD V1.0 修订）
tech-selection/前端技术路线评估-Flutter-vs-UniApp.md
+126 -14
View File
@@ -43,11 +43,14 @@
| 原生工程归谁 | **自己的工程**，Flutter 挂进去 | DCloud 的壳工程 | **DCloud 的壳工程**，核心是闭源 AAR |
| App 扩展能力 | 标准原生开发，无额外规则 | 受限 | **小组件需 Xcode 做 .appex；Siri 需离线打包** |
| 接入现有 GitLab 流水线 | 原生支持 | — | 结构性错配 |
| 鸿蒙 | 社区分支，落后一段时间 | 支持 | **支持更完整**（这一项 uni-app x 更强） |
| 鸿蒙 | 社区分支（3.41 已发布，3.44 预计 9 月） | 支持 | **一等公民**（这一项 uni-app x 更强） |
| 包体与内存 | 约多 10MB / 35MB | — | **更小**（这一项 uni-app x 更优，但本项目无包体 KPI） |
| 首版成本 | 基准 | — | **±10% 以内，基本持平** |
三条路线总览。uni-app（传统版）几格标"—"，是因为它在"界面本质上是网页"这一条上就已经不适合本项目，后续章节重点放在 Flutter 与 uni-app x 的对比。每一行的依据见第 1–5 章，外部数据来源见附录 A。
**表中"包体与内存""鸿蒙"两行是 uni-app x 占优的项，我们主动列出。** DCloud 官方另有一页专门对比 Flutter，客户方检索时大概率会看到——**我们已把那一页逐条核验，结果见[附录 C](#附录-c-对-dcloud-官方对比材料的核验)。**
---
## 1 市面上的跨端方案
@@ -288,12 +291,18 @@ F6 是这个项目里影响面最大的外部依赖——销售全链路、整
这一条在项目初期看不出价值，在第二年会。
### 3.5 渲染性能（明确标注：非决定项）
### 3.5 渲染性能、包体与内存（明确标注：非决定项）
Flutter 用自绘引擎、Dart 提前编译成机器码；uni-app x 编译成原生控件调用。**两者在这个项目上都够用**——这是一个以表单、列表、报表为主的业务 App，不是游戏，也不是有复杂动效的消费级产品。
**拿性能说事经不起追问，我们不把它算进结论。** 列在这里只是让对比完整。
**包体与内存这两项，Flutter 确实更高，我们主动列出。** DCloud 官方对比页给出的实测是：安装包 18M 对 8.5M、内存占用约 138MB 对 103MB。**这两个数字我们认为是可信的**——自绘引擎要把渲染引擎打进包里，这是路线本身的代价，不是实现问题。
但它在本项目不构成决策变量：这是一个**门店员工使用的内部业务 App**，通过企业分发和应用商店安装，不参与消费级 App 的下载转化竞争，没有包体 KPI，也没有"多 10MB 就少一批用户"的场景。设备是门店配发的作业终端，35MB 内存差异在现代机型上不产生可感知影响。
需要一并说明的是，**uni-app x 走离线 / 嵌入这条路同样有包体增量**：按 DCloud 官方数字，iOS 约 8.7 MB、Android（仅 arm64-v8a）约 8.1 MB。这项对比的完整核验见[附录 C](#附录-c-对-dcloud-官方对比材料的核验)。
真正和体验相关、且在本项目真实存在的差异是**视觉一致性**：这个 App 要把六套来源不同、不同团队不同时期做的小程序整合成一个东西。整合最大的隐性风险不是功能缺失，而是同一个业务概念在不同页面上叫法不同、长得不同、操作方式也不同——用户会觉得"这还是六个东西，只是塞进了同一个壳子"。Flutter 逐像素自绘，同一套设计规范落地结果完全一致；uni-app x 用系统控件，安卓的按钮和苹果的按钮本来就不一样，要抹平需要额外工作。
### 3.6 小结
@@ -306,12 +315,13 @@ Flutter 用自绘引擎、Dart 提前编译成机器码；uni-app x 编译成原
| 19 模块的工程边界 | 编译期物理强制 | 靠规范与评审 | 中等 |
| 视觉一致性 | 逐像素一致 | 需额外抹平 | 中等 |
| 渲染性能 | 够用 | 够用 | **否** |
| 包体与内存 | 约多 10MB / 35MB | 更小 | **否**（内部业务 App，无包体 KPI） |
六个维度的逐条对照。最后一行特意列出，是为了说明我们没有把不构成差异的项算进结论里。
七个维度的逐条对照。最后两行特意列出，是为了说明我们没有把不构成差异的项算进结论里，也没有回避对方占优的项。
---
## 4 生态、社区与 AI 工具链
## 4 生态、社区、落地规模与 AI 工具链
这一章比大多数人以为的重要。**技术栈的生命力不看今天能做什么，看社区每天往里投入多少。**
@@ -354,7 +364,25 @@ GitHub 实测数据，核验于 2026-08-25，取自 `flutter/flutter` 与 `dclou
对比 Flutter：2015 年至今同一条主线持续演进，没有让用户推倒重来过。**这是"平台连续性"的差异，会直接变成五年后的迁移成本。**
### 4.3 AI 工具链：开放生态 vs 厂商内置
### 4.3 谁在用：可查证的落地规模
提交数说明的是"投入"，落地案例说明的是"验证"。这里只列**厂商官方渠道公开发布、可点开核对**的，不引用二手传闻。
**字节跳动是目前公开信息中规模最大的 Flutter 使用方**（数据来自 Flutter 官方中文站的开发者故事，2026-06-22 更新）：
- **90 多款 Flutter 应用**在线上运行
- **800 多名 Flutter 开发者**，并设有专职的 Flutter Infra 基建团队
- 点名的产品包括：抖音火山版、飞书 Lark、Coze、小荷健康、幸福里、Lemon8，以及技术社区 **掘金**
原文对收益的表述是：**「与原生双端开发相比，Flutter 为我们的团队节省了大约 1/3 的开发时间」**。
> **这个 1/3 必须标清口径：它的对照组是"原生双端"，不是 uni-app。** 拿它去论证"Flutter 比 uni-app x 省 1/3"是错的，我们不这么用。本文档的成本结论仍然是第 6.1 节那句——**首版两条路线基本持平**。这里引用它只说明一件事：一个有能力自研全套基建的团队，在做过 90 多个 App 之后仍然选择继续投入 Flutter。
顺带一提：**这份评估里引用的技术社区"掘金"，它自己的 App 就是 Flutter 写的。**
**uni-app x 侧，我们未检索到同等量级的公开大厂落地案例。** 这里写"未检索到"而不是"没有"——DCloud 官方公布的是 uni-app 全系的开发者与应用总量，那个数字很大，但它统计的主体是小程序和 H5，无法单独拆出"用 uni-app x 做的独立 App"有多少、规模多大。**口径不可比的数字我们不拿来对比。**
### 4.4 AI 工具链：开放生态 vs 厂商内置
这是这次特别关注的一项。**先说清楚：两边都有官方 AI 工具，不能说 uni-app x 没有。**
@@ -379,13 +407,14 @@ GitHub 实测数据，核验于 2026-08-25，取自 `flutter/flutter` 与 `dclou
**这一条对 2026 年的实际开发效率有直接影响。** 同一个开发者，用 AI 辅助写 Flutter 和写 UTS，产出质量和返工率不是一回事。
### 4.4 这一章对本项目意味着什么
### 4.5 这一章对本项目意味着什么
生态不是"锦上添花"的加分项，它决定三件很实际的事：
生态不是"锦上添花"的加分项，它决定四件很实际的事：
1. **遇到问题能不能自己解决** —— 引擎开源你能读能修，闭源你只能等工单。
2. **五年后还有没有人维护** —— 8 倍的提交量差距 + 三代方案换代史，指向两种不同的平台连续性。
3. **AI 辅助的效率** —— 直接落在代码量最大的那两块工作上。
3. **有没有人趟过同样规模的路** —— 90 多款线上应用、800 多名开发者的实践，意味着我们会遇到的坑大概率已经有人踩过并写下来了。
4. **AI 辅助的效率** —— 直接落在代码量最大的那两块工作上。
---
@@ -484,10 +513,31 @@ uni-app x 提供两种出包方式：
uni-app x 的扩展能力现状，取自 DCloud 官方文档。
#### 安卓侧同样如此：一个桌面小组件的真实交付清单
上表是 iOS 侧，容易被理解成"苹果比较特殊"。**实际上安卓侧是一样的。** 下面这份清单来自社区一篇 2026-05 的 UTS 插件实战教程（**注明：这是社区一手实战记录，不是官方文档**），做的就是一个安卓桌面待办小组件，最终要交付的东西是：
| 交付物 | 内容 |
| --- | --- |
| **三个 Kotlin 文件** | `TodoWidgetNative.kt`（业务）、`TodoWidgetProvider.kt`（`AppWidgetProvider`）、`TodoListRemoteViewsService.kt`（列表数据源） |
| **AndroidManifest 注册** | receiver 声明 + service 声明，service 需带 `BIND_REMOTEVIEWS` 权限 |
| **三个 XML 布局** | 小组件主布局、列表项布局、空态布局 |
| **UTS 桥接层** | `interface.uts` + `index.uts`，且导出类型"必须使用 `type` 而非 `interface`" |
一个安卓桌面小组件在 uni-app x 下的实际交付物。
**除了这些代码本身，工具链还额外强加了三条成本，这才是关键：**
- 原文写明：**「每次修改这些文件后必须重新制作自定义基座」**——也就是说，改一行 XML 布局都要重新走一遍自定义基座的制作流程；只有纯 UTS / UVue 的改动才走差量编译。**这在标准安卓开发里就是一次普通的增量编译。**
- **不能直接 import `R` 类**取资源 ID，要用 `getIdentifier()` 在运行时按字符串查找——编译期的类型检查在这里失效了。
- 出现 `index.kt` 找不到、`R$id.class` 冲突这类报错时，需要手动清掉 `unpackage/cache/` 再重来。
**落点：安卓侧同样要写 Kotlin、同样要碰 AndroidManifest 和 XML 布局。** 而且断了之后不是回到干净的原生开发——是回到原生开发，再加上一个"每改一次就重打基座"的循环。
**这里要把话说准，不能说"做不到"——做得到，但代价是三层的：**
1. **你最终仍然要打开 Xcode、用 Swift 写原生扩展。** "一套代码跨端"的承诺在这里就断了。
2. **在此之上还要额外绕一遍 DCloud 的打包体系**——配 `ios-extension.json`、处理描述文件、在云端打包和离线打包之间做取舍。这是标准原生开发里不存在的额外一层。
1. **你最终仍然要打开 Xcode 写 Swift、打开 Android Studio 写 Kotlin。** "一套代码跨端"的承诺在这里就断了，而且是两端一起断。
2. **在此之上还要额外绕一遍 DCloud 的打包体系**——配 `ios-extension.json`、处理描述文件、每改一次原生文件重做一次自定义基座、在云端打包和离线打包之间做取舍。这是标准原生开发里不存在的额外一层。
3. **而官方给出的那条"离线打包"退路，本身就是 5.3 里那个受限的壳工程**——`Application` 得继承 `DCloudApplication`、传统离线 SDK 不支持 Kotlin、运行时闭源不可改。它不是一条干净的原生开发通道，只是一个开口更大一点的口子。
> 一句话概括：**你既要会 Swift 和 Kotlin，又要额外学一套 DCloud 的插件与打包规则，最后还只能在别人的壳外面加东西。**
@@ -506,7 +556,7 @@ uni-app x 的扩展能力现状，取自 DCloud 官方文档。
| 运行时能否排查 / 修改 | 引擎开源，可读可改 | **闭源二进制（AAR），不可改** |
| 宿主原生代码语言 | Kotlin / Swift，无限制 | 官方原文：**「App离线SDK不支持Kotlin」** |
| 加密付费插件与离线打包 | 不适用 | **互斥** |
| 桌面小组件 / Siri 等扩展 | 标准原生开发 | 需 Xcode 写原生 + 额外绕打包体系 + 落在受限壳工程里 |
| 桌面小组件 / Siri 等扩展 | 标准原生开发 | **两端都要写原生**（Swift + Kotlin）+ 额外绕打包体系 + 每改一次原生文件重做自定义基座 |
| 构建是否经第三方云 | 否，全在自有流水线 | 云端打包方式下需要 |
工程链路对比。倒数第一行对有正式安全评审流程的企业是需要走流程回答的问题，不是一句"没事的"能带过的技术细节。
@@ -583,11 +633,19 @@ UI 实现 20-25% ↓ 略省 ← 它的优势只作用在这一块
这一节不能省。一份只说对方缺点的评估，在技术评审面前站不住。
**① 鸿蒙支持目前确实更完整。** UTS 可编译成鸿蒙的 ArkTS，渲染模式已覆盖鸿蒙；Flutter 的鸿蒙支持走社区维护分支，进度落后官方稳定版一段时间。**鸿蒙不在本项目首版范围内**，我们的 Flutter 版本基线刻意停在 3.44.9 而没追最新版，就是为后续接鸿蒙留兼容窗口。但如果鸿蒙将来变成硬需求，这一条对 uni-app x 有利，应当如实计入。
**① 鸿蒙支持目前确实更完整。这一条要说得精确，分三层：**
- **对 uni-app x 有利的部分，如实写明：** UTS 可直接编译成鸿蒙的 ArkTS，鸿蒙在它这里是一等公民路径。而 Google 已经明确**不会在 Flutter 主线支持鸿蒙**——官方仓库里那条鸿蒙适配 issue（#150536）的处理结果是 **Closed as not planned**。这不是"还没做"，是"不打算做"。
- **但差距在收窄：** 鸿蒙侧的 Flutter 适配由 OpenHarmony-SIG 的社区分支承接，**2026 年 1 月已成立 Flutter SIG 做治理**，按季度跟进主线版本；目前 **3.41 的鸿蒙版已发布，3.44 的鸿蒙版预计 2026 年 9 月**。它不是一个无人维护的野生 fork。
- **对本项目的具体含义：** 我们的版本基线正是 **Flutter 3.44.9**，对应的鸿蒙版下个月就到。**鸿蒙不在本项目首版范围内**，而我们刻意停在 3.44.9 没追最新版，本来就是为后续接鸿蒙留兼容窗口。所以这条差距在本项目的时间线内是可控的。
**结论仍然是：如果鸿蒙将来变成硬需求，uni-app x 在这一项上更省事，应当如实计入。** 只是它比"Flutter 做不了鸿蒙"要小得多。
**② 小程序与 H5 的复用能力是真实存在的。** 将来若又有"同一套业务同时发 App 和小程序"的需求，它的价值会立刻显现。本项目用不上，但这是它客观的长处。
**③ Vue 技术栈上手快，国内人才池更大。** 团队组建和后续换人确实更容易。需要提醒的是，uni-app 岗位在市场上常和"Vue / 小程序 / H5 / 前端"捆绑，招到的人不一定有移动端原生经验——对一个原生能力密集的项目，这一点要考虑。
**③ UTS 这门语言的设计思路是对的。** 它直接编译成 Kotlin 和 Swift，比传统那种"传一个字符串方法名 + 一包弱类型参数"的桥接方式干净得多，方向上是正确的。**我们对 uni-app x 的保留意见不在语言设计，在它外面那层工具链和打包体系**——第 4、5 章列的问题，没有一条是 UTS 语言本身造成的。
以上三点是**能力层面**的长处。另外还有三项 uni-app x 占优、但不属于能力范畴的：**包体更小、内存占用更低、支持热更新**——这三项连同 DCloud 官方对比材料的逐条核验一并放在[附录 C](#附录-c-对-dcloud-官方对比材料的核验)。
### 6.6 如果最终选择 uni-app x，需要先落实的六项前提
@@ -612,7 +670,7 @@ UI 实现 20-25% ↓ 略省 ← 它的优势只作用在这一块
## 附录 A 数据与事实来源
本文档中所有关于 uni-app / uni-app x 的技术判断，均来自 DCloud 官方文档或对应厂商官方文档；社区数据取自 GitHub 公开接口。便于客户方自行复核。核验日期：**2026-08-25**。
本文档中所有关于 uni-app / uni-app x 的技术判断，**除单独标注者外，均来自 DCloud 官方文档或对应厂商官方文档**；社区数据取自 GitHub 公开接口。全文只有一处引用社区来源（5.4 节的安卓小组件交付清单），已在正文和下表中明确标注。便于客户方自行复核。核验日期：**2026-08-25**。
| 结论 | 来源 |
| --- | --- |
@@ -634,6 +692,10 @@ UI 实现 20-25% ↓ 略省 ← 它的优势只作用在这一块
| 神策 uni-app x SDK 不在插件市场，需联系技术顾问索取 | [神策分析 — uni-app x 集成文档](https://manual.sensorsdata.cn/sa/docs/XD3SLh7B/v0300) |
| Flutter 官方 agent skills 与 MCP server | [Flutter — Agent skills](https://docs.flutter.dev/ai/agent-skills)、[Dart and Flutter MCP server](https://docs.flutter.dev/ai/mcp-server) |
| Flutter Skills 发布公告（2026-05-06） | [Introducing Skills for Dart and Flutter](https://flutter.dev/blog/introducing-skills-for-dart-and-flutter) |
| DCloud 官方的 uni-app x 与 Flutter 对比（包体 18M / 8.5M、内存约 138MB / 103MB、仅覆盖 VDOM 模式、"需求墙尚有未完成项"等自陈边界） | [uni-app x — 跨平台技术选型](https://doc.dcloud.net.cn/uni-app-x/select.html) |
| 字节跳动 90+ 款 Flutter 应用、800+ Flutter 开发者、产品清单与"节省约 1/3 开发时间"（口径为对比原生双端） | [Flutter 中文文档 — 开发者故事 / 案例](https://docs.flutter.cn/resources/case-studies)（2026-06-22 更新） |
| 安卓桌面小组件在 uni-app x 下的交付清单：3 个 Kotlin 文件 + Manifest 注册 + 3 个 XML 布局 + UTS 桥接；「每次修改这些文件后必须重新制作自定义基座」；需用 `getIdentifier()` 取资源 ID **（社区来源，非官方文档）** | 掘金社区 UTS 插件桌面小组件实战教程，2026-05-31 |
| Google 明确不在 Flutter 主线支持鸿蒙（Closed as not planned）；鸿蒙适配由 OpenHarmony-SIG 社区分支承接，2026-01 成立 Flutter SIG，3.41 鸿蒙版已发布、3.44 鸿蒙版预计 2026-09 | [flutter/flutter issue #150536](https://github.com/flutter/flutter/issues/150536)、[OpenHarmony-SIG / flutter_flutter](https://gitcode.com/openharmony-sig/flutter_flutter) |
外部来源清单。凡本文档中标注为"推论"的内容（如"F6 需要改造页面"、"加密插件与离线打包互斥"），均由上表中的事实推出，推理过程已在正文中写明。
@@ -663,7 +725,57 @@ UI 实现 20-25% ↓ 略省 ← 它的优势只作用在这一块
| **AAR** | 安卓的二进制打包格式。拿到 AAR 只能调用它，看不到也改不了里面的代码 |
| **App Extension（扩展）** | App 主体之外的附加组件，比如桌面小组件、分享面板、语音助手指令 |
| **符号化** | 崩溃报告里原本是一串看不懂的地址，还原成"哪个文件哪一行出错"的过程 |
| **热更新** | 不经应用商店审核，直接把新版代码下发到用户手机上 |
| **VDOM / 蒸汽（Vapor）模式** | uni-app x 的两种渲染模式。后者更新，性能更好，但配套的原生 SDK 尚未发版 |
| **MCP** | 一种标准协议，让 AI 编程助手能读懂某个框架的专有知识 |
| **Agent Skills** | 打包好的一组指令，教 AI 编程助手按某个框架的最佳实践干活 |
术语对照表。
---
## 附录 C 对 DCloud 官方对比材料的核验
DCloud 官方文档里有一页专门做 uni-app x 与 Flutter 的对比（「跨平台技术选型」）。**客户方技术人员检索"uni-app x vs Flutter"时大概率会看到这一页，所以我们把它读完并逐条核验了。** 结果如下——凡属实的直接认，凡没有数据支撑的说明它没有数据支撑，不做反向解读。
| 对比页的论点 | 核验结果 | 对本项目的意义 |
| --- | --- | --- |
| Flutter 安装包更大（实测 **18M 对 8.5M**） | **属实。** 自绘引擎必须打进包里，这是路线本身的代价 | 差约 10MB。门店内部业务 App，企业分发、无包体 KPI，不构成决策变量。且 uni-app x 走离线 / 嵌入路径同样有增量：iOS 约 8.7 MB、Android arm64-v8a 约 8.1 MB（DCloud 官方数字） |
| Flutter 内存占用更高（实测 **约 138MB 对 103MB**） | **属实** | 差约 35MB。门店配发的作业终端，现代机型上不产生可感知影响 |
| 「dart与原生API的通信…通信损耗非常明显」 | **未附实测数据与测试条件**，属定性表述 | 本项目的原生调用（扫码、拍照、上传）是低频、事件驱动的，不在渲染热路径；且接口由 Pigeon 生成三端强类型代码，不是字符串方法名。**本项目真正吃紧的通信链路是嵌 F6 那条——恰恰是 uni-app x 更弱的地方，见 3.1** |
| 「原生渲染和flutter自渲染并存时，问题很多」 | **未附实测数据**，但原生与自绘混排确是业界已知难点，这个方向上的提醒是成立的 | 本项目唯一的混排点是 WebView，用的是 Flutter 官方团队维护的一等公民插件，不是第三方封装。混排面积小且可控 |
| 「dart生态…以及比较难用的嵌套写法」 | 生态一项与第 4 章的公开数据相反（公开提交量、大厂落地规模均为 Flutter 占优）；**嵌套写法这条是真实体验问题**，深层嵌套的可读性确实不如模板语法 | 嵌套写法属编码习惯与工具问题：IDE 的结构提示、格式化与重构快捷键已覆盖，团队上手一两周即适应。**这一条我们不辩解，但它不影响能力上限** |
| 「热更新」 | **属实，且是对方一条真优势** | 单独说明，见下 |
对 DCloud 官方对比页各项论点的核验。
> **这份对比里给出实测数字的只有包体和内存两项，差距分别约 10MB 和 35MB；其余论点均为定性表述，未附测试条件或数据。**
>
> 我们认为这个事实本身值得客户方注意：**一家厂商在自己撰写的公开对比材料里，通常会把手上最有力的证据放上来——而这份材料里最有力的证据是安装包大小。** 这从侧面说明了两条路线的差距集中在哪些维度上：不在能力，在体积。
**同一页里，DCloud 也标注了这份对比的边界。我们认为这些自陈是客观的，一并列出：**
- 该测试**仅覆盖 VDOM 模式**，蒸汽（Vapor）模式不在对比范围内
- 官方原文提到其**「需求墙尚有未完成项」**
- Android 侧页面元素过多时仍会拖慢性能，复杂场景需改用 draw 方式实现
- 引入常用库之后，uni-app x 的包体同样会增长
**这几条说明上面那两个数字是有前提的**：它们是特定模式、特定测试工程下的结果，不宜直接外推到一个有十几项原生能力、要嵌第三方网页的真实业务 App 上。
### 补充一条对方的真实优势：热更新
**uni-app 支持热更新（wgt 方式），Flutter 不支持。这一条我们主动列出，不等对方提。**
对很多项目来说这是实打实的价值——线上出了问题不用等应用商店审核，直接下发修复。需要一并说明的是：
- 苹果的审核政策对"绕过商店下发可执行逻辑"长期处于灰色地带，规模化使用存在被下架的风险敞口
- 本项目的发版链路已经定了：**安卓走托管的 OTA 分发页，iOS 走 TestFlight + App Store**，都是正规链路
- 企业侧的安全与合规评审，通常也不倾向于接受"可以绕开商店直接下发代码"这种能力
**所以准确的说法是：这条优势客观存在，但在本项目已确定的发版模式下用不上。** 如果将来发版策略改变、热更新变成硬需求，这一条应当重新计入。
### 这一节的用途
写这一节不是为了驳倒谁，是为了让评审会上不出现"我在网上看到 DCloud 说 Flutter 怎样怎样"这种悬空的讨论。**对方的每一条论点，上面都有一个明确的答复：属实的认下来并说明影响，没有数据的指出它没有数据，对我们不利的（包体、内存、热更新、鸿蒙）主动列出。**
结论不因此改变——**这些差异全部落在本项目不敏感的维度上，而第 3 章那几条落在敏感维度上的差异，方向是相反的。**