我去年接了一个挺有意思的App需求：做一款手账便签纸收藏应用。听起来简单，实际上要支持用户把各种风格的和纸胶带、便签、素材纸拍照归档，打标签，按心情分类，还要在手机、平板甚至折叠屏上保持一致的视觉和交互体验。更棘手的是，对方明确要求鸿蒙设备必须能正常用。我原本以为Flutter跨平台跑一遍就行，真做起来才发现，Flutter这套东西放到鸿蒙上，坑比想象的多。这篇文章就用手账便签纸收藏应用这个真实项目做主线，把Flutter框架、跨平台方案和鸿蒙适配的完整链路拆解一遍，适合正在做Flutter项目又想兼容鸿蒙的开发同学，也适合想拿一个真实App练手的手账爱好者。我会把项目设计、核心代码、踩过的坑都摆出来，尽量让你照着走能少折腾几天。
1. 手账便签纸收藏应用到底要做什么：需求与选型思路
1.1 手账便签纸收藏的业务场景拆解
手账便签纸收藏应用的核心用户是一批喜欢做手账、收集文具的人。她们会买很多好看的便签纸，有的是格子、波点、花朵图案，有的事先印好日期或待办框，但买回来之后经常想不起来自己有什么，更不知道哪一卷配哪一页。这个App要解决的就是“收藏、分类、快速找到”的问题。
从产品角度看，MVP阶段我建议只做四块：素材列表、素材详情、收藏夹、标签搜索。素材列表用双列瀑布流展示便签纸的照片，详情页展示大图、纸张尺寸、品牌、购买来源、使用心得。收藏夹允许用户把心仪的便签纸按主题分组，比如“复古风”“旅行手帐”“生日礼盒”。标签搜索则承担主要的检索能力，用户拍照入库时顺手打上“和风”“烫金”“网格”等标签，以后搜索的时候直接按标签过滤。
很多开发者会忽略一个点：手账便签纸收藏应用本质上是一个“图片管理工具”，不是普通的笔记App。它最核心的页面都是图片密集型场景，对内存、缩略图缓存、数据库查询性能都有要求。如果把大量高分辨率原图直接加载到列表，分分钟OOM。所以项目初期就要把图片压缩、缩略图生成、懒加载这些基础能力规划进去，而不是做到一半再回头补。
1.2 为什么是Flutter而不是原生双端开发
这个项目选择Flutter，理由很直接：目标设备分布在Android、iOS、鸿蒙三个平台，团队又只有两个人，没有精力各写一套原生代码。Flutter用一套Dart代码同时覆盖三端，UI层采用自绘引擎实现，不会像WebView方案那样在不同系统浏览器内核上出现样式差异。手账应用里有大量圆角卡片、阴影、纸张纹理，Flutter的Canvas渲染能把细节做到像素级统一。
另外，Flutter的状态管理和热重载非常契合这种内容型应用。开发过程中频繁调整瀑布流间距、卡片阴影、标签样式，热重载基本秒级生效，不用每次改UI都重新编译原生工程。再加上Flutter的动画性能在2D UI方面足够强，手账应用常见的页面转场、标签堆叠动画、图片缩放效果都可以用内置的AnimationController完成，不需要额外引大型动画库。
当然，Flutter也不是万能。如果项目需要重度依赖系统原生控件、调用私有的鸿蒙API，或者要做复杂的后台保活任务，纯Flutter方案会很别扭。手账便签纸收藏应用的业务逻辑大部分在UI和数据层，系统能力调用集中在相册、文件存储、传感器这几个明确场景，用Flutter加少量平台通道就能覆盖。所以在这个赛道上，Flutter是性价比非常高的选择。
1.3 鸿蒙适配的三种技术路线怎么选
鸿蒙上跑Flutter，目前不是打开IDE新建一个项目就能跑通的，中间涉及引擎和SDK版本匹配。市面上常见的有三条路线，我按自己的经验排了个序。
第一条是直接使用OpenHarmony社区维护的Flutter适配分支。这个分支把Flutter引擎接到OpenHarmony的ArkTS运行时上，可以在DevEco Studio里编译出HAP包。优点是贴近官方Flutter API，Dart代码基本不用改；缺点是分支更新速度略慢，Flutter官方一发新版，社区适配要过一阵才跟上。
第二条是在Flutter工程里保留Android和iOS平台，额外手工添加一个鸿蒙Runner模块。这个方案适合存量Flutter项目改造。你只需要把鸿蒙Runner当成一个独立的应用壳，通过MethodChannel和EventChannel与Dart层通信，原生的业务代码量不大，大量UI还是由Flutter渲染。手账便签纸收藏这种偏展示型的应用，用这条路线最稳。
第三条是放弃Flutter，直接用ArkTS原生开发。这个方案兼容性最好，性能也最直接，但代价是必须重写整套UI，和“跨平台”的初衷相悖。我见过有人为了一个收藏类App把Flutter版辛苦做完，又花两个月用ArkTS重写，结果后续双端需求变更时维护成本爆炸。除非团队有完整的两套人力，否则不建议走这条。
我最后选的是第二条路线：Flutter写主体，鸿蒙Runner做壳，再用平台通道桥接相册、图片压缩和文件目录。这样既能保住跨平台效率，也能在鸿蒙设备上得到接近原生的体验。
2. 开发环境搭建与首个鸿蒙跨平台工程
2.1 安装Flutter SDK并确认鸿蒙工具链
先说环境准备。别急着双击安装包，先把Flutter SDK和鸿蒙工具链的版本对应关系搞清楚。我见过太多人卡在第一步，就是因为Flutter版本和OpenHarmony SDK不匹配，导致引擎编译时接口对不上。
我的做法是先装一个稳定的Flutter SDK，然后安装DevEco Studio和OpenHarmony SDK。OpenHarmony SDK需要单独下载并配置本地路径，安装完成后要设置环境变量，比如把SDK的ets目录和toolchains目录加到PATH里。注意，DevEco Studio自带了一套SDK配置，但命令行编译时可能读不到，最好在系统环境变量里显式声明。
接下来执行flutter doctor检查Flutter环境。如果里面没有出现鸿蒙相关的状态项，不用慌，因为flutter doctor默认只检查Android、iOS等官方平台，鸿蒙适配分支的检测项一般不会出现在官方版本里。你可以直接查看flutter --version，确认SDK版本和分支来源，再去社区对应版本表里找匹配的OpenHarmony SDK版本。
我这里强烈建议直接用Android Studio管理Flutter工程，但鸿蒙Runner模块用DevEco Studio打开。不要想着一个IDE全部搞定。Android Studio对Dart和Flutter插件的支持更成熟，DevEco Studio对HAP编译、签名、调试的集成更完整。两个IDE打开同一个项目不同目录，是鸿蒙Flutter开发里最常见的工作流。
2.2 创建项目并配置鸿蒙平台模块
创建Flutter项目的命令和平常一样，指定你需要的平台即可。如果你的Flutter适配分支支持ohos平台，可以这样写：
flutter create --platforms=android,ios,ohos hand_note_app如果不支持，那就先创建标准的Android和iOS工程，再手动把社区模板里的鸿蒙Runner目录复制到项目根目录。复制之后需要检查三处：
第一，hand_note_app/ohos目录下要有build-profile.json5和hvigorfile.ts，这是DevEco项目的构建入口。第二，Runner模块里要包含entry/src/main/ets/entryability/EntryAbility.ets，这个文件负责加载Flutter引擎并创建Flutter页面。第三，应用包名和Flutter引用的applicationId要保持一致，否则Dart层调用原生能力时会因为通道绑定到错误的应用进程而失败。
配置完成后，用DevEco Studio打开ohos目录，等待首次同步完成。首次同步会拉取鸿蒙SDK和Flutter引擎依赖，时间比较长，不用反复点刷新，看底部进度条就好。这个过程中最容易出现的是网络超时，建议把Gradle和ohpm的镜像源都配置好，再多试几次。
2.3 跑通“Hello手账”之前必须解决的依赖问题
在动手写业务代码之前，先把依赖跑通。手账便签纸收藏应用需要几个基础插件：数据库、图片选择、文件路径、图片压缩。为了避免后面反复折腾，pubspec文件最好一开始就锁定兼容版本。
以我的项目为例，最常用的依赖是这些：
dependencies: flutter: sdk: flutter sqflite: ^2.3.0 path_provider: ^2.1.0 image_picker: ^1.0.0 flutter_image_compress: ^2.1.0 provider: ^6.0.0注意，sqflite和image_picker这类插件默认只有Android和iOS平台实现，鸿蒙上需要找对应的适配插件。有的插件维护者提供了鸿蒙平台分支，你需要在pubspec.yaml里用git依赖覆盖默认实现，例如：
image_picker: git: url: https://gitee.com/xxx/image_picker.git ref: ohos这个环节最重要的经验是：不要以为所有插件都能够跨平台。开始做鸿蒙适配前，先把你依赖列表里的插件全部过一遍，看有没有OpenHarmony适配分支。有些冷门插件没有适配版本，就得自己写一个简单的MethodChannel实现。
依赖配置好后，先编译一个空白Flutter页面，确保Dart代码能在鸿蒙设备上渲染“Hello HandNote”几个字。能跑通这一步，说明引擎和工具链没问题，后面再进入业务开发。
3. 收藏核心模块开发：数据模型、图片管理与组件通信
3.1 便签纸数据模型与本地数据库设计
手账便签纸收藏应用的数据模型不复杂，但设计不好会很难扩展。我第一版写了七八个字段放在一张表里，后来发现标签和分组的需求变来变去，只能不停改表。建议一开始就把标签和分组拆开，利用关联表处理多对多关系。
一张便签纸的核心信息包括：名称、缩略图路径、原图路径、分类ID、标签列表、纸张尺寸、品牌、购买来源、备注、创建时间。Dart模型可以这样写：
class StickyNotePaper { final int id; final String name; final String thumbPath; final String originalPath; final int categoryId; final List<String> tags; final String sizeText; final String brand; final String source; final String remark; final DateTime createdAt; StickyNotePaper({ this.id = 0, required this.name, required this.thumbPath, required this.originalPath, this.categoryId = 0, this.tags = const [], this.sizeText = '', this.brand = '', this.source = '', this.remark = '', required this.createdAt, }); Map<String, Object?> toMap() { return { 'id': id, 'name': name, 'thumbPath': thumbPath, 'originalPath': originalPath, 'categoryId': categoryId, 'tags': tags.join(','), 'sizeText': sizeText, 'brand': brand, 'source': source, 'remark': remark, 'createdAt': createdAt.millisecondsSinceEpoch, }; } factory StickyNotePaper.fromMap(Map<String, Object?> map) { return StickyNotePaper( id: map['id'] as int? ?? 0, name: map['name'] as String? ?? '', thumbPath: map['thumbPath'] as String? ?? '', originalPath: map['originalPath'] as String? ?? '', categoryId: map['categoryId'] as int? ?? 0, tags: (map['tags'] as String? ?? '').split(',').where((e) => e.isNotEmpty).toList(), sizeText: map['sizeText'] as String? ?? '', brand: map['brand'] as String? ?? '', source: map['source'] as String? ?? '', remark: map['remark'] as String? ?? '', createdAt: DateTime.fromMillisecondsSinceEpoch(map['createdAt'] as int? ?? 0), ); } }数据库表结构用SQLite即可，核心两张表：papers和categories。papers表保存便签纸字段，categories表保存分组信息。标签不单独建表，直接在papers表里用逗号拼接字符串字段存储。对于收藏总量在几千条以内的应用，这种设计足够，查询时用LIKE做标签搜索也没有明显性能问题。
CREATE TABLE papers ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, thumb_path TEXT, original_path TEXT, category_id INTEGER DEFAULT 0, tags TEXT DEFAULT '', size_text TEXT DEFAULT '', brand TEXT DEFAULT '', source TEXT DEFAULT '', remark TEXT DEFAULT '', created_at INTEGER ); CREATE TABLE categories ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, color TEXT DEFAULT '#5B8DEF' );3.2 手账素材图片的采集、压缩与保存
便签纸照片是应用的核心资产，用户拍完后，原图往往有几MB，直接保存到相册和数据库都会给体验拖后腿。所以采集图片后的第一件事是压缩并生成缩略图。
我采用的做法是：先用image_picker获取图片路径，再读取原始数据，在Dart侧进行尺寸缩放和压缩。flutter_image_compress插件在Android和iOS上已经比较成熟，鸿蒙适配如果暂时不稳定，就回到原生事件通道处理。
保存逻辑分两步：原图压缩到最大边长1600像素，保存到应用私有目录documents/papers/；缩略图压缩到最大边长400像素，保存到documents/thumbs/。这两类文件在数据库里分别记录路径，列表页加载缩略图，详情页加载原图。
这里有个小技巧：不要直接使用image_picker返回的临时路径做持久化保存。临时路径经常被系统清理，一旦应用重启，图片就丢了。正确流程是把文件复制到应用私有目录，校验复制结果后再更新数据库。
图片采集这块，最容易踩的坑是权限适配。在鸿蒙上读取相册需要在module.json5里声明ohos.permission.READ_IMAGEVIDEO，用DevEco Studio配置权限时，注意分为“受限权限”和“普通权限”，相册读取属于受限权限，需要动态申请并且在代码里处理弹窗结果。
3.3 跨页面传参不丢状态：Navigator、IndexedStack与状态管理选型
Flutter开发中，跨页面传参最常见的手段就是Navigator的构造参数。比如点开一个便签纸详情页：
Navigator.push( context, MaterialPageRoute( builder: (_) => PaperDetailPage(paperId: paper.id), ), );这样传参简单，但藏着一个坑：如果详情页修改了便签纸信息，返回列表页后，列表页往往还停留在旧数据。因为列表页的State可能被重建，也可能没有刷新。手账应用里用户经常从详情页直接修改标签或备注，返回时要立刻看到变化。
我常用的方案是让列表页等待详情页的返回结果。Navigator.push返回的是一个Future，详情页保存成功后Navigator.pop(context, true)，列表页就拿到一个刷新信号。这样既不用引入全局事件总线，也能保证数据一致。
另一个高频问题是“Navigator切换页面后，会不会丢失状态？”答案是：如果页面被pop销毁，State当然会丢失；如果只是被新的路由覆盖，原来的状态还保留在栈里。真正让人头疼的是底部导航栏切换时，每个Tab页面的滚动位置和列表数据都被重建。解决办法是用IndexedStack承载多个Tab页面，所有页面同时挂载但只有当前Tab可见，状态不会销毁。手账收藏页、标签搜索页、设置页之间切换，用IndexedStack体验提升非常明显。
对于跨页面状态管理，项目规模不大的话，我推荐先用Provider。它的学习成本低，写法接近日常开发，不会像Bloc那样引入一堆概念。比如全局的收藏数量、当前分类ID、主题色，放一个ChangeNotifier里，页面用context.watch()监听，数据变了自动刷新。
3.4 与鸿蒙原生能力通信：MethodChannel和EventChannel的实战
Flutter和鸿蒙原生通信是整个适配里最关键的部分。手账应用需要用到两个原生能力：读取相册图片和图片压缩。前者是主动调用，用MethodChannel；后者如果有进度回调或者文件监听需求，可以用EventChannel。
Dart侧定义通道，我的习惯是把通道名统一放在一个文件里管理，避免散落各处：
import 'package:flutter/services.dart'; class NativeBridge { static const _methodChannel = MethodChannel('com.handnote/native'); static const _eventChannel = EventChannel('com.handnote/gallery_events'); static Future<String?> compressImage(String path, int maxWidth) async { final result = await _methodChannel.invokeMethod<String>( 'compressImage', {'path': path, 'maxWidth': maxWidth}, ); return result; } static Stream<dynamic> galleryEventStream() { return _eventChannel.receiveBroadcastStream(); } }MethodChannel适合一次性请求响应，比如压缩图片，调用后等原生端返回值。EventChannel适合持续监听，比如原生端监测相册是否有新截图，有变化时通过流推给Dart层。
鸿蒙侧的注册逻辑通常在Runner模块的EntryAbility中完成。在这里面拿到FlutterEngine，然后注册对应的MethodChannel处理器。原生代码收到Dart调用的compressImage方法后，调用鸿蒙的图像处理接口完成压缩，再返回新路径。EventChannel则是在原生端通过Streams把事件推给Dart层。
通道通信最需要注意的一点是线程和主线程问题。Dart调用原生方法时，鸿蒙侧默认可能不在UI线程回调结果。不能在原生代码的异步回调里直接操作Flutter UI，必须确保返回值通过事件循环正确回传。另外，通道名必须完全一致，包括包名风格的大小写和中划线，稍微不同就会静默失败，且不会报错，只能靠日志排查。
4. 鸿蒙平台适配实录：渲染、原生控件与打包调试
4.1 Impeller渲染引擎在鸿蒙设备上的取舍
Flutter从3.x开始逐步用Impeller渲染引擎替代Skia。Impeller在Android和iOS上表现很好，渲染速度快、卡顿少。但在鸿蒙适配分支上，Impeller的成熟度和设备兼容性没有官方平台那么稳。
我在一台鸿蒙平板上跑Demo时，发现列表页快速滚动会偶发闪烁，截帧后看到部分图像纹理加载异常。排查了很久，最后把矛头指向Impeller的缓存策略。后来我在鸿蒙Runner的FlutterEngine初始化位置设置了启用Skia渲染，问题就消失了。如果你的应用里也有大量图片列表，建议先分别用Impeller和Skia各跑一遍，看看有没有渲染异常。
判断当前生效的渲染引擎，可以在启动时使用debugPaintLayerBordersEnabled打开调试边框，或者查看运行日志里的Renderer标识。切换引擎的方法在适配分支里通常是一个配置项，比如enableImpeller=false。这个值要写在鸿蒙Runner的初始化配置里，不是在Dart代码里改。
不要因为Impeller听着新就盲上。手账便签纸收藏应用对图片渲染稳定性的要求，远高于对那一点点帧率提升的需求。稳定的图片加载和内存释放，比花哨的渲染特性更重要。
4.2 PlatformView嵌入原生便签编辑器的注意点
手账应用有一个特殊需求：用户可能想直接在便签纸上写字、贴素材，保存成一张合成图片。如果这个功能用Flutter自研Canvas实现，开发量很大，所以我一开始打算嵌入一个原生便签编辑器，通过PlatformView在Flutter页面里显示。
PlatformView的坑在于混合视图的选层处理。Flutter引擎和原生视图是两个不同的渲染层级，嵌入原生的TextView或CanvasView时，可能会出现滚动不同步、触摸事件被原生View吃掉、页面截图缺块等问题。在鸿蒙适配分支上，PlatformView的支持力度本来就比Android晚一步，我在滚动和双指缩放事件上都做了特殊分发才勉强能用。
如果你的场景只是展示原生预览画面，可以用Texture模式。它会把原生控件渲染成一帧一帧的纹理，交给Flutter合成，性能更好，也能避免很多层级冲突。但Texture模式需要原生侧做纹理注册，开发量会上升。
后来我反思了一下，手账便签纸收藏应用其实根本不需要嵌入那么重的原生编辑器。Flutter完全可以用CustomPainter实现简单的书写和贴纸功能，把用户输入合成到画布上。与其Debug PlatformView，不如用纯Flutter实现，跨平台统一且维护成本低。这个经验也分享给大家：只有当原生能力不可替代时，才考虑PlatformView。
4.3 Navigator页面状态丢失与恢复
Flutter里用Navigator做页面跳转时，页面状态是否丢失，完全取决于你怎么管理页面生命周期。普通的Navigator.push，原页面不会dispose，只会暂停；新页面pop后原页面从栈顶恢复，状态还在。但是如果你用了Navigator.pushReplacement或者pushAndRemoveUntil，原页面被销毁，状态自然没了。
手账应用的收藏列表滑动到很长的位置，用户点开一个便签纸看详情再返回，列表应该还停在同一个位置。这个体验看起来简单，实际需要两层保障。第一层，列表页不要被销毁，用前面说的IndexedStack或者不执行pop销毁。第二层，列表数据要带有“恢复锚点”，比如滚动偏移量的持久化。
如果使用ScrollController，可以在dispose前保存当前偏移量，再次进入列表页时重新定位。另一个更规范的做法是把ListView的每一项用一个固定ValueKey标记，然后初始化时跳到之前记录的item index。实测下来，这个方案比保存像素偏移量更靠谱，因为不同屏宽下像素偏移会失真。
对于需要完全重建的页面也有办法。把筛选条件、排序方式、当前标签等数据提升到路由参数中，详情页返回时携带最新参数，列表页收到后重新请求数据库。这样状态不会凭空丢失，恢复逻辑也清晰。
4.4 真机无线调试与Release打包记录
鸿蒙Flutter应用调试，不能像Android一样直接打APK安装。你要先把鸿蒙Runner编译成HAP包，再安装到设备。测试阶段用DevEco Studio的运行按钮很方便，选择真机设备后会自动编译安装启动。如果设备长时间连接不稳定，可以开启无线调试。
无线调试的流程是：首先在设备上打开开发者模式，然后设置里开启无线调试。接着用DevEco Studio的设备管理器扫码或手动输入IP端口连接。注意每次连接时设备可能弹窗询问是否允许，要确认允许调试。无线调试适合修改Dart代码跑热重载的场景，比反复插拔数据线舒服很多。
Release打包是新手的重灾区。第一，必须配置签名，否则HAP装到非本机设备上会失败。第二，需要区分Debug和Release签名，我见过有人把Debug签名包发给测试，结果测试机一更新就安装不上。第三，鸿蒙的包格式和Android不同，不要试图把生成的apk直接改后缀混淆。
打包前建议先把ohos目录下的build-profile.json5检查一遍，确认签名配置路径正确。然后在DevEco Studio里选择Build->Build Hap，选择Release模式。构建成功后，产物通常在ohos/entry/build/default/outputs/default/entry-default-signed.hap。把这个包放到测试设备上用命令行或文件管理器安装即可。
5. 常见问题排查与避坑清单
5.1 高频报错速查表
做Flutter鸿蒙开发的这阵子，我整理了一份高频问题表，很多问题在官方文档里找不到直接答案，只能靠日志和经验去定位。
| 现象 | 可能原因 | 解决思路 |
|---|---|---|
| Flutter工程无法识别鸿蒙设备 | ohos平台模块未注册或SDK路径错误 | 检查flutter config和OpenHarmony SDK环境变量 |
| 编译时提示找不到FlutterEngine相关类 | 鸿蒙Runner的引擎依赖版本与Flutter SDK不匹配 | 对齐分支版本，重新同步ohos依赖 |
| Dart调用MethodChannel无响应 | 通道名不一致或原生侧未注册 | 检查Dart和ArkTS通道字符串是否完全一致 |
| 页面列表滚动时图片突然消失 | Impeller纹理缓存问题或缩略图路径失效 | 先切Skia引擎，再检查文件是否存在 |
| 运行时报缺少READ_IMAGEVIDEO权限 | 鸿蒙module.json5未配置相册权限 | 在权限清单中添加并动态申请 |
| 真机安装HAP显示签名错误 | Release使用了Debug签名 | 配置正式签名文件后重新构建 |
| EventChannel收不到事件推送 | 原生侧没有启动Stream发送 | 在原生逻辑中调用StreamSink的success方法推数据 |
这些坑每一种都在调试上耗过不少时间。遇到问题先不要急着改代码，先看日志。鸿蒙的hilog默认比较详细，Flutter引擎的错误会以flutter为tag输出，用hdc shell hilog | grep flutter就能过滤出来。
5.2 手账收藏应用的性能优化心得
图片型应用的性能优化，本质上就两个字：减负。列表页永远不要加载原图，缩略图统一控制在400像素以内，并且要做内存缓存。Flutter的Image组件默认会做一定的缓存，但是如果你用文件路径频繁创建FileImage，缓存策略可能不稳定。
我建议在应用里用一个统一的图片加载组件，根据路径自动判断加载本地文件还是网络资源，并处理好占位图、错误图、加载完成后的淡入效果。对ListTile和卡片布局，还可以用itemExtent固定行高，帮助列表跳过测量步骤，滚动帧率会明显提升。
数据库查询也要控制。手账应用中下拉刷新或添加新便签纸后，不要直接重新查全表。可以用INSERT OR REPLACE做局部更新，然后只对列表页暴露增量数据流。新增的便签纸插在列表最前面，删除的就从当前列表移除，避免整个数据集合重建。
EventChannel如果用来监听相册变化，要注意事件频率。原生端推送事件时最好做节流，比如500毫秒内只推一次变更通知。Dart侧收到事件后也不要立刻全量刷新，先判断变化类型，再做局部处理。否则用户连续截图几张，应用就会连续刷新好几次，界面会抖动得很明显。
5.3 跨平台鸿蒙开发经验总结
做这个手账便签纸收藏应用，最大的感触是：跨平台不是“一次编写，到处运行”那么理想化。Flutter确实能把UI层和业务逻辑层做得非常统一，但到了鸿蒙平台，引擎、插件、权限、打包，每一步都可能和Android拉开差距。千万不要把Android上的成功经验原封不动搬到鸿蒙，尤其是平台通道和原生控件这两块。
我个人在实际操作中的体会是，接鸿蒙适配项目时，第一步不是写业务代码，而是先把插件依赖的鸿蒙分支名单列出来。缺少适配的插件，该自己写通道就早点写。另一个很有用的习惯是：Dart层和原生层之间的通信数据尽量用普通Map和字符串，不要传自定义对象，减少跨语言边界的数据序列化开销。
如果后续你想把这个项目扩展成社区版，可以考虑加入用户自己上传的手账模板、便签纸电子版在线预览、云端收藏同步这几个方向。但核心还是先把本地收藏体验做好。图片管理、数据模型、平台通道这三块基础打牢了，后面加什么功能都不慌。希望这篇手账便签纸收藏应用开发记录，能帮你在Flutter和鸿蒙适配的路上少踩几个坑。
