适合谁看

• 做过 Android / iOS Flutter 开发，第一次接触鸿蒙的人

• 已经把 Flutter 项目跑到 HarmonyOS 上，但不确定还缺什么的人

• 想把“普通跨平台项目”进一步做成“有鸿蒙特征的应用”的人

问题背景

很多人会问：

Flutter 不就是跨平台吗？那做鸿蒙和做 Android / iOS 版本，到底本质差在哪里？

这个问题之所以常见，是因为从页面开发角度看，差别确实没有想象中那么大：

• 一样写 Widget

• 一样写状态管理

• 一样写路由

• 一样写接口请求

如果只看这层，你很容易得出一个结论：

鸿蒙应用和普通 Flutter App 没什么本质区别，只是多了一个平台目标。

但只要你把视角从“页面开发”再往外拉一点，就会发现差别并不只在页面层，而是同时落在：

• 工程结构

• 系统能力

• 系统入口

• 产品表达

食界探味这个项目正好可以把这几层差别比较清楚地拆出来。

先说结论：差别不在“是不是 Flutter 写的”，而在“有没有接进鸿蒙系统层”

如果只用一句话概括，我会这样说：

鸿蒙应用和普通 Flutter App 的差别，不在于页面是不是 Flutter 写的，而在于它有没有把 HarmonyOS 的工程结构、系统能力、系统入口和系统语境真正接进来。

也就是说，一个 Flutter 项目即便已经能运行在 HarmonyOS 上，也不代表它已经完成了“鸿蒙应用化”。

它可能只是：

• 多了一个运行平台

• 多了一个构建目标

• 但还没有形成鸿蒙特有的系统能力与系统体验

1. 第一层差别：工程结构不同

这是最先能看到、也最容易被低估的一层。

普通 Flutter 项目通常重点关注的是：

• android/

• ios/

• lib/

而到了鸿蒙项目，至少会多出一整套 ohos/ 工程。

在食界探味里，差别首先就体现在这些位置：

• app/ohos/

• app/ohos/build-profile.json5

• app/ohos/entry/src/main/module.json5

• app/ohos/entry/src/main/ets/

为什么这不是“多一个目录”这么简单

因为这个 ohos/ 目录不是静态外壳，而是一个真正参与构建、签名、权限声明、Ability 配置和系统入口声明的工程层。

比如在 app/ohos/build-profile.json5 里，可以看到：

• runtimeOS: "HarmonyOS"

• targetSdkVersion: "6.1.0(23)"

• compatibleSdkVersion: "6.1.0(23)"

• 独立的 signing config

这说明鸿蒙不是简单的“运行一下 Flutter 引擎”，而是有一套完整的平台构建语义。

再看 app/ohos/entry/src/main/module.json5，里面能看到：

• EntryAbility

• extensionAbilities

• requestPermissions

• pages

• metadata

这一层在 Android / iOS Flutter 项目里并没有完全等价的组织方式。

所以第一层差别是：

普通 Flutter App 更像“跨平台页面工程”，鸿蒙应用则会多出一层明确的平台工程结构。

2. 第二层差别：系统能力的接入方式不同

这也是大多数 Flutter 开发者真正开始感到差异的地方。

在普通 Flutter 项目里，很多功能习惯上会这样获得：

• 先找 pub 包

• 能装就装

• 能调用就调用

但在 HarmonyOS 场景里，不是所有能力都能直接靠现成 Flutter 包解决。

食界探味现在已经比较明确地把这一点体现出来了。

Flutter 和鸿蒙原生之间的桥接，主要集中在：

• app/lib/core/platform/anti_peep_protection_channel.dart

• app/lib/core/platform/intent_navigation_channel.dart

• app/lib/core/platform/speech_recognition_channel.dart

• app/lib/core/platform/text_to_speech_channel.dart

这说明什么？

说明这些能力并不是普通 Flutter 层原生就有的，而是需要显式建立一个平台边界，把 HarmonyOS 的系统能力接进来。

食界探味里已经体现出来的几类差别

1. 语音识别

语音识别在普通 Flutter App 里，往往会先从通用插件思路去找方案。
但在鸿蒙里，项目直接通过 ArkTS 插件去接 CoreSpeechKit。

对应原生实现位置：

• app/ohos/entry/src/main/ets/plugins/SpeechRecognitionPlugin.ets

2. 文本转语音

文本转语音也不是停留在一个通用 Flutter 层抽象里，而是明确下沉到鸿蒙插件：

• app/ohos/entry/src/main/ets/plugins/TextToSpeechPlugin.ets

3. 防窥保护

这类能力更能说明差别。
在普通 Flutter App 里，你通常不会天然具备这种系统级能力接入。

但在鸿蒙里，项目可以通过：

• app/ohos/entry/src/main/ets/plugins/AntiPeepProtectionPlugin.ets

去连接 DeviceSecurityKit，再把状态回传到 Flutter 侧。

4. 意图导航

普通 Flutter App 更常见的是深链、路由跳转、应用内导航。
而在鸿蒙里，项目还接了系统入口级别的意图跳转：

• app/ohos/entry/src/main/ets/plugins/IntentNavigationPlugin.ets

这已经不是“普通页面能力”了，而是系统层参与页面调度。

所以第二层差别是：

普通 Flutter App 主要在应用内部完成能力组织，而鸿蒙应用往往需要显式连接系统能力层。

3. 第三层差别：系统入口形态不同

这是很多人最容易忽略的一层。

如果你的理解还停留在：

• 图标点开应用

• 进入首页

• 在页面里完成所有操作

那你做出来的项目很可能只是“能跑在鸿蒙上的 Flutter 应用”，还不太像“鸿蒙应用”。

食界探味里已经可以看到几种典型的鸿蒙入口形态。

1. 主入口 Ability

在 module.json5 里，主入口不是简单的“App 启动页”，而是通过 EntryAbility 来声明应用能力入口。

这说明应用和系统之间的关系，并不只是一个简单的启动动作。

2. Form 卡片入口

食界探味在：

• app/ohos/entry/src/main/ets/formability/DailyRecommendFormAbility.ets

• app/ohos/entry/src/main/ets/formability/RecommendData.ets

里定义了卡片相关能力。

这类入口和普通 Flutter App 最大的区别在于：

用户不一定先打开应用，再看内容；系统可以先把内容触达到桌面。

3. 意图直达入口

食界探味还在：

• app/ohos/entry/src/main/ets/entryability/InsightIntentExecutorImpl.ets

里处理系统意图执行逻辑。

这意味着它不仅仅有“打开应用”这一种路径，还可能有：

• 搜索直达

• 功能页直达

• 指定内容页直达

对普通 Flutter App 来说，这不是默认能力；但对鸿蒙应用来说，这种“被系统理解”和“被系统调起”的能力是很重要的一部分。

所以第三层差别是：

普通 Flutter App 更强调应用内部入口，鸿蒙应用更强调系统级入口和外部触达能力。

4. 第四层差别：产品语境不同

如果前面三层偏工程和能力，那么这一层更偏“产品怎么被定义”。

普通 Flutter App 常见的目标是：

• 多端一致

• 页面能复用

• 开发效率高

这些目标当然没有问题。
但到了鸿蒙语境下，项目通常还会多出一些新的要求，比如：

• 能否被系统理解

• 能否接入系统能力

• 能否体现系统场景协同

• 能否在系统入口中被触达

食界探味这个项目里，这一点体现得比较明显。

比如它接入这些能力，并不是为了堆功能，而是为了让产品更接近下面这种状态：

• 用户可以直接说出需求

• 系统可以帮助把应用能力暴露出来

• 推荐内容可以通过卡片触达

• 隐私相关页面可以接系统保护能力

这和普通 Flutter App 的“应用内部完成所有事”是不一样的。

所以第四层差别是：

普通 Flutter App 更多是应用视角，鸿蒙应用往往还要补上一层系统视角。

在食界探味里，这四层差别具体落在哪里

如果把上面这四层压缩到这个项目里，可以这样理解：

工程层

• app/ohos/

• build-profile.json5

• module.json5

平台能力层

• app/lib/core/platform/

• app/ohos/entry/src/main/ets/plugins/

系统入口层

• entryability/

• formability/

产品语境层

• docs/competition/prd.md

• AI 助手、语音输入、推荐触达等功能组织

这也是为什么这个项目适合拿来解释“鸿蒙应用”和“普通 Flutter App”的差别。
因为它不是只停留在其中一层，而是四层都能找到对应材料。

那什么才算真正完成了“鸿蒙化”

这件事不一定有绝对标准，但从工程角度看，我会至少看下面三件事：

1. 有没有鸿蒙工程层

也就是除了 lib/ 之外，是否真的存在：

• ohos/

• 构建配置

• 权限声明

• Ability 配置

2. 有没有系统能力桥接

也就是项目是否真的接入了 HarmonyOS 的能力，而不是只在页面层复用 Flutter UI。

3. 有没有系统入口与场景融入

也就是：

• 是否能被系统入口调起

• 是否有卡片或其他系统级触达

• 是否有与鸿蒙语境一致的能力组织方式

如果这三层都没有，那项目更像“运行在鸿蒙上的 Flutter App”；
如果这三层逐步补齐，它才更接近“鸿蒙应用”。

初学者最容易踩的几个坑

坑 1：把“能运行”误当成“完成鸿蒙适配”

能跑起来只是开始，不代表已经接入了系统能力和系统入口。

坑 2：只补工程，不补体验

有些项目已经有 ohos/ 目录了，但用户层完全感觉不到鸿蒙差异化能力，这时鸿蒙化其实还不完整。

坑 3：只接能力，不回到产品场景

如果你只是接了语音、接了卡片、接了意图，但没有回到产品流程里，它们仍然只是分散的能力点。

坑 4：把鸿蒙理解成“另一个 Android”

这会让很多系统入口和系统语境层面的差异被忽略掉。

可复用的判断模板

以后你看一个 Flutter 项目是否真正带有鸿蒙特征，可以先问这 4 个问题：

1. 它有没有完整的鸿蒙工程层

2. 它有没有接入 HarmonyOS 系统能力

3. 它有没有系统级入口或系统触达

4. 它的产品语境有没有体现鸿蒙系统协同思路

如果前两条有，但后两条没有，它更像“跑在鸿蒙上的 Flutter 项目”；
如果四条都有，它就更接近“真正完成鸿蒙化的 Flutter 应用”。

本篇总结

鸿蒙应用和普通 Flutter App 的差别，并不只是“多了一个平台目录”，也不只是“多接了几个插件”。

更关键的差别在于四层：

• 工程结构不同

• 系统能力接入方式不同

• 系统入口形态不同

• 产品语境不同

食界探味这个项目的价值就在于，它把这四层差别都比较具体地呈现出来了。
所以它既适合拿来做项目，也适合拿来做鸿蒙 Flutter 系列教程的拆解样本。