企业官网建设流程全解析

这些年移动端的跨平台方案我前前后后试过不少，从早期的 WebView 套壳，到 React Native，再到现在的 Flutter，每个方案都有自己的脾气。这次要聊的项目，是用 Flutter 框架做的一个专门针对鸿蒙生态的“附近文创市集查询”应用。这个选题挺有意思，一是它踩中了当下年轻人逛市集、淘文创的热点，二是它把 Flutter 跨平台能力和鸿蒙系统的适配问题摆在了一起，很能说明问题。这篇文章我会把这个项目从立项到实现的关键环节完整拆开，讲清楚每一步为什么这么做，以及我实际踩过的坑和填坑的方法。

这个应用的核心功能并不复杂：打开应用，定位到你当前的位置，以你为中心搜索周边正在举办或常驻的文创市集，展示市集的基础信息、开放时间、特色摊位和用户评价。但恰恰是这些看似简单的功能，放在鸿蒙设备上做 Flutter 适配时，会牵扯出很多平时在 Android 和 iOS 上根本不会注意到的细节。适合正在学习 Flutter 跨平台开发、对鸿蒙原生适配好奇、或者想做一个同类型 LBS 查询应用的开发者参考。

1. 项目背景与整体设计思路

1.1 为什么选 Flutter 做鸿蒙跨平台开发

鸿蒙生态这几年的发展速度确实快，设备数量上来了，应用需求也跟着增加。但对于个人开发者或者小团队来说，为鸿蒙单独维护一套原生代码的成本很高，尤其是你手上已经有一套 Flutter 代码库的时候。Flutter 的跨平台能力在 Android 和 iOS 上已经被验证过很多次，UI 一致性好，渲染性能接近原生。而鸿蒙这边，社区陆续出现了针对 Flutter 引擎的适配方案，让 Flutter 应用能够在鸿蒙设备上以接近原生的方式运行。

我的选择逻辑很简单：一套 Dart 代码，同时覆盖 Android、iOS、鸿蒙三个平台。核心业务逻辑全部复用，只是针对不同平台的系统能力做少量适配。这样一来，后期维护成本大幅降低，新增功能也只需要写一遍。实际体验下来，Flutter 在鸿蒙上的渲染性能整体表现不错，帧率稳定，动画流畅度也不输原生。

1.2 文创市集查询的场景痛点

为什么专门做“文创市集查询”而不是做个通用的“周边商铺查询”？因为这两种产品的用户心智和使用场景完全不同。通用商铺查询，用户的目标非常明确，比如找银行、找药店，搜完就走。但文创市集不一样，它是一种“逛”的体验，用户打开应用的时候往往没有明确目标，就是想看看附近有什么好玩好逛的，周末可以去哪里打发时间。

这意味着产品设计上需要突出的内容是：市集的主题风格、特色摊位亮点、现场照片、开放时间、交通便利程度。市集是流动性的，很多市集只在周末或者特定节假日举办，这和固定商铺的信息维护逻辑也有区别。所以应用需要有“正在举办”和“即将举办”的标签区分，甚至要支持市集主办方发布延期或取消的公告。这个场景比单纯的商铺查询更有温度，需要更多的内容运营支撑。

1.3 技术方案选型与架构拆解

先说说整体技术架构。这个项目采用标准的 Flutter 三层架构：

• UI 层：负责页面渲染和用户交互，包括地图展示页、市集列表页、市集详情页、个人中心
• 业务层：负责市集数据的获取、筛选、排序，以及用户位置信息和收藏状态的管理
• 数据层：负责网络请求、本地缓存、数据库存储

状态管理我选的是 Provider，配合 ChangeNotifier。原因很务实：项目规模不算大，Provider 足够用，而且它的学习成本低，团队成员上手快。如果是用 Bloc 或者 Riverpod，功能上当然更强，但对这个体量的项目来说有点杀鸡用牛刀。

地图选型是这个项目里比较关键的一个决策点。鸿蒙系统本身有自己的地图服务能力，但 Flutter 插件生态里对鸿蒙的适配还处于早期阶段。我最终采用了某主流地图 SDK 的 Flutter 插件，因为它同时提供了 Android、iOS 和鸿蒙的支持，接口风格统一，可以减少很多适配工作量。地图上需要展示市集的位置标记，支持点击标记弹出市集简卡，然后可以跳转到详情页。

2. 核心功能拆解与数据模型设计

2.1 附近市集检索的数据模型

市集数据是整个应用的核心资产，数据模型设计得好不好，直接影响后续的筛选、排序和展示逻辑。我定义了一个 MarketPlace 类，包含以下核心字段：

• id：市集唯一标识
• name：市集名称
• coverImageUrl：封面图地址
• description：市集简介
• latitude / longitude：市集坐标
• address：详细地址
• startTime / endTime：本次开放时间段
• status：状态枚举，分别是举办中、即将开始、已结束
• tags：标签列表，比如手作、美食、复古、植物、插画等
• rating：综合评分
• featuredBooths：特色摊位简介列表

这里需要特别说明的是经纬度字段。市集的位置不像固定店铺那样一成不变，同一场市集可能在不同的周末去不同的场地举办。所以每期活动都应该有自己独立的坐标信息，而不是把坐标绑定在市集本身。我后台的数据结构把“市集主题活动”作为数据粒度，同一个市集品牌可以有多个活动场次，每个场次有自己的时间和坐标。这样用户在搜索时，看到的是具体的“本周这场活动在哪里办”，而不是一个模糊的市集品牌信息。

2.2 附近检索的距离计算与排序逻辑

用户打开应用后的核心操作就是“搜附近”。这个功能有两个关键技术点：一是如何计算用户与市集之间的距离，二是如何按距离进行排序。

距离计算我用的是 Haversine 公式，这是球面两点间距离计算的标准方法。考虑到市集查询的场景里，用户和市集之间的距离通常在几十公里以内，直接使用 Haversine 公式在精度和性能之间能够取得很好的平衡。核心代码如下：

import 'dart:math'; double calculateDistance(double lat1, double lon1, double lat2, double lon2) { const double earthRadius = 6371; // 地球半径，单位公里 final double dLat = _toRadians(lat2 - lat1); final double dLon = _toRadians(lon2 - lon1); final double a = sin(dLat / 2) * sin(dLat / 2) + cos(_toRadians(lat1)) * cos(_toRadians(lat2)) * sin(dLon / 2) * sin(dLon / 2); final double c = 2 * atan2(sqrt(a), sqrt(1 - a)); return earthRadius * c; // 返回公里数 } double _toRadians(double degree) => degree * pi / 180;

排序逻辑上，默认按距离从近到远。但这里我加了一个小的产品优化：状态为“举办中”的市集排在所有结果的最前面，因为用户当前立刻能去逛的市集优先级最高；其次是“即将开始”；“已结束”的直接过滤掉，不进入列表。这样排序规则就是：状态优先，其次距离。看起来简单，但实际体验比单纯按距离排序要好很多，因为用户不是来找最近的，是来找“现在能去的最近的”。

2.3 市集状态的时间判断逻辑

市集状态不是后台直接下发一个写死的字符串，而是根据当前时间动态计算。因为市集的开放时间是随时变化的，如果在服务端写死状态，可能会出现用户端展示与实际不符的情况。我的做法是后台只下发 startTime 和 endTime，由客户端根据当前时间实时判断状态。

MarketStatus getCurrentStatus(DateTime currentTime) { if (currentTime.isBefore(startTime)) { return MarketStatus.upcoming; } else if (currentTime.isAfter(endTime)) { return MarketStatus.ended; } else { return MarketStatus.ongoing; } }

这种设计的好处是，客户端展示的状态始终是最新的。哪怕是用户一直挂着应用不刷新，跨过了市集的开始时间节点，端上也能自动切换状态。当然，前提是拿到准确的服务器时间，而不是依赖用户设备时间。用户如果自己改了系统时间，会导致状态判断异常，所以实践中我都是通过接口返回的时间戳来校准。

3. 鸿蒙适配的关键环节与实操记录

3.1 Flutter 引擎在鸿蒙上的集成方式

鸿蒙系统对 Flutter 的支持，目前是通过社区维护的 Flutter 引擎适配层实现的。简单理解，鸿蒙应用本身是使用 ArkTS 语言开发的，要跑 Flutter 应用，需要在一个鸿蒙原生的页面里嵌入 Flutter 的渲染容器。这个容器的能力类似 Android 里的 FlutterView，或者是 iOS 里的 FlutterViewController。

具体集成的时候，需要在鸿蒙工程里引入 Flutter 引擎的依赖库，然后通过一个容器组件装载 Flutter 模块。实际操作中最需要注意的是，Flutter 模块的路由管理和鸿蒙原生页面的路由管理需要打通。我在项目里做了一个统一的路由分发器，鸿蒙原生页面需要跳转到 Flutter 页面时，通过一个全局的路由名称来触发，避免两端路由逻辑各写一套，导致后期维护困难。

3.2 定位权限的鸿蒙适配

定位功能是这个应用的基础能力，鸿蒙的定位服务有自己的一套权限体系，和 Android 的权限模型不完全一样。

鸿蒙定位权限分为两种：粗略定位和精确定位。如果应用只需要知道用户在哪个城市，粗略定位就够了，但附近市集的查询要求在几百米的范围内做计算，所以必须申请精确定位权限。

在鸿蒙工程配置文件里，需要声明以下权限：

{ "name": "ohos.permission.LOCATION" }

同时需要在代码中动态申请。这里要特别提一个容易踩的坑：鸿蒙系统对于后台定位有严格的管控，如果应用退到后台继续获取位置，系统会弹出提醒甚至直接切断定位回调。所以我采取的策略是：应用生命周期处于前台时持续监听位置变化，一旦退到后台就立即停止定位更新，只保留最后一次位置信息。这样既满足了功能需求，也规避了系统管控风险。

3.3 地图 SDK 的鸿蒙适配细节

地图 SDK 在鸿蒙上的适配是另一个大问题。我用的地图 SDK 在鸿蒙上提供了独立的适配包，但集成方式和 Android 版本有明显差异。

首先，需要在鸿蒙工程中注册 SDK 的初始化代码。初始化时机必须放在应用启动阶段的早期，最好是应用入口模块初始化时就执行。如果初始化太晚，可能出现地图区域白屏或者无法加载的情况。

其次，地图 SDK 的 API Key 配置。不同的平台需要配置不同的 Key，Android 和鸿蒙的 Key 不能混用。我在这里踩过坑，一开始以为 Key 是通用的，结果在鸿蒙设备上地图始终显示空白，排查了很久才发现是 Key 不匹配的问题。配置的时候记得检查一下，鸿蒙工程里配置的 Key 一定要是和鸿蒙包名绑定的那个。

另外，地图上标记点的自定义样式也需要注意。Flutter 端自定义 Marker 的 Widget 渲染，在鸿蒙上可能会出现部分样式失真。我测试下来，简单的圆形、方形标记没有问题，但如果用复杂的自定义 Widget 做 Marker，偶尔会碰到渲染卡顿或者掉帧的情况。最终的折中方案是使用地图 SDK 自带的标记图标能力，配合不同的颜色和图标来区分市集的线上状态，而不是在 Flutter 端做完全自定义的 Marker Widget。

3.4 鸿蒙打包发布与签名配置

鸿蒙应用打包和 Android 打包逻辑类似，但细节不太一样。鸿蒙应用使用的签名文件格式是 .p12，证书是 .cer，配置文件是 .p7b，这三者缺一不可。而且签名配置文件里包含了应用的包名、签名证书指纹等信息，一旦生成后如果包名改了，签名文件就必须重新生成。

我在发布测试版本的时候遇到过一次失败：装到鸿蒙设备上提示签名不一致，应用无法安装。排查后发现是因为之前为一个旧包名生成的签名配置，后来改了包名没有重新生成。解决方法是登录鸿蒙应用市场开发者后台，用新的包名重新生成签名配置文件，替换到工程里，清理缓存后重新打包。

这里还要提醒一下，鸿蒙应用市场对上架应用的审核要求比安卓市场更严格一些，尤其是涉及定位权限的应用，需要在隐私政策里明确说明收集定位信息的目的、方式和范围。我的应用在上架时被驳回过一次，就是因为隐私政策里对定位信息的说明不够详细。修改了隐私政策，补充了“用于获取用户当前位置，检索周边文创市集信息”的描述后，才顺利通过。

4. 实操过程与核心环节实现

4.1 项目初始化和依赖配置

创建一个新的 Flutter 项目，需要支持鸿蒙平台时，我建议直接用命令行创建基本工程，然后手动添加鸿蒙适配目录，而不是依赖 IDE 的向导。因为目前的 Flutter 官方工具链还没有把鸿蒙作为一等平台直接支持，IDE 向导生成的工程可能缺鸿蒙适配配置。

初始化核心命令：

flutter create market_app

创建完成后，在项目根目录下手动添加鸿蒙适配层目录，并参考 Flutter 官方鸿蒙适配仓库的文档配置依赖。需要修改的配置文件包括：

• 鸿蒙工程的 build-profile.json5，配置应用包名和签名信息
• 鸿蒙工程的 module.json5，声明应用权限和页面路由
• Flutter 工程的 pubspec.yaml，添加地图、定位、状态管理、网络请求等依赖

依赖库版本的选择上建议保守一些，不要一上来就追最新版本。鸿蒙适配的插件往往滞后于 Flutter 官方的发版节奏，有时候 Flutter 升级了，插件还没有适配鸿蒙，就会导致编译失败。我的做法是：Flutter 版本选定一个稳定版本后，所有依赖都选与之兼容的版本范围，并且每次升级 Flutter 版本前，先确认核心插件已经支持鸿蒙。

4.2 地图与定位模块的代码实现

地图页是应用的门面，用户打开应用第一眼看到的应该是一张以自己位置为中心的地图，上面散布着周边的市集标记。我推荐的结构是顶部一个搜索栏、中间是地图、底部弹出半屏列表。

地图初始化的关键代码：

@override void initState() { super.initState(); _mapController = Completer<MapController>(); _loadNearbyMarkets(); } Widget buildMap() { return MapWidget( initialCenter: _currentPosition, initialZoom: 14, markers: _marketMarkers, onTapMarker: (markerId) { final market = _markets.firstWhere((m) => m.id == markerId); _showMarketBriefCard(market); }, ); }

定位模块的核心逻辑：

Future<void> _updateCurrentPosition() async { try { final position = await _locationService.getCurrentPosition(); setState(() { _currentPosition = position; }); _loadNearbyMarkets(); } catch (e) { _showLocationErrorDialog(); } }

这里有一个值得注意的细节：首次进入应用时，定位过程可能需要几秒钟，期间地图位置是空的，用户会看到一片灰色区域。我的做法是先在页面中央显示一个加载动画，同时把默认中心点设置为所在城市的中心坐标，等定位成功后再平滑移动到用户当前位置。这样用户感知是“应用正在定位”，而不是“应用卡了”。

4.3 市集列表与详情页面的 UI 实现

市集列表页我采用了“卡片式 + 图片流”的布局风格。文创市集是视觉导向的产品，用户对图片的兴趣远大于文字描述，所以卡片上图片占比要大，文字信息要精简。每张卡片包含封面图、市集名称、开放状态标签、距离信息和开放时间，核心信息一目了然。

列表卡片的大小和图宽高比需要仔细控制。我测试下来，整页宽度减去边距后，卡片宽度约 350 逻辑像素，图片高度约为宽度的 0.75 倍，也就是 262 逻辑像素左右，这个比例视觉效果最舒适。图片上下不留白，裁切模式用 BoxFit.cover，保证所有图片以统一的视觉规格展示。

详情页的信息结构从上到下依次是：大图轮播、市集名称和状态标签、核心信息栏（时间、地址、距离）、主题标签、特色摊位列表、简介、地图位置、用户评价。整个页面的滚动体验要平滑，图片轮播区域的滑动流畅度直接决定了用户对这个页面品质感的第一印象。如果图片加载太慢，可以用低分辨率模糊占位图过渡，图片加载完成后渐变替换，这个细节能明显提升体验。

4.4 数据加载策略与缓存优化

文创市集的图片一般比较多，而且很多是主办方上传的高清大图，如果不做处理，用户逛列表页时流量和内存消耗都会很大。

我的数据加载分了三级：

• 列表页：加载压缩过的中尺寸图片，单张不超过 100KB
• 详情页首屏：加载大尺寸图片，但首屏最多只加载 3 张
• 详情页非首屏：滑动到对应区域时才触发加载

这里推荐用 Flutter 自带的 Image.network 配合缓存宽高设置，或者使用第三方图片缓存库。我在项目中是自建了一个轻量级缓存层，基于内存缓存加本地磁盘缓存两级结构。内存缓存存放最近浏览的 50 张图片的位图数据，磁盘缓存存放最近 3 天浏览过的图片文件。这样用户反复打开同一个市集详情页，图片基本能做到秒开。

网络请求层面也做了缓存策略：

class ApiCache { static const Duration cacheValidDuration = Duration(minutes: 5); Future<Map<String, dynamic>> fetchMarkets(double lat, double lon) async { final cacheKey = 'markets_${lat.toStringAsFixed(3)}_${lon.toStringAsFixed(3)}'; // 先读缓存，缓存超时再请求网络 } }

缓存的有效期设为 5 分钟，因为这个场景下市集数据虽然变化不频繁，但用户可能移动位置，如果缓存时间太长，用户走了一段路之后看到的结果可能还停留在旧位置。经纬度保留三位小数，意味着缓存粒度大约是百米级别，既能保证缓存命中率，又不会因为坐标精度过高导致缓存频繁失效。

5. 常见问题与排查技巧实录

5.1 鸿蒙设备上地图白屏

这个问题的排查过程记忆深刻。现象是：应用在 Android 设备上运行正常，但安装到鸿蒙设备上之后，地图区域显示一片空白，没有任何报错信息，应用也不崩溃。

排查步骤：

• 检查地图 SDK 初始化状态：在初始化接口前后加了日志输出，确认初始化接口有被调用，没有抛异常
• 检查网络请求是否正常：地图瓦片加载需要网络，确认网络权限已声明，且设备网络正常
• 检查 API Key 是否匹配：对比了鸿蒙工程和应用市场后台的签名信息，最终发现真的是 Key 不匹配

这里的问题在于，我之前只用 Android 包名申请过 API Key，鸿蒙的包名和 Android 的包名虽然可以相同，但应用市场后台的 Key 管理是区分平台的，需要单独为鸿蒙平台申请新 Key。

5.2 Flutter 页面在鸿蒙上偶现卡顿

部分用户反馈，在鸿蒙设备上使用应用时，列表滑动的流畅度不如 Android 设备。这个问题不容易稳定复现，只能通过日志分析和帧率监控来定位。

我最终发现的原因和图片有关。列表页在滑动时，新的卡片进入可视区域会触发图片加载，如果图片加载是同步发起大量网络请求，会导致 UI 线程短暂的阻塞。优化方式是降低图片并发加载数量，同一时间最多发起 4 个图片下载请求，同时开启了图片的预解码功能，让图片在进入可视区域之前就开始解码。

这个优化在 Android 上感知不明显，但在鸿蒙上帧率有明显提升。我后来总结，鸿蒙的 Flutter 渲染在并发任务处理上比 Android 更敏感一些，对资源竞争更敏感，所以需要更克制地使用并发资源。

5.3 定位权限弹窗不出现

另一个用户在鸿蒙设备上遇到的问题是，首次打开应用时，定位权限弹窗没有出现，直接就进入了地图页面，地图上也没有用户当前位置。

排查后发现，有两层原因：第一，应用安装时，鸿蒙系统可能默认了权限策略，没有弹出权限询问窗口，而是直接拒绝了权限申请。第二，Flutter 端申请权限时，需要等待页面渲染完成后再发起，如果在页面还在加载时就申请权限，鸿蒙系统会认为请求时机不合法，直接忽略。

解决方案是在定位权限申请前，先主动检查权限状态，如果已经被拒绝，就在页面上展示一个引导卡片，提示用户手动前往设置页面开启定位权限。不要反复自动弹窗申请，鸿蒙系统对于频繁申请权限的行为非常敏感，容易被系统判定为恶意行为。

6. 性能优化与体验打磨

6.1 应用启动速度优化

启动速度直接影响用户的留存。这个项目的启动流程包括：Flutter 引擎初始化、地图 SDK 初始化、定位服务初始化、首页数据加载。如果这些步骤全部完成才展示首页，启动时间会非常难堪。

我的优化思路是分阶段展示：

• 第一阶段：Flutter 引擎启动后，立刻渲染一个静态的欢迎页，给用户即时的反馈
• 第二阶段：后台并行初始化地图和定位模块，欢迎页同时展示加载进度动画
• 第三阶段：定位完成后，切到地图页，开始加载市集数据

整体优化后，从点击应用图标到看到地图，大约需要 2 到 3 秒，其中定位耗时占比最大。考虑到定位本身的物理特性，这个速度已经可以接受。

6.2 市集列表的懒加载和分页优化

市集数据量如果很大，一次性加载全量数据既浪费流量也拖慢渲染。这里采用了 ListView.builder 配合分页加载模式。

分页逻辑：

static const int pageSize = 20; Future<void> _loadMoreMarkets() async { if (_isLoadingMore || _hasReachedMax) return; _isLoadingMore = true; final page = _currentPage + 1; final result = await _api.fetchMarkets( page: page, pageSize: pageSize, lat: _currentPosition.latitude, lon: _currentPosition.longitude, ); setState(() { _markets.addAll(result.list); _currentPage = page; _hasReachedMax = result.list.length < pageSize; }); _isLoadingMore = false; }

每次加载 20 条，滚动到底部自动触发下一次加载。这里要特别注意防重复请求：当 _isLoadingMore 为 true 时，不再触发新的加载。如果用户滚动速度快，可能一帧内连续触发多次加载回调，没有这个保护机制就会出现请求重复、数据错乱的问题。

6.3 低内存设备的图片降级策略

部分低端鸿蒙设备内存只有 3GB 左右，高分辨率图片可能在解码时就导致内存溢出。我加了图片尺寸的硬件限制：解码时强制限制最大边长为 1080 像素，超过的图片先压缩再显示。与此同时，系统内存紧张时，Flutter 会自动触发 ImageCache 的清理，这里也要主动监听 AppLifecycleState，在应用进入后台时主动清理内存缓存，降低系统回收应用的风险。

6.4 市集数据的本地离线缓存

为了让用户在信号不好的地方也能查看已经浏览过的市集信息，我做了一层离线缓存。网络请求成功后，把市集的摘要信息以 JSON 格式写入本地数据库，限制保存最近 200 条记录。用户再次进入应用且网络不可用时，可以切换到“离线模式”，查看之前缓存过的市集列表和详情摘要。

这个功能看起来不起眼，实际上对用户体验的提升很大。文创市集的场景经常发生在创意园区、旧厂房、户外广场这类位置，有些地方网络信号确实不稳定。离线模式下虽然不能更新实时状态，但至少能看到之前缓存的市集基本信息，用户可以决定要不要按照地址找过去。

7. 关于鸿蒙生态 Flutter 适配的思考

7.1 跨平台方案在鸿蒙生态的进化

鸿蒙系统目前的发展势头很强，越来越多的设备加入了鸿蒙生态。对开发者来说，这是一个增量市场，但也是一个需要投入适配成本的市场。Flutter 在鸿蒙上的适配方案从无到有、从粗糙到相对稳定，这个过程中的迭代速度很快，社区贡献者的活跃度也越来越高。但不可否认，鸿蒙上的 Flutter 仍然处于追赶阶段，部分能力还做不到和 Android 完全对齐。

在我开发这个项目时，最大的感受是：跨平台的本质不是一套代码跑遍所有平台，而是业务逻辑的高度复用加上平台能力的灵活适配。真正让项目顺利推进的，是对鸿蒙平台特性的理解和尊重，而不是单纯依赖 Flutter 的跨平台魔法。每个平台都有自己的脾气和规则，理解这些差异，才能在适配时少踩坑。

7.2 新生态带来的机会与挑战

鸿蒙生态的快速成长带来了新的分发渠道和用户群体。对于文创市集这类带有明显本地属性的应用来说，能够触达更多本地用户是核心价值。鸿蒙应用市场对初创小而美应用的态度比较友好，审核流程相对清晰，应用的曝光机会也比在竞争激烈的安卓市场更大一些。

但挑战同样明显：鸿蒙设备的性能特性有自己的特点，部分中低端设备的图形渲染能力不如同价位的安卓设备，需要更注意性能和内存的优化。而且鸿蒙的调试工具链还在不断更新中，部分调试功能比成熟的 Android 开发工具链简陋，需要多依靠日志和内存分析工具来定位问题。

7.3 后期扩展方向

这个项目后续有很多可以扩展的方向。比如可以做市集主办方的入驻和管理功能，让主办方自主发布市集活动信息，减轻平台运营压力。也可以加入用户签到和打卡功能，配合市集的线下活动做联动。还可以尝试接入鸿蒙的原子化服务能力和卡片服务，让用户不需要打开应用，就能在桌面卡片上看到附近市集的实时信息。

从技术角度来说，后续还可以尝试把 Flutter 引擎在多端协同场景中发挥更大作用。鸿蒙生态强调多设备协同，手机、平板、手表之间的信息流转如果能在 Flutter 层做统一处理，对用户的吸引力会更强。当然这会涉及到更多平台底层的适配工作，需要持续投入和积累。

我在实际开发这个项目的过程中，最深的体会是：技术选型没有绝对的对错，关键是看项目自身的约束条件和发展阶段。Flutter 做鸿蒙开发，目前适合的是中小型应用、MVP 阶段的产品验证、以及对跨平台一致性要求高的产品。如果团队有足够的原生开发资源，追求极致的性能和体验，原生仍然是首选。但如果你和我一样，面临着资源有限但想覆盖更多平台的情况，那 Flutter 加鸿蒙适配这条路，是当前性价比比较高的选择。

这个应用的开发过程让我对跨平台开发有了新的理解。每个平台的适配不仅是技术问题，更是对平台生态理解的考验。做鸿蒙适配的时候，我不得不去了解鸿蒙的系统架构、权限模型和用户习惯，这些知识反过来也帮助我完善了应用在 Android 平台上的表现。以后再做类似项目时，我的建议是尽早把平台适配纳入整体技术方案，而不是等代码写完了再补适配。早适配、勤测试、多真机验证，这三点做到位，鸿蒙上的 Flutter 项目才能少走弯路。如果你准备用 Flutter 做鸿蒙应用，希望这篇分享能帮你避开我踩过的坑。