半岛森林先交代一下背景。去年年底我开始做「GreenSort 绿分家」这个智能垃圾分类应用，定位很简单：让用户举起手机拍一下、或者输入一个物品名字，立刻知道它属于可回收、有害、厨余还是其他垃圾。项目从立项到第一个可体验版本，前后花了三个月，其中最核心的是「快速分类」模块——也就是从拍照/输入到出分类结果这一段链路。
这篇文章我把快速分类模块从选型、实现到优化的完整过程写出来。包括为什么在 HarmonyOS 6.0 上仍然选 Flutter 做跨端框架、本地方案怎么设计、踩过的那些 Flutter 工程化坑、以及最后是怎么把一次分类耗时从 5 秒压到 1.5 秒的。对 Flutter 开发、鸿蒙应用适配、轻量 AI 应用落地感兴趣的读者，这篇文章应该能给你一些可以直接用的经验。
1. 为什么「快速分类」值得作为独立模块优先做
「GreenSort 绿分家」整个 App 有垃圾分类识别、投放点地图、环保知识科普、积分任务这些功能。但我在产品设计之初就定了一条原则：快速分类模块必须最先做、做最深。理由有三层。
1.1 产品侧：用户打开 App 的第一诉求就是“这个东西扔哪”
垃圾分类 App 不是社交产品，用户不会每天刷。真实场景是：手里拎着一袋垃圾站在垃圾桶前，不确定某个东西该扔哪个桶，这时候掏出手机，期望 3 秒内得到答案。地图、积分、科普都是低频功能，唯独“这是什么垃圾”是最高频、最刚需的入口。
所以我要求快速分类模块必须做到“单次操作不超过三步”：打开 App，拍照或输入，获得结果。任何多余注册、跳转、广告都会让用户流失。
1.2 技术侧：分类模块是整个 AI 链路的试金石
垃圾分类识别看起来是个小功能，但它牵扯到完整的移动端 AI 链路：摄像头调用、图像预处理、模型推理、结果后处理、离线缓存、性能优化。做透这个模块，等于把后续所有智能功能的骨架都搭好了。
比如模型推理部分，我们直接在 HarmonyOS 设备上通过 Flutter 插件通道调用本地 TFLite 模型。这个链路涉及 Dart 层、原生层（Java/Kotlin 或 ArkTS）、C++ 层（JNI/Napi）三层协作。一旦跑通，后续加任何 AI 能力都是复制粘贴这套架构。
1.3 架构侧：模块边界的划分决定了团队协作效率
快速分类模块最终被拆成四个子模块：
- UI 层：相机预览页、结果展示页、搜索页，全部用 Flutter 编写
- 服务层：分类请求的统一入口，负责调用图像识别或文本搜索
- 推理层：封装 TFLite 模型加载、输入预处理、输出解析，通过 MethodChannel 暴露给 Dart
- 数据层：本地垃圾类别数据库、用户分类历史缓存
边界划清楚的直接好处是：UI 层可以并行开发，推理层可以单独用原生工程调试，数据层可以脱离 UI 做单元测试。后续如果要把推理层换成端侧 NPU 方案，只需要改推理层内部实现，对 UI 层完全透明。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技术选型：Flutter 和 HarmonyOS 6.0 是怎么走到一起的
很多人看到“Flutter + HarmonyOS”会觉得矛盾：Flutter 不是跨平台吗？HarmonyOS 不是要推 ArkTS 吗？这里我把决策过程说清楚。
2.1 为什么不是纯 ArkTS，也不是纯原生 Flutter
HarmonyOS 6.0 原生开发首推 ArkTS + ArkUI，这个方向本身没问题。但 GreenSort 的定位是跨 Android、HarmonyOS、iOS 三端，而且团队只有两个人，纯 ArkTS 意味着 Android 和 iOS 端要另外维护两套代码，人力撑不住。
Flutter 的优势恰恰在这：一套 Dart 代码覆盖三端，UI 一致性高，动画性能好，生态成熟度高。HarmonyOS 侧通过社区适配层可以跑 Flutter 引擎，虽然不完全等同于官方支持，但实际体验已经可以达到生产可用水平。
2.2 鸿蒙 6.0 在项目里承担的角色
HarmonyOS 6.0 这个版本有几个值得注意的特性：更强的端侧算力调度、更严格的权限管控、新的应用签名机制。对 GreenSort 来说，它提供了两大价值：
第一，端侧 AI 加速能力。 鸿蒙设备对端侧模型的调度做了优化，NPU 加速路径比 Android 同硬件更顺畅。虽然 Flutter 跨端层暂时用不上 NPU，但后续如果做实时识别，原生侧可以借助这个能力。
第二，统一的应用分发入口。 一个 H