1. 项目背景与整体定位最近在折腾 Flutter 做鸿蒙跨平台适配顺手把一个记观影流水的小账本应用完整跑通了。这篇文章就把整个开发过程的思路、代码、踩坑经过都整理出来给想用 Flutter 在鸿蒙上做应用的朋友一个参考同时也聊聊跨端框架在适配新系统时那些绕不开的实际问题。先说清楚这是个什么项目。标题里的“观影记录账本”不是那种简单的电影收藏夹它做的是两件事结合一是记录你看了什么片名、观看时间、平台、评分、观后感二是记录看电影花了多少钱电影票、视频会员、周边消费。也就是把“观影行为”和“消费账本”合并成一个应用。项目名叫 film-keeper我平时习惯叫它“观影账本”。它的核心价值在于到月底能看到“我这个月看了 12 部电影花了 268 元平均评分 7.8”而不是只知道“我看了很多电影”。这个项目适合谁看分三类。第一类是已经熟悉 Flutter 基础、想尝试鸿蒙端适配的开发者重点看第 4 和第 5 章那是鸿蒙适配和环境问题最集中的地方。第二类是正在做跨平台应用选型的产品或技术负责人第 1、2 章的分析能帮你看清楚跨端框架在鸿蒙这种新平台上的真实成本和收益。第三类是纯粹想拿一个项目练手的学习者整个项目从状态管理到数据库再到图表统计都有麻雀虽小五脏俱全可以直接照着敲。再说说这个项目的规模。整个应用在 Android 上跑起来大概 4000 行 Dart 代码迁移到鸿蒙端以后新增的 ArkTS 桥接代码不超过 200 行。这个比例就是 Flutter 跨平台的意义所在——业务逻辑、UI、状态管理全部复用只有平台相关的能力比如获取设备信息、调用系统功能需要单独写桥接代码。当然这只是我这个项目的数字如果你的应用依赖大量原生插件那鸿蒙适配的工作量会成倍上涨这一点后面会详细分析。2. 为什么选 Flutter 做鸿蒙跨平台技术方案解析2.1 Flutter 的跨端原理与鸿蒙的契合点先弄清楚 Flutter 凭什么能跨平台。大多数人对 Flutter 的印象是“一套代码跑多端”但很少有人关注它为什么能做到这一点。Flutter 的核心在于它不自带原生控件而是用 Skia 图形引擎在画布上重新绘制所有 UI 组件。你可以把它理解成一部电影在每家影院都用同一套放映机、同一套胶片播放而不是让每家影院用自己的设备翻拍一次。Android 的按钮、iOS 的按钮、鸿蒙的按钮在 Flutter 世界里统统不存在存在的是 Flutter 自己画出来的“像按钮的东西”。这种做法带来的直接好处就是 UI 层的移植成本极低。鸿蒙系统作为新平台由于没有历史包袱对第三方应用的原生控件适配支持远不如 Android 成熟但这恰恰是 Flutter 发挥优势的地方——它根本不依赖原生控件。只要能把 Flutter 引擎编译到鸿蒙系统上能提供画布渲染和事件分发整个 UI 层就能跑起来。所以 Flutter 跨端到鸿蒙本质上是把“渲染引擎”编译到鸿蒙而不是把“控件库”移植到鸿蒙。另一个契合点是鸿蒙原生生态还不够丰富很多常用的第三方库在鸿蒙上要么没有要么维护不活跃。而 Flutter 生态库只要不依赖原生插件绝大多数能直接跑。比如我用的 fl_chart 图表库、intl 日期格式化、csv 导出库这些在鸿蒙端完全没有碰壁因为它们都是纯 Dart 实现。这事关一个选型原则如果决定用 Flutter 做鸿蒙应用优先选纯 Dart 实现的库少碰带有 Android/iOS 原生代码的插件因为那些插件在鸿蒙端大概率要重新写桥接。2.2 状态管理方案Provider 在小项目里的优势状态管理选型上我对比过 Provider、Riverpod 和 Bloc。Bloc 学习曲线陡峭模板代码多适合大团队大项目Riverpod 没有依赖注入容器调试体验好但概念多新手容易被绕晕Provider 是三者中最容易上手的代码量最少而且有 Flutter 官方团队背书。对于观影账本这种中小型项目Provider 是性价比最高的选择这也是为什么 Flutter 社区搜索量里“flutter provider 插件使用教程”一直居高不下。Provider 的核心原理其实很简单它底层用的是 Flutter 自带的 InheritedWidget在这个基础上封装了 ChangeNotifier。InheritedWidget 能让子树里的组件读取到父级共享的数据ChangeNotifier 能让数据发生变化时通知订阅者。Provider 把这两者结合起来就是“数据变了所有依赖这个数据的组件自动重建”。我用一个 MovieRecordModel 来管理所有观影记录它继承 ChangeNotifier内部维护一个 List 增删改之后调用 notifyListeners()界面上用 Consumer 或 context.watch 来订阅数据一变 UI 自动刷新。class MovieRecordModel extends ChangeNotifier { ListMovieRecord _records []; ListMovieRecord get records List.unmodifiable(_records); Futurevoid load() async { _records await DatabaseHelper.instance.getAllRecords(); notifyListeners(); } Futurevoid addRecord(MovieRecord record) async { await DatabaseHelper.instance.insertRecord(record); _records.insert(0, record); notifyListeners(); } Futurevoid updateRecord(MovieRecord record) async { await DatabaseHelper.instance.updateRecord(record); final index _records.indexWhere((r) r.id record.id); if (index ! -1) { _records[index] record; notifyListeners(); } } Futurevoid deleteRecord(int id) async { await DatabaseHelper.instance.deleteRecord(id); _records.removeWhere((r) r.id id); notifyListeners(); } }这里有一个细节容易被忽视方法里先操作数据库再操作内存列表最后才 notifyListeners()。这个顺序很重要。如果先通知界面刷新再写数据库界面会用旧数据渲染一轮出现闪一下的问题如果先改数据库但忘了更新内存列表那界面永远不会刷新。所以我的习惯是“数据库先落库内存再同步最后通知监听者”。这三个步骤缺一不可。另外说一个 Provider 使用中的常见坑这也是搜“flutter provider 插件使用教程”最容易踩的雷在 build 方法里创建 Provider 实例。比如你在 build 里写了ProviderMovieRecordModel.value(value: MovieRecordModel())那每次 setState 都会重新创建一个 Model数据全丢。正确做法是在 main 函数里用 MultiProvider 一次性注册页面里只负责读。void main() { runApp( MultiProvider( providers: [ ChangeNotifierProvider(create: (_) MovieRecordModel()), ChangeNotifierProvider(create: (_) ExpenseModel()), ], child: const FilmKeeperApp(), ), ); }2.3 数据持久化SQLite 的结构设计与查询策略观影记录账本涉及两类数据观影记录列表和消费流水。列表数据需要关联查询、按月分组汇总这种场景下 shared_preferences 存 JSON 根本不够用Hive 也偏轻了SQLite 是最合适的选择。我在项目里用的是 sqflite 插件注意在鸿蒙端有对应的 sqflite_ohos 实现接口和 sqflite 完全一致切换成本极低。表结构设计分三张表。records 表存观影记录字段包括 id、title、watch_date、rating、platform、comment、created_at。其中 watch_date 是查询统计的核心字段必须建索引。platform 字段存的是观看平台可以是“电影院”“腾讯视频”“B站”等我用数字枚举映射避免字符串导致的数据冗余。expenses 表存消费流水字段包括 id、record_id关联观影记录、amount、category、spend_date、note。一张电影票的消费可以记账到某条观影记录上也可以独立记录比如买会员但还没看电影。categories 表是消费分类配置默认预置“电影票”“会员订阅”“周边商品”“零食饮料”四类也允许用户自定义。为什么要把消费和观影记录拆成两张表因为两者其实不是一对一关系。一场电影你可能买了两张票一条观影记录对应两条消费流水反过来一个月度会员可能覆盖了十部电影。拆开后关联查询灵活很多如果要看“某部电影总共花了多少钱”一个 left join 就出来了。我当初为了图省事把消费金额直接存在 records 表里结果只能统计“每部电影的平均消费”完全没法统计“这个月会员支出”后来花了半小时重构。这个教训值得记账本类应用记录流水和业务实体一定要分开。月度统计的 SQL 查询是核心逻辑我写出来给大家参考-- 月度观影记录数 SELECT COUNT(*) FROM records WHERE strftime(%Y-%m, watch_date) 2025-01; -- 月度消费汇总按分类 SELECT category, SUM(amount) FROM expenses WHERE strftime(%Y-%m, spend_date) 2025-01 GROUP BY category; -- 某部电影关联的所有支出 SELECT e.* FROM expenses e LEFT JOIN records r ON e.record_id r.id WHERE r.title 流浪地球3;2.4 图表展示与主题切换的选型月度账单页面需要柱状图和饼图柱状图展示每天观影次数饼图展示消费分类占比。这个需求用 fl_chart 最方便。它支持折线图、柱状图、饼图、雷达图纯 Dart 实现不依赖平台原生代码所以在鸿蒙端也能直接用。这里要说一个小技巧fl_chart 的柱状图工具提示tooltip在鸿蒙端点击事件上偶尔会不响应我用的是 TouchTooltipConfig 里的 getTooltipColor 回调实测在鸿蒙上需要把 tooltipBgColor 显式设置成半透明色否则点击的时候 tooltip 显示一团黑。这属于典型的“框架能用但细节要调”的情况。主题切换方面Flutter 的 ThemeData 天然支持深色模式MaterialApp 里设置 theme 和 darkTheme然后跟随系统切换即可。应用里我做了三档浅色、深色、跟随系统。在设置页提供一个 SegmentedButton 来切换。有一个容易忽略的点是showLicensePage应用设置里常见的“开源许可”页面默认的标题颜色跟随 ThemeData 的 appBarTheme我一开始没设置 licensePage 的颜色导致深色模式下那个页面的标题变成深灰色几乎看不见。后来在showLicensePage方法外面包了一层 Theme 才解决。这个细节不常见但真实存在写在这里给需要的朋友避个雷。3. 观影记录账本的核心功能实现3.1 观影记录模块增删改查与评分体系核心模块是观影记录管理包含记录列表、详情页、新增/编辑页三个主要界面。列表页我选择用 ListView.builder 配合卡片式布局每张卡片显示电影封面网络图或本地图、片名、观看日期、评分5 星制、观看平台。记录按观看日期倒序排列这个直接靠 SQLite 的 ORDER BY watch_date DESC 实现内存排序会造成大数据量下的卡顿不推荐。新增/编辑页是个表单页字段包括片名必填、观看日期DatePicker、评分Slider 或星级评分、平台下拉选择、短评多行文本。这里我用到 Flutter 的 Form TextFormField 校验方案片名空值时提示“请输入片名”。评分用五星组件我选择用第三方库 flutter_rating_bar语义清晰、交互流畅在鸿蒙端也没有兼容问题。但如果想减少依赖用 Slider 其实也够只是用户感知上五星更亲切。class MovieRecordFormPage extends StatefulWidget { final MovieRecord? record; // 非空则为编辑模式 ... } class _MovieRecordFormPageState extends StateMovieRecordFormPage { final _formKey GlobalKeyFormState(); late TextEditingController _titleController; late DateTime _watchDate; late double _rating; String _platform 电影院; override void initState() { super.initState(); _titleController TextEditingController(text: widget.record?.title ?? ); _watchDate widget.record?.watchDate ?? DateTime.now(); _rating widget.record?.rating ?? 5.0; _platform widget.record?.platform ?? 电影院; } override void dispose() { _titleController.dispose(); super.dispose(); } void _save() { if (!_formKey.currentState!.validate()) return; final record MovieRecord( id: widget.record?.id, title: _titleController.text.trim(), watchDate: _watchDate, rating: _rating, platform: _platform, comment: _commentController.text.trim(), ); if (widget.record null) { context.readMovieRecordModel().addRecord(record); } else { context.readMovieRecordModel().updateRecord(record); } Navigator.of(context).pop(); } }保存逻辑里有个细节新增和编辑走的是同一个表单页通过 widget.record 是否为 null 区分。这样共用一个表单页代码量省了一大截而且天然保证新增和编辑的字段一致性不会出现“新增时能填评分编辑时评分控件却丢了”这种对称性 bug。评分组件配套的逻辑是列表页按评分降序排序新增页面评分默认 5 星编辑页面回显原评分。这里有一个产品层面的取舍观影记录是主观行为我选择不做“必须评分”的强校验用户没看完的电影也可以只记片名不评分。这种灵活度在工具类 App 里很重要——强制用户完成流程会劝退很多人。3.2 消费记账与月度统计的实现细节账本功能的重点是消费流水管理。每一笔消费有四个关键属性金额amount、分类category、日期spendDate、关联观影记录recordId。新增消费流水时用户可以手动输入金额从预设分类里选择也可以直接从某条观影记录跳转过来预填关联。两种入口都收敛到同一个 ExpenseFormPage参数是可选 recordId。金额输入这里有个隐蔽的问题用户在 TextField 里输入“12.5”程序拿到的是字符串“12.5”但 SQLite 存的是 REAL 类型所以要做 parse。如果用户输入“12.345”这种三位小数SQLite 能存但显示和统计时会出精度问题。我的做法是录入时校验最多两位小数用正则^\d(\.\d{1,2})?$拦截同时在模型层把金额统一转成 int单位分存储这样彻底绕开浮点精度问题。这个方案在金融类 App 是标配在个人小工具里容易被忽略但一旦涉及月度汇总SUM就会踩坑——浮点数累加会出现 0.1 0.2 0.30000000000000004 的现象。月度统计页面是账本应用的“灵魂”。顶部显示本月总观影数、总支出、平均评分三个指标卡中间是柱状图每天观影次数下方是饼图消费分类占比最底下是分类明细列表。这一页依赖的 SQL 在前面已经贴过逻辑上就是查 records 表按月分组计数、查 expenses 表按分类汇总。数据量在几千条以内时SQLite 的查询速度都是毫秒级不需要做缓存优化直接在 build 方法里查询并返回 FutureBuilder 即可。等数据量增长到几万条以上再考虑加内存缓存或引入 async 状态的 StreamProvider这个阶段不用过度设计。还有一类数据要考虑负数记账。用户在退票时可能产生退款我会把这类流水记成金额为负的分类“退款”。统计 SQL 用 SUM 聚合退款自动抵扣总支出。这个逻辑要提前设计否则后面加退款功能就得重构统计 SQL。3.3 导出与备份CSV 导出和 JSON 备份实现观影账本这种个人数据应用数据导出是刚需。用户可能想把自己一年的观影记录导入其他应用或者单纯想备份。我实现了两个导出入口CSV 导出用于表格软件打开JSON 备份用于完整恢复。两者都依赖 path_provider 获取应用文档目录在鸿蒙端对应 path_provider_ohos 插件。CSV 导出的实现思路很简单查询所有记录转换成 CSV 格式字符串写入文件再调用 share_plus 分享。“简单”二字背后有几个坑写出来供参考第一CSV 的换行符容易被 Excel 兼容性问题吃掉。Dart 的 File.writeAsString 默认使用 LF 换行Excel 在 Windows 上打开会错行。解决方案是写入前把换行符替换成 CRLF。这个细节至少能救活 50% 的导出体验问题。第二注释字段里的逗号和引号会破坏 CSV 结构。用户写了一句“今天看哭了电影票还挺贵”这里面的逗号如果直接拼进 CSVExcel 会把它拆成两列。正确做法是字段值里包含逗号、双引号、换行符时用双引号包裹字段内的双引号用两个双引号转义。这不是 Flutter 特有的问题而是所有手写 CSV 的通用规则但我在网上搜到的 Flutter CSV 教程里很少有人讲清楚。String _escapeCsvField(String value) { if (value.contains(,) || value.contains() || value.contains(\n)) { return ${value.replaceAll(, )}; } return value; }JSON 备份则简单地多把 records 和 expenses 两张表的数据全部序列化成 JSON写入文件。恢复时读取 JSON先清空数据库再批量插入。为防止用户误操作把备份文件恢复错了我加了一个版本号字段备份文件里带 app_version恢复时校验版本不匹配就提示失败。这个版本校验在个人项目中属于“做了会显得很专业不做也没人知道”的加分项我个人建议加上。3.4 扩展能力定位与地图在观影场景的接入观影记录有一个很高频的使用场景记录“我在哪个电影院看的”。这个需求如果要做得完整免不了接入地图定位。热词里“flutter 如何接入高德”出现了很多次说明这是 Flutter 开发者的共性需求。但在这里我要先泼一盆冷水地图类插件是目前 Flutter 生态里鸿蒙适配最差的品类没有之一。原因在于高德地图 Flutter 插件的原理是原生 SDK 封装Android 端调用高德 Android SDKiOS 端调用高德 iOS SDK鸿蒙端没有对应的官方插件需要你自己用 MethodChannel 桥接鸿蒙的 Map Kit。如果只是为了让用户手动选一个电影院位置完全用不着引入地图 SDK用 dart 包里的联动选择器省-市-区-影院就够了既省包体又省适配精力。所以我的策略是把影院信息作为普通字符串字段存入记录用它做统计维度不引入地图。等鸿蒙端地图 SDK 的 Flutter 插件成熟以后再考虑升级。如果确实需要接入策略是自己在鸿蒙工程里写一个地图页面封装成 MethodChannelDart 侧调用 channel 传入经纬度和地点名鸿蒙侧用 Map Kit 显示地图。这个过程并不复杂但很琐碎而且地图 SDK 的 key 申请、权限配置、初始化流程在鸿蒙和 Android 上完全不同。关于在鸿蒙端配置高德地图 key 和权限的问题下文 4.3 里有更详细的说明。4. Flutter 工程接入鸿蒙的完整适配实践4.1 鸿蒙 Flutter 开发环境搭建与踩坑实录这是整个项目里最折腾的部分。鸿蒙上的 Flutter 开发不是从官方 Flutter SDK 里 create 一个带鸿蒙平台的项目就可以了官方 Flutter SDK 目前还没有把鸿蒙作为 first-class 平台支持必须使用 OpenHarmony SIG特别兴趣小组维护的 flutter_flutter 分支。这个分支在 Gitee 上名字就叫 flutter_flutter基于官方 Flutter 稳定版和主开发分支做同步鸿蒙相关的平台代码都在 sdk 的 ohos 目录下。环境搭建第一步是安装 DevEco Studio鸿蒙的 IDE类似 Android Studio。注意这里要装 5.0 及以上版本才支持 API 12 及以上的鸿蒙应用开发。第二步是下载鸿蒙 Flutter SDK 并配置环境变量。具体操作先把 OpenHarmony 的 Flutter 分支 clone 到本地然后把它配到 PATH 里确保输入flutter --version显示的是这个分支的版本而不是官方版本。git clone https://gitee.com/openharmony-sig/flutter_flutter.git -b master export FLUTTER_HOME~/flutter_flutter export PATH$FLUTTER_HOME/bin:$PATH export FLUTTER_STORAGE_BASE_URLhttps://storage.flutter-io.cn第三行 FLUTTER_STORAGE_BASE_URL 是让 Flutter 从国内镜像下载依赖能解决不少网络问题特别是下载引擎产物和 pub 包的时候。这里的细节是只配置这个环境变量还不够OpenHarmony 的 Flutter 分支还需要额外配置一个环境变量用于指定引擎和构建工具链叫OHOS_SDK_HOME指向你安装 DevEco Studio 时自带的 SDK 目录。如果不配置 OHOS_SDK_HOMEflutter doctor会提示找不到鸿蒙 SDK。接下来创建项目。常规做法是先用flutter create创建一个普通的 Flutter 项目然后在项目根目录执行flutter create --platforms ohos .如果这个命令执行成功项目里会多出 ohos 目录里面是鸿蒙的工程模板包括 entry 模块、oh-package.json5、module.json5。不过我在实际操作中遇到过--platforms ohos不被识别的情况那说明你的 Flutter 版本不是 OpenHarmony 分支需要回退检查分支。另一种方式是从 OpenHarmony SIG 提供的一个 flutter_ohos_samples 仓库拉模板手动把 ohos 目录拷进项目效果一样。构建和运行用的是flutter build hap和flutter run -d device。第一次在真机上运行DevEco Studio 会自动签名但如果你的鸿蒙设备开启了“开发人员选项”里的“仅通过 USB 安装”可能会遇到设备连接失败需要手动通过 DevEco 部署一次。后面第 5 章会把常见错误汇总这里先不展开。4.2 工程结构调整从 Android 到鸿蒙的关键差异鸿蒙工程的目录结构和 Android 差异很大但核心逻辑是相通的。我这里把关键点整理成一个表格方便对照对比项Android鸿蒙(OpenHarmony)模块结构android/app/src/mainohos/entry/src/main工程配置文件build.gradlebuild-profile.json5模块配置AndroidManifest.xmlmodule.json5依赖声明pubspec.yaml gradleoh-package.json5应用入口MainActivityEntryAbility权限声明AndroidManifest 里uses-permissionmodule.json5 里 requestPermissions调试工具adbhdc构建产物APK/AABHAP/APP初次从 Android 迁移到鸿蒙最容易漏的就是权限配置。Android 的网络权限写在 AndroidManifest.xml 里鸿蒙的对应权限写在 ohos/entry/src/main/module.json5 的 requestPermissions 字段。如果你的应用需要访问网络比如加载电影海报在 Android 上配 INTERNET 权限就行在鸿蒙里则要加ohos.permission.INTERNET。而且在鸿蒙 API 12 上如果你要在网络访问的同时使用 HTTP非 HTTPS协议还要额外开 usesCleartextTraffic 开关否则请求会被系统拦截。这两个权限问题最容易把新手卡在“页面白屏”或“图片加载不出来”上。应用入口的差异也需要关注。Android 的 MainActivity 在鸿蒙里对应 EntryAbility但 Flutter 工程在鸿蒙端的入口逻辑不是让你在 ArkTS 里写页面而是通过一个 FlutterPage 组件把 Flutter 的渲染内容嵌入进去。Flutter 的插件注册、MethodChannel 的注册都在 EntryAbility 的 onCreate 里完成通过 FlutterEngine 的 config 来设置。我在项目里的做法是新建一个MyFlutterPage.ets文件继承 FlutterPage 并重写 onCreate 注册插件然后在 EntryAbility 里跳转到这个页面。还有一个容易被忽略的差异是资源文件的存放位置。Flutter 的 assets 默认从 flutter_assets 目录加载这在 Android 和鸿蒙上是一样的。但如果你在 ArkTS 层有自己的自定义图片资源它们的路径和 Flutter 层不互通。跨层共享资源目前只能通过原生 API 读取然后传给 Flutter或者把资源放进 Flutter 的 assets 再在 Dart 层访问。我在项目里把 App 图标和启动页放在了 ArkTS 层其他所有图片资源都放在 Flutter assets 里这样两边各管各的互不干扰也省得来回转换。4.3 原生能力打通Dart 与 ArkTS 的 MethodChannel 实践Flutter 在鸿蒙上跑起来后最典型的原生能力需求是调用鸿蒙系统特有的 API。比如获取设备型号、读取系统相册、调用系统分享。这些能力在 Android 端有现成插件在鸿蒙端就要自己写桥接。MethodChannel 的整体思路是Dart 侧通过 channel 调用方法名和参数鸿蒙侧监听 channel 并处理处理结果通过 result 返回给 Dart。鸿蒙侧实现和 Android 侧其实非常像区别在于 Android 用 Java/Kotlin 写鸿蒙用 ArkTS 写。Dart 侧定义一个获取设备型号的方法static const platformChannel MethodChannel(com.filmkeeper/device); FutureString getDeviceModel() async { try { final String model await platformChannel.invokeMethod(getDeviceModel); return model; } on MissingPluginException { return unknown; } }鸿蒙侧在 EntryAbility 里注册同一个 MethodChannel监听方法import { MethodChannel, MethodCall, FlutterResult } from ohos/flutter_ohos; const channel new MethodChannel(engine, com.filmkeeper/device); channel.setMethodCallHandler((call: MethodCall, result: FlutterResult) { if (call.method getDeviceModel) { const model deviceInfo.getModel(); // 调用鸿蒙系统API result.success(model); } else { result.notImplemented(); } });这段代码的关键在于 MethodChannel 的名称必须和 Dart 侧完全一致前缀建议用“com.公司名/功能名”的格式避免和其他插件冲突。我碰到过一种情况MethodChannel 名字取了device_info结果和某些第三方插件的内部 channel 撞了导致调用时返回异常。这事排查了很久才发现是命名冲突。所以给自家 channel 起名时一定要有唯一的包名前缀。MethodChannel 的传参类型也要注意鸿蒙侧接收到的参数是 JSON 对象Dart 侧传入的 Map、List、String、num、bool 基本都能直接映射。但如果 Dart 侧传入 int 类型的值鸿蒙侧拿到的可能变成 double因为鸿蒙的 JSON 解析统一转成 number 类型它内部不分 int 和 double。我在传日期时间戳时就因为这个类型转换吃了亏Dart 侧的毫秒时间戳在鸿蒙侧解析成了浮点数赋值给 ArkTS 的 number 类型变量后精度丢失。解决方案是传字符串而不是数字在鸿蒙侧解析字符串再转成想要的类型这个方法虽然丑但绝对可靠。4.4 鸿蒙端的 Flutter 插件适配sqflite、path_provider 等任何一个真实项目都不可避免要依赖 Flutter 插件。我在这个项目里用到的关键插件包括 sqflite、path_provider、share_plus、fl_chart、intl、provider。其中 fl_chart、intl、provider 是纯 Dart 包鸿蒙端毫无压力。sqflite 和 path_provider 都有对应鸿蒙实现sqflite_ohos、path_provider_ohos用法和原版一致唯一要改的是 pubspec.yaml 里的依赖名称。这里有一个 Flutter 生态里比较常见的插件适配机制值得说明很多 Flutter 插件在 Android/iOS 上通过 method channel 和原生层通信鸿蒙上要实现同样的功能需要一个“中间层”把鸿蒙的原生实现注册到 Flutter 引擎里。这些中间层通常以单独的包发布名字里带 ohos 后缀例如path_provider_ohos、shared_preferences_ohos、sqflite_ohos。但这不意味着你需要在代码里 import 两个包它们依赖的还是同一个 Dart 接口如 path_provider只是在 pubspec 里显式声明对应 ohos 包作为依赖。具体到我的项目sqflite 在鸿蒙端的数据库路径定位方式变了。Android 上getDatabasesPath()返回/data/data/包名/databases/而鸿蒙返回的是应用沙箱路径data/storage/el2/base/haps/entry/files/databases/。这个差异不需要你手动处理因为 sqflite_ohos 已经内置了路径映射逻辑直接调用 getDatabasesPath 拿到的就是鸿蒙的可用路径。但要注意的是如果你的数据库已经存在迁移时要确认启动时的建表 SQL 是否兼容鸿蒙端 SQLite 的版本通常较新一些旧写法可能不兼容比如 SQLite 新版本默认开启外键约束但旧版本不会如果你的表结构里有外键要确认 ON DELETE CASCADE 行为是否符合预期。5. 常见问题排查与实战避坑速查表5.1 Flutter Gradle 插件应用方式警告热词里有条报错很典型you are applying flutters main gradle plugin imperatively using the apply s。这是 Android 构建时的一种警告意思是你的 android/settings.gradle 在应用 Flutter Gradle 插件时用了旧的命令式写法新插件版本要求改用声明式 plugins DSL。虽然目前只是警告但后续 Flutter 版本可能会直接报错所以还是建议先处理掉。修复方式是把apply /path/to/flutter.gradle改成在 settings.gradle 里加plugins { id dev.flutter.flutter-plugin-loader version 1.0.0 id com.android.application version 8.1.0 apply false id org.jetbrains.kotlin.android version 1.8.22 apply false }这个报错虽然发生在 Android 构建环节但如果你一开始只是用 Flutter 开发 Android 版后来才加鸿蒙适配这个旧工程残留问题会一直伴随你所以尽早处理。5.2 Windows 下 Flutter 构建报 CMake 生成器错误热词里另一条flutter cmake error at cmakelists.txt:3 (project): generator visual studio。这是 Windows 上构建 Flutter Windows 桌面版或某些原生插件时常见的错误。原因是你的机器上装了多个 Visual Studio 版本或 CMake 默认生成器选了 VS 而 Flutter 期望用 Ninja。解决办法有三种一是到 Visual Studio Installer 里安装“使用 C 的桌面开发”工作负载二是配置环境变量CMAKE_GENERATORNinja并确保 Ninja 在 PATH 里三是如果你不需要 Windows 桌面版直接在flutter config里禁用 Windows 桌面平台从根源上跳过这个检查。这条报错虽然和鸿蒙适配没有直接关系但我在鸿蒙开发环境配置期间频繁遇到因为 DevEco Studio 本身自带的 CMake 工具链会影响系统全局的 CMake 设置。强烈建议在项目根目录创建.fvmrc或自己写一个环境变量脚本固定 CMake 和 Ninja 的版本避免 IDE 和命令行互相污染。5.3 Flutter 插件解析失败错误热词里的flutter error resolving plugin [id: dev.flutter.flutter-plugin-loader, ver...是 pub 依赖解析时匹配不到插件版本导致的。这类问题在鸿蒙开发中特别常见因为 OpenHarmony 分支的 Flutter 版本往往落后于官方稳定版而 pub.dev 上的最新插件可能要求更高的 Flutter 版本。解决的思路很直接查看项目里flutter --version的版本号然后在 pubspec.yaml 里把插件版本降低到与该 Flutter 版本兼容的区间。比如我的 Flutter 分支是 3.22.0那我把 provider 锁在 6.1.xsqflite 锁在 2.3.x避免依赖解析器选到 7.x 的新版本。另一个解析失败的隐蔽原因是 pub 源不稳定。在鸿蒙开发环境下如果你配置了 pub 镜像但它和 OpenHarmony 分支的包索引有同步延迟也可能解析失败。我的做法是在项目根目录下创建 pubspec_overrides.yaml把有问题的插件包重定向到国内或 Gitee 的镜像源。dependency_overrides: sqflite_ohos: git: url: https://gitee.com/openharmony-sig/sqflite_ohos.git ref: main5.4 底部弹窗里的 TextField 被键盘遮挡这个是我在观影记录新增页面遇到的交互问题也是搜索热词里“flutter 底部弹窗内有 text field”的来源。场景是我在新增观影记录时把“短评”输入框放在一个 showModalBottomSheet 里键盘弹出时输入框被输入法完全遮住用户完全打不了字。Flutter 默认情况下Scaffold 的 resizeToAvoidBottomInset 会自动把页面顶上去但 bottom sheet 的布局是浮在页面之上的键盘弹出时它的位置不会自动调整。解决方案是监听 MediaQuery.viewInsets 变化给 bottom sheet 内部内容加一个底部 padding。网上很多教程直接让人setState增加 padding但没有考虑动画导致键盘弹出时内容跳动很生硬。我的做法是return AnimatedPadding( duration: const Duration(milliseconds: 200), curve: Curves.easeOut, padding: EdgeInsets.only( bottom: MediaQuery.of(context).viewInsets.bottom, ), child: _buildFormContent(), );AnimatedPadding 会让 bottom sheet 跟随键盘弹出做平滑动画实测在鸿蒙端和 Android 端表现一致。不要用MediaQuery.of(context).viewInsets.bottom之外的方式去获取键盘高度因为在鸿蒙上某些输入法可能不遵循标准 keyboardInset 回调用 viewInsets 是最稳妥的方案。5.5 Provider 不刷新的三个常见原因Provider 不刷新是新手最爱踩的坑。我总结了三类最常见情况每个都可以在现场诊断。第一类Model 里调用了 notifyListeners()但界面没有用 Consumer 或 context.watch 订阅只是用 Provider.of(context) 读了一次数据。Provider.of默认不开 listen所以数据变了界面不会重绘。要触发刷新必须写成Provider.ofT(context, listen: true)或者用 Consumer 包裹需要刷新的组件。第二类异步方法里忘了在if (mounted)之后调用 notifyListeners。比如删除记录时数据库删完了但页面已经关闭这时候调用 notifyListeners 不会报错但也没用数据更新停留在内存里下次进入页面才刷新。这种问题在 Navigator 跳转场景下特别容易忽略。第三类同一个 Model 被两个不同的 Provider 实例创建导致数据不同步。我在做“新增观影记录后月度统计页要自动刷新”的功能时踩过这个坑列表页的 Model 和统计页的 Model 不是同一个实例。解决方法是保证全应用只有一个 Model 实例用 MultiProvider 在顶层注册一次各个页面只依赖绝不自己创建。5.6 鸿蒙真机调试连接不上开发鸿蒙 Flutter 应用最痛苦的事就是连不上真机。现象往往是flutter devices里看不到设备但 DevEco Studio 里能看到。原因是 Flutter 用的是 hdc 工具而 DevEco Studio 连接设备时可能用的是自身的 USB 服务两者抢占同一台设备。解决办法先断开 DevEco Studio 的设备连接在命令行里执行hdc list targets看看设备是否出现如果出现就执行hdc start启动 hdc server再执行flutter devices。如果还是没有检查 USB 调试模式是否开启以及鸿蒙设备上是否安装了最新的 hdcd 驱动。另外有一种情况是 hdc 需要先 hdc kill再hdc start 重启服务这个操作解决了我至少八成的连接问题。6. 项目扩展方向与个人实操心得6.1 从观影账本到更多场景的扩展设计这个项目做完以后我发现它的架构完全可以复用到其他垂直场景。比如“阅读记录账本”“游戏时长账本”“健身消费账本”。它们的数据模型高度相似一个业务实体表书/电影/游戏/训练一张消费流水表买书/电影票/游戏/私教课再加上评分和时间维度。如果你也想拿类似项目练手我建议的重点不是把某一块功能写得花里胡哨而是把数据模型和统计模块抽象好这样后续换一个垂直场景只需要改实体字段和文案统计逻辑和 UI 框架基本能复用。更值得扩展的方向是把观影数据和在线电影数据库打通。比如通过 TMDB API 拉取电影元信息海报、导演、演员、剧情简介这样用户添加观影记录时不用手输片名搜索一下自动补全。这个能力会让应用的体验上一个台阶但它不是纯 Dart 能搞定的——要处理网络请求、JSON 解析、图片缓存而且 TMDB 在部分地区访问需要代理如果访问不稳定建议选用其他可用的电影数据库 API。这里面没有太多鸿蒙适配问题因为网络请求在 Flutter 层面走 dart:io 就能完成不需要平台通道。6.2 跨平台鸿蒙开发的真实验收感受把整个项目从 Android 迁移到鸿蒙之后我最直观的感受是官方文档覆盖率决定了开发效率的天花板。Flutter 官方对鸿蒙的支持还处在“能用但没完全铺开”的阶段很多报错和异常在 Google 上搜不到答案在中文社区反而能找到——因为国内开发者踩坑最多。搜索热词里大量出现的“flutter 安装与配置”“flutter 打包安卓 apk”等其实侧面说明 Flutter 社区的很多基础瓶颈还没彻底解决这跟鸿蒙适配又是两个维度的问题叠加在一起确实有点酸爽。在项目里我得到的最有价值的经验是把“适配鸿蒙”当成“适配一个新插件生态”而不是“适配一个新系统”。Flutter 的 UI、状态管理、业务逻辑在鸿蒙和 Android 上完全一致真正要适配的只是那几十个和原生层通信的插件。所以规划鸿蒙项目时第一件事不是搭 Flutter 工程而是盘点你的依赖清单里有哪些是纯 Dart 包、哪些带原生代码、哪些有 ohos 后缀的替代包。这个盘点做完了你就能准确评估鸿蒙适配的工作量——十有八九比你想的要少。6.3 给后来者的三条实操建议如果让我给准备做 Flutter 鸿蒙开发的朋友三个建议我会说第一优先选择 OpenHarmony SIG 维护的插件包而不是自己从零写桥接。社区里已经有 sqflite_ohos、path_provider_ohos、shared_preferences_ohos 等一堆现成方案很多人不知道它们存在或者知道但不知道去哪找。入口就是 Gitee 的 openharmony-sig 组织进去搜你需要的插件名加 ohos 后缀省时省力。第二鸿蒙的构建产物虽然是 HAP但它的调试流程和 Android 截然不同建议从第一天就用真机调试不要指望模拟器能完全复刻真机行为。鸿蒙模拟器在网络权限、定位权限、音视频解码方面的表现和真机相差很大。很多问题只在真机上暴露比如我遇到的 MethodChannel 传参精度问题、底部弹窗与输入法冲突问题模拟器上统统没有。尽早接真机等于把调试周期拉长把上线前的意外压缩。第三别把新版 Flutter 的 UI 特性带到鸿蒙分支上用。我一开始想用 Flutter 新版本里更新的Material 3组件但 OpenHarmony 分支基于的是旧版 Flutter部分组件 API 不兼容运行时报错。后来我把代码里的 M3 相关组件全部换成兼容写法项目终于跑通。这个教训是在鸿蒙 Flutter 里兼容性和稳定性优先于新特性。功能能跑通比代码写得好看重要得多。这个项目从构思到 Android 版跑通用了大概两周鸿蒙适配又花了一周。总体的感觉是Flutter 做鸿蒙跨平台这条路已经能走了但还需要一点耐心和非常多的时间去排查生态里那些半生不熟的兼容问题。如果你正准备入坑希望这篇文章能帮你少走一些弯路。 Flutter鸿蒙跨平台开发实战：观影账本应用从入门到适配
1. 项目背景与整体定位最近在折腾 Flutter 做鸿蒙跨平台适配顺手把一个记观影流水的小账本应用完整跑通了。这篇文章就把整个开发过程的思路、代码、踩坑经过都整理出来给想用 Flutter 在鸿蒙上做应用的朋友一个参考同时也聊聊跨端框架在适配新系统时那些绕不开的实际问题。先说清楚这是个什么项目。标题里的“观影记录账本”不是那种简单的电影收藏夹它做的是两件事结合一是记录你看了什么片名、观看时间、平台、评分、观后感二是记录看电影花了多少钱电影票、视频会员、周边消费。也就是把“观影行为”和“消费账本”合并成一个应用。项目名叫 film-keeper我平时习惯叫它“观影账本”。它的核心价值在于到月底能看到“我这个月看了 12 部电影花了 268 元平均评分 7.8”而不是只知道“我看了很多电影”。这个项目适合谁看分三类。第一类是已经熟悉 Flutter 基础、想尝试鸿蒙端适配的开发者重点看第 4 和第 5 章那是鸿蒙适配和环境问题最集中的地方。第二类是正在做跨平台应用选型的产品或技术负责人第 1、2 章的分析能帮你看清楚跨端框架在鸿蒙这种新平台上的真实成本和收益。第三类是纯粹想拿一个项目练手的学习者整个项目从状态管理到数据库再到图表统计都有麻雀虽小五脏俱全可以直接照着敲。再说说这个项目的规模。整个应用在 Android 上跑起来大概 4000 行 Dart 代码迁移到鸿蒙端以后新增的 ArkTS 桥接代码不超过 200 行。这个比例就是 Flutter 跨平台的意义所在——业务逻辑、UI、状态管理全部复用只有平台相关的能力比如获取设备信息、调用系统功能需要单独写桥接代码。当然这只是我这个项目的数字如果你的应用依赖大量原生插件那鸿蒙适配的工作量会成倍上涨这一点后面会详细分析。2. 为什么选 Flutter 做鸿蒙跨平台技术方案解析2.1 Flutter 的跨端原理与鸿蒙的契合点先弄清楚 Flutter 凭什么能跨平台。大多数人对 Flutter 的印象是“一套代码跑多端”但很少有人关注它为什么能做到这一点。Flutter 的核心在于它不自带原生控件而是用 Skia 图形引擎在画布上重新绘制所有 UI 组件。你可以把它理解成一部电影在每家影院都用同一套放映机、同一套胶片播放而不是让每家影院用自己的设备翻拍一次。Android 的按钮、iOS 的按钮、鸿蒙的按钮在 Flutter 世界里统统不存在存在的是 Flutter 自己画出来的“像按钮的东西”。这种做法带来的直接好处就是 UI 层的移植成本极低。鸿蒙系统作为新平台由于没有历史包袱对第三方应用的原生控件适配支持远不如 Android 成熟但这恰恰是 Flutter 发挥优势的地方——它根本不依赖原生控件。只要能把 Flutter 引擎编译到鸿蒙系统上能提供画布渲染和事件分发整个 UI 层就能跑起来。所以 Flutter 跨端到鸿蒙本质上是把“渲染引擎”编译到鸿蒙而不是把“控件库”移植到鸿蒙。另一个契合点是鸿蒙原生生态还不够丰富很多常用的第三方库在鸿蒙上要么没有要么维护不活跃。而 Flutter 生态库只要不依赖原生插件绝大多数能直接跑。比如我用的 fl_chart 图表库、intl 日期格式化、csv 导出库这些在鸿蒙端完全没有碰壁因为它们都是纯 Dart 实现。这事关一个选型原则如果决定用 Flutter 做鸿蒙应用优先选纯 Dart 实现的库少碰带有 Android/iOS 原生代码的插件因为那些插件在鸿蒙端大概率要重新写桥接。2.2 状态管理方案Provider 在小项目里的优势状态管理选型上我对比过 Provider、Riverpod 和 Bloc。Bloc 学习曲线陡峭模板代码多适合大团队大项目Riverpod 没有依赖注入容器调试体验好但概念多新手容易被绕晕Provider 是三者中最容易上手的代码量最少而且有 Flutter 官方团队背书。对于观影账本这种中小型项目Provider 是性价比最高的选择这也是为什么 Flutter 社区搜索量里“flutter provider 插件使用教程”一直居高不下。Provider 的核心原理其实很简单它底层用的是 Flutter 自带的 InheritedWidget在这个基础上封装了 ChangeNotifier。InheritedWidget 能让子树里的组件读取到父级共享的数据ChangeNotifier 能让数据发生变化时通知订阅者。Provider 把这两者结合起来就是“数据变了所有依赖这个数据的组件自动重建”。我用一个 MovieRecordModel 来管理所有观影记录它继承 ChangeNotifier内部维护一个 List 增删改之后调用 notifyListeners()界面上用 Consumer 或 context.watch 来订阅数据一变 UI 自动刷新。class MovieRecordModel extends ChangeNotifier { ListMovieRecord _records []; ListMovieRecord get records List.unmodifiable(_records); Futurevoid load() async { _records await DatabaseHelper.instance.getAllRecords(); notifyListeners(); } Futurevoid addRecord(MovieRecord record) async { await DatabaseHelper.instance.insertRecord(record); _records.insert(0, record); notifyListeners(); } Futurevoid updateRecord(MovieRecord record) async { await DatabaseHelper.instance.updateRecord(record); final index _records.indexWhere((r) r.id record.id); if (index ! -1) { _records[index] record; notifyListeners(); } } Futurevoid deleteRecord(int id) async { await DatabaseHelper.instance.deleteRecord(id); _records.removeWhere((r) r.id id); notifyListeners(); } }这里有一个细节容易被忽视方法里先操作数据库再操作内存列表最后才 notifyListeners()。这个顺序很重要。如果先通知界面刷新再写数据库界面会用旧数据渲染一轮出现闪一下的问题如果先改数据库但忘了更新内存列表那界面永远不会刷新。所以我的习惯是“数据库先落库内存再同步最后通知监听者”。这三个步骤缺一不可。另外说一个 Provider 使用中的常见坑这也是搜“flutter provider 插件使用教程”最容易踩的雷在 build 方法里创建 Provider 实例。比如你在 build 里写了ProviderMovieRecordModel.value(value: MovieRecordModel())那每次 setState 都会重新创建一个 Model数据全丢。正确做法是在 main 函数里用 MultiProvider 一次性注册页面里只负责读。void main() { runApp( MultiProvider( providers: [ ChangeNotifierProvider(create: (_) MovieRecordModel()), ChangeNotifierProvider(create: (_) ExpenseModel()), ], child: const FilmKeeperApp(), ), ); }2.3 数据持久化SQLite 的结构设计与查询策略观影记录账本涉及两类数据观影记录列表和消费流水。列表数据需要关联查询、按月分组汇总这种场景下 shared_preferences 存 JSON 根本不够用Hive 也偏轻了SQLite 是最合适的选择。我在项目里用的是 sqflite 插件注意在鸿蒙端有对应的 sqflite_ohos 实现接口和 sqflite 完全一致切换成本极低。表结构设计分三张表。records 表存观影记录字段包括 id、title、watch_date、rating、platform、comment、created_at。其中 watch_date 是查询统计的核心字段必须建索引。platform 字段存的是观看平台可以是“电影院”“腾讯视频”“B站”等我用数字枚举映射避免字符串导致的数据冗余。expenses 表存消费流水字段包括 id、record_id关联观影记录、amount、category、spend_date、note。一张电影票的消费可以记账到某条观影记录上也可以独立记录比如买会员但还没看电影。categories 表是消费分类配置默认预置“电影票”“会员订阅”“周边商品”“零食饮料”四类也允许用户自定义。为什么要把消费和观影记录拆成两张表因为两者其实不是一对一关系。一场电影你可能买了两张票一条观影记录对应两条消费流水反过来一个月度会员可能覆盖了十部电影。拆开后关联查询灵活很多如果要看“某部电影总共花了多少钱”一个 left join 就出来了。我当初为了图省事把消费金额直接存在 records 表里结果只能统计“每部电影的平均消费”完全没法统计“这个月会员支出”后来花了半小时重构。这个教训值得记账本类应用记录流水和业务实体一定要分开。月度统计的 SQL 查询是核心逻辑我写出来给大家参考-- 月度观影记录数 SELECT COUNT(*) FROM records WHERE strftime(%Y-%m, watch_date) 2025-01; -- 月度消费汇总按分类 SELECT category, SUM(amount) FROM expenses WHERE strftime(%Y-%m, spend_date) 2025-01 GROUP BY category; -- 某部电影关联的所有支出 SELECT e.* FROM expenses e LEFT JOIN records r ON e.record_id r.id WHERE r.title 流浪地球3;2.4 图表展示与主题切换的选型月度账单页面需要柱状图和饼图柱状图展示每天观影次数饼图展示消费分类占比。这个需求用 fl_chart 最方便。它支持折线图、柱状图、饼图、雷达图纯 Dart 实现不依赖平台原生代码所以在鸿蒙端也能直接用。这里要说一个小技巧fl_chart 的柱状图工具提示tooltip在鸿蒙端点击事件上偶尔会不响应我用的是 TouchTooltipConfig 里的 getTooltipColor 回调实测在鸿蒙上需要把 tooltipBgColor 显式设置成半透明色否则点击的时候 tooltip 显示一团黑。这属于典型的“框架能用但细节要调”的情况。主题切换方面Flutter 的 ThemeData 天然支持深色模式MaterialApp 里设置 theme 和 darkTheme然后跟随系统切换即可。应用里我做了三档浅色、深色、跟随系统。在设置页提供一个 SegmentedButton 来切换。有一个容易忽略的点是showLicensePage应用设置里常见的“开源许可”页面默认的标题颜色跟随 ThemeData 的 appBarTheme我一开始没设置 licensePage 的颜色导致深色模式下那个页面的标题变成深灰色几乎看不见。后来在showLicensePage方法外面包了一层 Theme 才解决。这个细节不常见但真实存在写在这里给需要的朋友避个雷。3. 观影记录账本的核心功能实现3.1 观影记录模块增删改查与评分体系核心模块是观影记录管理包含记录列表、详情页、新增/编辑页三个主要界面。列表页我选择用 ListView.builder 配合卡片式布局每张卡片显示电影封面网络图或本地图、片名、观看日期、评分5 星制、观看平台。记录按观看日期倒序排列这个直接靠 SQLite 的 ORDER BY watch_date DESC 实现内存排序会造成大数据量下的卡顿不推荐。新增/编辑页是个表单页字段包括片名必填、观看日期DatePicker、评分Slider 或星级评分、平台下拉选择、短评多行文本。这里我用到 Flutter 的 Form TextFormField 校验方案片名空值时提示“请输入片名”。评分用五星组件我选择用第三方库 flutter_rating_bar语义清晰、交互流畅在鸿蒙端也没有兼容问题。但如果想减少依赖用 Slider 其实也够只是用户感知上五星更亲切。class MovieRecordFormPage extends StatefulWidget { final MovieRecord? record; // 非空则为编辑模式 ... } class _MovieRecordFormPageState extends StateMovieRecordFormPage { final _formKey GlobalKeyFormState(); late TextEditingController _titleController; late DateTime _watchDate; late double _rating; String _platform 电影院; override void initState() { super.initState(); _titleController TextEditingController(text: widget.record?.title ?? ); _watchDate widget.record?.watchDate ?? DateTime.now(); _rating widget.record?.rating ?? 5.0; _platform widget.record?.platform ?? 电影院; } override void dispose() { _titleController.dispose(); super.dispose(); } void _save() { if (!_formKey.currentState!.validate()) return; final record MovieRecord( id: widget.record?.id, title: _titleController.text.trim(), watchDate: _watchDate, rating: _rating, platform: _platform, comment: _commentController.text.trim(), ); if (widget.record null) { context.readMovieRecordModel().addRecord(record); } else { context.readMovieRecordModel().updateRecord(record); } Navigator.of(context).pop(); } }保存逻辑里有个细节新增和编辑走的是同一个表单页通过 widget.record 是否为 null 区分。这样共用一个表单页代码量省了一大截而且天然保证新增和编辑的字段一致性不会出现“新增时能填评分编辑时评分控件却丢了”这种对称性 bug。评分组件配套的逻辑是列表页按评分降序排序新增页面评分默认 5 星编辑页面回显原评分。这里有一个产品层面的取舍观影记录是主观行为我选择不做“必须评分”的强校验用户没看完的电影也可以只记片名不评分。这种灵活度在工具类 App 里很重要——强制用户完成流程会劝退很多人。3.2 消费记账与月度统计的实现细节账本功能的重点是消费流水管理。每一笔消费有四个关键属性金额amount、分类category、日期spendDate、关联观影记录recordId。新增消费流水时用户可以手动输入金额从预设分类里选择也可以直接从某条观影记录跳转过来预填关联。两种入口都收敛到同一个 ExpenseFormPage参数是可选 recordId。金额输入这里有个隐蔽的问题用户在 TextField 里输入“12.5”程序拿到的是字符串“12.5”但 SQLite 存的是 REAL 类型所以要做 parse。如果用户输入“12.345”这种三位小数SQLite 能存但显示和统计时会出精度问题。我的做法是录入时校验最多两位小数用正则^\d(\.\d{1,2})?$拦截同时在模型层把金额统一转成 int单位分存储这样彻底绕开浮点精度问题。这个方案在金融类 App 是标配在个人小工具里容易被忽略但一旦涉及月度汇总SUM就会踩坑——浮点数累加会出现 0.1 0.2 0.30000000000000004 的现象。月度统计页面是账本应用的“灵魂”。顶部显示本月总观影数、总支出、平均评分三个指标卡中间是柱状图每天观影次数下方是饼图消费分类占比最底下是分类明细列表。这一页依赖的 SQL 在前面已经贴过逻辑上就是查 records 表按月分组计数、查 expenses 表按分类汇总。数据量在几千条以内时SQLite 的查询速度都是毫秒级不需要做缓存优化直接在 build 方法里查询并返回 FutureBuilder 即可。等数据量增长到几万条以上再考虑加内存缓存或引入 async 状态的 StreamProvider这个阶段不用过度设计。还有一类数据要考虑负数记账。用户在退票时可能产生退款我会把这类流水记成金额为负的分类“退款”。统计 SQL 用 SUM 聚合退款自动抵扣总支出。这个逻辑要提前设计否则后面加退款功能就得重构统计 SQL。3.3 导出与备份CSV 导出和 JSON 备份实现观影账本这种个人数据应用数据导出是刚需。用户可能想把自己一年的观影记录导入其他应用或者单纯想备份。我实现了两个导出入口CSV 导出用于表格软件打开JSON 备份用于完整恢复。两者都依赖 path_provider 获取应用文档目录在鸿蒙端对应 path_provider_ohos 插件。CSV 导出的实现思路很简单查询所有记录转换成 CSV 格式字符串写入文件再调用 share_plus 分享。“简单”二字背后有几个坑写出来供参考第一CSV 的换行符容易被 Excel 兼容性问题吃掉。Dart 的 File.writeAsString 默认使用 LF 换行Excel 在 Windows 上打开会错行。解决方案是写入前把换行符替换成 CRLF。这个细节至少能救活 50% 的导出体验问题。第二注释字段里的逗号和引号会破坏 CSV 结构。用户写了一句“今天看哭了电影票还挺贵”这里面的逗号如果直接拼进 CSVExcel 会把它拆成两列。正确做法是字段值里包含逗号、双引号、换行符时用双引号包裹字段内的双引号用两个双引号转义。这不是 Flutter 特有的问题而是所有手写 CSV 的通用规则但我在网上搜到的 Flutter CSV 教程里很少有人讲清楚。String _escapeCsvField(String value) { if (value.contains(,) || value.contains() || value.contains(\n)) { return ${value.replaceAll(, )}; } return value; }JSON 备份则简单地多把 records 和 expenses 两张表的数据全部序列化成 JSON写入文件。恢复时读取 JSON先清空数据库再批量插入。为防止用户误操作把备份文件恢复错了我加了一个版本号字段备份文件里带 app_version恢复时校验版本不匹配就提示失败。这个版本校验在个人项目中属于“做了会显得很专业不做也没人知道”的加分项我个人建议加上。3.4 扩展能力定位与地图在观影场景的接入观影记录有一个很高频的使用场景记录“我在哪个电影院看的”。这个需求如果要做得完整免不了接入地图定位。热词里“flutter 如何接入高德”出现了很多次说明这是 Flutter 开发者的共性需求。但在这里我要先泼一盆冷水地图类插件是目前 Flutter 生态里鸿蒙适配最差的品类没有之一。原因在于高德地图 Flutter 插件的原理是原生 SDK 封装Android 端调用高德 Android SDKiOS 端调用高德 iOS SDK鸿蒙端没有对应的官方插件需要你自己用 MethodChannel 桥接鸿蒙的 Map Kit。如果只是为了让用户手动选一个电影院位置完全用不着引入地图 SDK用 dart 包里的联动选择器省-市-区-影院就够了既省包体又省适配精力。所以我的策略是把影院信息作为普通字符串字段存入记录用它做统计维度不引入地图。等鸿蒙端地图 SDK 的 Flutter 插件成熟以后再考虑升级。如果确实需要接入策略是自己在鸿蒙工程里写一个地图页面封装成 MethodChannelDart 侧调用 channel 传入经纬度和地点名鸿蒙侧用 Map Kit 显示地图。这个过程并不复杂但很琐碎而且地图 SDK 的 key 申请、权限配置、初始化流程在鸿蒙和 Android 上完全不同。关于在鸿蒙端配置高德地图 key 和权限的问题下文 4.3 里有更详细的说明。4. Flutter 工程接入鸿蒙的完整适配实践4.1 鸿蒙 Flutter 开发环境搭建与踩坑实录这是整个项目里最折腾的部分。鸿蒙上的 Flutter 开发不是从官方 Flutter SDK 里 create 一个带鸿蒙平台的项目就可以了官方 Flutter SDK 目前还没有把鸿蒙作为 first-class 平台支持必须使用 OpenHarmony SIG特别兴趣小组维护的 flutter_flutter 分支。这个分支在 Gitee 上名字就叫 flutter_flutter基于官方 Flutter 稳定版和主开发分支做同步鸿蒙相关的平台代码都在 sdk 的 ohos 目录下。环境搭建第一步是安装 DevEco Studio鸿蒙的 IDE类似 Android Studio。注意这里要装 5.0 及以上版本才支持 API 12 及以上的鸿蒙应用开发。第二步是下载鸿蒙 Flutter SDK 并配置环境变量。具体操作先把 OpenHarmony 的 Flutter 分支 clone 到本地然后把它配到 PATH 里确保输入flutter --version显示的是这个分支的版本而不是官方版本。git clone https://gitee.com/openharmony-sig/flutter_flutter.git -b master export FLUTTER_HOME~/flutter_flutter export PATH$FLUTTER_HOME/bin:$PATH export FLUTTER_STORAGE_BASE_URLhttps://storage.flutter-io.cn第三行 FLUTTER_STORAGE_BASE_URL 是让 Flutter 从国内镜像下载依赖能解决不少网络问题特别是下载引擎产物和 pub 包的时候。这里的细节是只配置这个环境变量还不够OpenHarmony 的 Flutter 分支还需要额外配置一个环境变量用于指定引擎和构建工具链叫OHOS_SDK_HOME指向你安装 DevEco Studio 时自带的 SDK 目录。如果不配置 OHOS_SDK_HOMEflutter doctor会提示找不到鸿蒙 SDK。接下来创建项目。常规做法是先用flutter create创建一个普通的 Flutter 项目然后在项目根目录执行flutter create --platforms ohos .如果这个命令执行成功项目里会多出 ohos 目录里面是鸿蒙的工程模板包括 entry 模块、oh-package.json5、module.json5。不过我在实际操作中遇到过--platforms ohos不被识别的情况那说明你的 Flutter 版本不是 OpenHarmony 分支需要回退检查分支。另一种方式是从 OpenHarmony SIG 提供的一个 flutter_ohos_samples 仓库拉模板手动把 ohos 目录拷进项目效果一样。构建和运行用的是flutter build hap和flutter run -d device。第一次在真机上运行DevEco Studio 会自动签名但如果你的鸿蒙设备开启了“开发人员选项”里的“仅通过 USB 安装”可能会遇到设备连接失败需要手动通过 DevEco 部署一次。后面第 5 章会把常见错误汇总这里先不展开。4.2 工程结构调整从 Android 到鸿蒙的关键差异鸿蒙工程的目录结构和 Android 差异很大但核心逻辑是相通的。我这里把关键点整理成一个表格方便对照对比项Android鸿蒙(OpenHarmony)模块结构android/app/src/mainohos/entry/src/main工程配置文件build.gradlebuild-profile.json5模块配置AndroidManifest.xmlmodule.json5依赖声明pubspec.yaml gradleoh-package.json5应用入口MainActivityEntryAbility权限声明AndroidManifest 里uses-permissionmodule.json5 里 requestPermissions调试工具adbhdc构建产物APK/AABHAP/APP初次从 Android 迁移到鸿蒙最容易漏的就是权限配置。Android 的网络权限写在 AndroidManifest.xml 里鸿蒙的对应权限写在 ohos/entry/src/main/module.json5 的 requestPermissions 字段。如果你的应用需要访问网络比如加载电影海报在 Android 上配 INTERNET 权限就行在鸿蒙里则要加ohos.permission.INTERNET。而且在鸿蒙 API 12 上如果你要在网络访问的同时使用 HTTP非 HTTPS协议还要额外开 usesCleartextTraffic 开关否则请求会被系统拦截。这两个权限问题最容易把新手卡在“页面白屏”或“图片加载不出来”上。应用入口的差异也需要关注。Android 的 MainActivity 在鸿蒙里对应 EntryAbility但 Flutter 工程在鸿蒙端的入口逻辑不是让你在 ArkTS 里写页面而是通过一个 FlutterPage 组件把 Flutter 的渲染内容嵌入进去。Flutter 的插件注册、MethodChannel 的注册都在 EntryAbility 的 onCreate 里完成通过 FlutterEngine 的 config 来设置。我在项目里的做法是新建一个MyFlutterPage.ets文件继承 FlutterPage 并重写 onCreate 注册插件然后在 EntryAbility 里跳转到这个页面。还有一个容易被忽略的差异是资源文件的存放位置。Flutter 的 assets 默认从 flutter_assets 目录加载这在 Android 和鸿蒙上是一样的。但如果你在 ArkTS 层有自己的自定义图片资源它们的路径和 Flutter 层不互通。跨层共享资源目前只能通过原生 API 读取然后传给 Flutter或者把资源放进 Flutter 的 assets 再在 Dart 层访问。我在项目里把 App 图标和启动页放在了 ArkTS 层其他所有图片资源都放在 Flutter assets 里这样两边各管各的互不干扰也省得来回转换。4.3 原生能力打通Dart 与 ArkTS 的 MethodChannel 实践Flutter 在鸿蒙上跑起来后最典型的原生能力需求是调用鸿蒙系统特有的 API。比如获取设备型号、读取系统相册、调用系统分享。这些能力在 Android 端有现成插件在鸿蒙端就要自己写桥接。MethodChannel 的整体思路是Dart 侧通过 channel 调用方法名和参数鸿蒙侧监听 channel 并处理处理结果通过 result 返回给 Dart。鸿蒙侧实现和 Android 侧其实非常像区别在于 Android 用 Java/Kotlin 写鸿蒙用 ArkTS 写。Dart 侧定义一个获取设备型号的方法static const platformChannel MethodChannel(com.filmkeeper/device); FutureString getDeviceModel() async { try { final String model await platformChannel.invokeMethod(getDeviceModel); return model; } on MissingPluginException { return unknown; } }鸿蒙侧在 EntryAbility 里注册同一个 MethodChannel监听方法import { MethodChannel, MethodCall, FlutterResult } from ohos/flutter_ohos; const channel new MethodChannel(engine, com.filmkeeper/device); channel.setMethodCallHandler((call: MethodCall, result: FlutterResult) { if (call.method getDeviceModel) { const model deviceInfo.getModel(); // 调用鸿蒙系统API result.success(model); } else { result.notImplemented(); } });这段代码的关键在于 MethodChannel 的名称必须和 Dart 侧完全一致前缀建议用“com.公司名/功能名”的格式避免和其他插件冲突。我碰到过一种情况MethodChannel 名字取了device_info结果和某些第三方插件的内部 channel 撞了导致调用时返回异常。这事排查了很久才发现是命名冲突。所以给自家 channel 起名时一定要有唯一的包名前缀。MethodChannel 的传参类型也要注意鸿蒙侧接收到的参数是 JSON 对象Dart 侧传入的 Map、List、String、num、bool 基本都能直接映射。但如果 Dart 侧传入 int 类型的值鸿蒙侧拿到的可能变成 double因为鸿蒙的 JSON 解析统一转成 number 类型它内部不分 int 和 double。我在传日期时间戳时就因为这个类型转换吃了亏Dart 侧的毫秒时间戳在鸿蒙侧解析成了浮点数赋值给 ArkTS 的 number 类型变量后精度丢失。解决方案是传字符串而不是数字在鸿蒙侧解析字符串再转成想要的类型这个方法虽然丑但绝对可靠。4.4 鸿蒙端的 Flutter 插件适配sqflite、path_provider 等任何一个真实项目都不可避免要依赖 Flutter 插件。我在这个项目里用到的关键插件包括 sqflite、path_provider、share_plus、fl_chart、intl、provider。其中 fl_chart、intl、provider 是纯 Dart 包鸿蒙端毫无压力。sqflite 和 path_provider 都有对应鸿蒙实现sqflite_ohos、path_provider_ohos用法和原版一致唯一要改的是 pubspec.yaml 里的依赖名称。这里有一个 Flutter 生态里比较常见的插件适配机制值得说明很多 Flutter 插件在 Android/iOS 上通过 method channel 和原生层通信鸿蒙上要实现同样的功能需要一个“中间层”把鸿蒙的原生实现注册到 Flutter 引擎里。这些中间层通常以单独的包发布名字里带 ohos 后缀例如path_provider_ohos、shared_preferences_ohos、sqflite_ohos。但这不意味着你需要在代码里 import 两个包它们依赖的还是同一个 Dart 接口如 path_provider只是在 pubspec 里显式声明对应 ohos 包作为依赖。具体到我的项目sqflite 在鸿蒙端的数据库路径定位方式变了。Android 上getDatabasesPath()返回/data/data/包名/databases/而鸿蒙返回的是应用沙箱路径data/storage/el2/base/haps/entry/files/databases/。这个差异不需要你手动处理因为 sqflite_ohos 已经内置了路径映射逻辑直接调用 getDatabasesPath 拿到的就是鸿蒙的可用路径。但要注意的是如果你的数据库已经存在迁移时要确认启动时的建表 SQL 是否兼容鸿蒙端 SQLite 的版本通常较新一些旧写法可能不兼容比如 SQLite 新版本默认开启外键约束但旧版本不会如果你的表结构里有外键要确认 ON DELETE CASCADE 行为是否符合预期。5. 常见问题排查与实战避坑速查表5.1 Flutter Gradle 插件应用方式警告热词里有条报错很典型you are applying flutters main gradle plugin imperatively using the apply s。这是 Android 构建时的一种警告意思是你的 android/settings.gradle 在应用 Flutter Gradle 插件时用了旧的命令式写法新插件版本要求改用声明式 plugins DSL。虽然目前只是警告但后续 Flutter 版本可能会直接报错所以还是建议先处理掉。修复方式是把apply /path/to/flutter.gradle改成在 settings.gradle 里加plugins { id dev.flutter.flutter-plugin-loader version 1.0.0 id com.android.application version 8.1.0 apply false id org.jetbrains.kotlin.android version 1.8.22 apply false }这个报错虽然发生在 Android 构建环节但如果你一开始只是用 Flutter 开发 Android 版后来才加鸿蒙适配这个旧工程残留问题会一直伴随你所以尽早处理。5.2 Windows 下 Flutter 构建报 CMake 生成器错误热词里另一条flutter cmake error at cmakelists.txt:3 (project): generator visual studio。这是 Windows 上构建 Flutter Windows 桌面版或某些原生插件时常见的错误。原因是你的机器上装了多个 Visual Studio 版本或 CMake 默认生成器选了 VS 而 Flutter 期望用 Ninja。解决办法有三种一是到 Visual Studio Installer 里安装“使用 C 的桌面开发”工作负载二是配置环境变量CMAKE_GENERATORNinja并确保 Ninja 在 PATH 里三是如果你不需要 Windows 桌面版直接在flutter config里禁用 Windows 桌面平台从根源上跳过这个检查。这条报错虽然和鸿蒙适配没有直接关系但我在鸿蒙开发环境配置期间频繁遇到因为 DevEco Studio 本身自带的 CMake 工具链会影响系统全局的 CMake 设置。强烈建议在项目根目录创建.fvmrc或自己写一个环境变量脚本固定 CMake 和 Ninja 的版本避免 IDE 和命令行互相污染。5.3 Flutter 插件解析失败错误热词里的flutter error resolving plugin [id: dev.flutter.flutter-plugin-loader, ver...是 pub 依赖解析时匹配不到插件版本导致的。这类问题在鸿蒙开发中特别常见因为 OpenHarmony 分支的 Flutter 版本往往落后于官方稳定版而 pub.dev 上的最新插件可能要求更高的 Flutter 版本。解决的思路很直接查看项目里flutter --version的版本号然后在 pubspec.yaml 里把插件版本降低到与该 Flutter 版本兼容的区间。比如我的 Flutter 分支是 3.22.0那我把 provider 锁在 6.1.xsqflite 锁在 2.3.x避免依赖解析器选到 7.x 的新版本。另一个解析失败的隐蔽原因是 pub 源不稳定。在鸿蒙开发环境下如果你配置了 pub 镜像但它和 OpenHarmony 分支的包索引有同步延迟也可能解析失败。我的做法是在项目根目录下创建 pubspec_overrides.yaml把有问题的插件包重定向到国内或 Gitee 的镜像源。dependency_overrides: sqflite_ohos: git: url: https://gitee.com/openharmony-sig/sqflite_ohos.git ref: main5.4 底部弹窗里的 TextField 被键盘遮挡这个是我在观影记录新增页面遇到的交互问题也是搜索热词里“flutter 底部弹窗内有 text field”的来源。场景是我在新增观影记录时把“短评”输入框放在一个 showModalBottomSheet 里键盘弹出时输入框被输入法完全遮住用户完全打不了字。Flutter 默认情况下Scaffold 的 resizeToAvoidBottomInset 会自动把页面顶上去但 bottom sheet 的布局是浮在页面之上的键盘弹出时它的位置不会自动调整。解决方案是监听 MediaQuery.viewInsets 变化给 bottom sheet 内部内容加一个底部 padding。网上很多教程直接让人setState增加 padding但没有考虑动画导致键盘弹出时内容跳动很生硬。我的做法是return AnimatedPadding( duration: const Duration(milliseconds: 200), curve: Curves.easeOut, padding: EdgeInsets.only( bottom: MediaQuery.of(context).viewInsets.bottom, ), child: _buildFormContent(), );AnimatedPadding 会让 bottom sheet 跟随键盘弹出做平滑动画实测在鸿蒙端和 Android 端表现一致。不要用MediaQuery.of(context).viewInsets.bottom之外的方式去获取键盘高度因为在鸿蒙上某些输入法可能不遵循标准 keyboardInset 回调用 viewInsets 是最稳妥的方案。5.5 Provider 不刷新的三个常见原因Provider 不刷新是新手最爱踩的坑。我总结了三类最常见情况每个都可以在现场诊断。第一类Model 里调用了 notifyListeners()但界面没有用 Consumer 或 context.watch 订阅只是用 Provider.of(context) 读了一次数据。Provider.of默认不开 listen所以数据变了界面不会重绘。要触发刷新必须写成Provider.ofT(context, listen: true)或者用 Consumer 包裹需要刷新的组件。第二类异步方法里忘了在if (mounted)之后调用 notifyListeners。比如删除记录时数据库删完了但页面已经关闭这时候调用 notifyListeners 不会报错但也没用数据更新停留在内存里下次进入页面才刷新。这种问题在 Navigator 跳转场景下特别容易忽略。第三类同一个 Model 被两个不同的 Provider 实例创建导致数据不同步。我在做“新增观影记录后月度统计页要自动刷新”的功能时踩过这个坑列表页的 Model 和统计页的 Model 不是同一个实例。解决方法是保证全应用只有一个 Model 实例用 MultiProvider 在顶层注册一次各个页面只依赖绝不自己创建。5.6 鸿蒙真机调试连接不上开发鸿蒙 Flutter 应用最痛苦的事就是连不上真机。现象往往是flutter devices里看不到设备但 DevEco Studio 里能看到。原因是 Flutter 用的是 hdc 工具而 DevEco Studio 连接设备时可能用的是自身的 USB 服务两者抢占同一台设备。解决办法先断开 DevEco Studio 的设备连接在命令行里执行hdc list targets看看设备是否出现如果出现就执行hdc start启动 hdc server再执行flutter devices。如果还是没有检查 USB 调试模式是否开启以及鸿蒙设备上是否安装了最新的 hdcd 驱动。另外有一种情况是 hdc 需要先 hdc kill再hdc start 重启服务这个操作解决了我至少八成的连接问题。6. 项目扩展方向与个人实操心得6.1 从观影账本到更多场景的扩展设计这个项目做完以后我发现它的架构完全可以复用到其他垂直场景。比如“阅读记录账本”“游戏时长账本”“健身消费账本”。它们的数据模型高度相似一个业务实体表书/电影/游戏/训练一张消费流水表买书/电影票/游戏/私教课再加上评分和时间维度。如果你也想拿类似项目练手我建议的重点不是把某一块功能写得花里胡哨而是把数据模型和统计模块抽象好这样后续换一个垂直场景只需要改实体字段和文案统计逻辑和 UI 框架基本能复用。更值得扩展的方向是把观影数据和在线电影数据库打通。比如通过 TMDB API 拉取电影元信息海报、导演、演员、剧情简介这样用户添加观影记录时不用手输片名搜索一下自动补全。这个能力会让应用的体验上一个台阶但它不是纯 Dart 能搞定的——要处理网络请求、JSON 解析、图片缓存而且 TMDB 在部分地区访问需要代理如果访问不稳定建议选用其他可用的电影数据库 API。这里面没有太多鸿蒙适配问题因为网络请求在 Flutter 层面走 dart:io 就能完成不需要平台通道。6.2 跨平台鸿蒙开发的真实验收感受把整个项目从 Android 迁移到鸿蒙之后我最直观的感受是官方文档覆盖率决定了开发效率的天花板。Flutter 官方对鸿蒙的支持还处在“能用但没完全铺开”的阶段很多报错和异常在 Google 上搜不到答案在中文社区反而能找到——因为国内开发者踩坑最多。搜索热词里大量出现的“flutter 安装与配置”“flutter 打包安卓 apk”等其实侧面说明 Flutter 社区的很多基础瓶颈还没彻底解决这跟鸿蒙适配又是两个维度的问题叠加在一起确实有点酸爽。在项目里我得到的最有价值的经验是把“适配鸿蒙”当成“适配一个新插件生态”而不是“适配一个新系统”。Flutter 的 UI、状态管理、业务逻辑在鸿蒙和 Android 上完全一致真正要适配的只是那几十个和原生层通信的插件。所以规划鸿蒙项目时第一件事不是搭 Flutter 工程而是盘点你的依赖清单里有哪些是纯 Dart 包、哪些带原生代码、哪些有 ohos 后缀的替代包。这个盘点做完了你就能准确评估鸿蒙适配的工作量——十有八九比你想的要少。6.3 给后来者的三条实操建议如果让我给准备做 Flutter 鸿蒙开发的朋友三个建议我会说第一优先选择 OpenHarmony SIG 维护的插件包而不是自己从零写桥接。社区里已经有 sqflite_ohos、path_provider_ohos、shared_preferences_ohos 等一堆现成方案很多人不知道它们存在或者知道但不知道去哪找。入口就是 Gitee 的 openharmony-sig 组织进去搜你需要的插件名加 ohos 后缀省时省力。第二鸿蒙的构建产物虽然是 HAP但它的调试流程和 Android 截然不同建议从第一天就用真机调试不要指望模拟器能完全复刻真机行为。鸿蒙模拟器在网络权限、定位权限、音视频解码方面的表现和真机相差很大。很多问题只在真机上暴露比如我遇到的 MethodChannel 传参精度问题、底部弹窗与输入法冲突问题模拟器上统统没有。尽早接真机等于把调试周期拉长把上线前的意外压缩。第三别把新版 Flutter 的 UI 特性带到鸿蒙分支上用。我一开始想用 Flutter 新版本里更新的Material 3组件但 OpenHarmony 分支基于的是旧版 Flutter部分组件 API 不兼容运行时报错。后来我把代码里的 M3 相关组件全部换成兼容写法项目终于跑通。这个教训是在鸿蒙 Flutter 里兼容性和稳定性优先于新特性。功能能跑通比代码写得好看重要得多。这个项目从构思到 Android 版跑通用了大概两周鸿蒙适配又花了一周。总体的感觉是Flutter 做鸿蒙跨平台这条路已经能走了但还需要一点耐心和非常多的时间去排查生态里那些半生不熟的兼容问题。如果你正准备入坑希望这篇文章能帮你少走一些弯路。