这些年移动端的跨平台方案我前前后后试过不少从早期的 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 配置。不同的平台需要配置不同的 KeyAndroid 和鸿蒙的 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 CompleterMapController(); _loadNearbyMarkets(); } Widget buildMap() { return MapWidget( initialCenter: _currentPosition, initialZoom: 14, markers: _marketMarkers, onTapMarker: (markerId) { final market _markets.firstWhere((m) m.id markerId); _showMarketBriefCard(market); }, ); }定位模块的核心逻辑Futurevoid _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); FutureMapString, 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; Futurevoid _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 做鸿蒙应用希望这篇分享能帮你避开我踩过的坑。