Flutter + OpenHarmony电子合同模板首页开发实战与性能优化

直接上手写这篇。先说结论：用 Flutter 做 OpenHarmony 上的电子合同签署 App，模板首页这一层，是整个项目里最“磨人”但也最出活的部分。它不涉及复杂的签名算法，也不碰底层账本，但要把模板展示、预览、选择、进入签署这个链路做得流畅，跨端通信、渲染性能、状态同步这些坑一个都躲不掉。我这边把实现过程完整拆开讲，包括架构思路、关键代码、踩过的坑，以及针对 OpenHarmony 生态做的适配细节。

1. 整体设计：为什么模板首页是试金石

电子合同签署 App 的业务链路通常是这样的：用户在模板库挑选合适的合同模板，预览确认条款，然后填写信息、完成签署。模板首页就是整条链路的入口，也是用户接触产品的第一屏。它的好坏直接决定用户愿不愿意继续往下走。

1.1 需求拆解：这页到底要做什么

拿我们这次做的版本来讲，模板首页要承担四件事：

• 模板库展示：以网格或列表形式展示合同模板，包括合同类型（租房、劳务、购销、保密协议等）、模板名称、缩略图、使用次数等基础信息。
• 模板筛选与搜索：按合同类型筛选，支持关键词搜索，方便用户快速找到目标模板。
• 模板预览：用户点击某个模板后，要能快速预览合同正文内容，确认是否适合自己的场景。
• 进入签署流程：预览确认后，引导用户进入填写合同关键信息（甲方、乙方、金额、期限等）的步骤。

听起来不复杂，但结合 OpenHarmony 生态和 Flutter 的跨端特性，这页涉及的技术点就多了。首先是 UI 层，要做得跟原生一样顺滑，而不是“一眼 Flutter”；其次是数据层，模板数据要从服务端拉取，需要做缓存和离线可用；再者是通信层，Flutter 和 OpenHarmony 原生之间要互相调用，比如调起系统分享、获取设备信息、处理权限申请；最后是性能层，模板缩略图多、列表滚动频繁，内存和帧率都要控制住。

1.2 方案选型：为什么最终投入 Flutter 的怀抱

这个项目的宿主环境是 OpenHarmony，原生开发用 ArkTS 和 ArkUI。但选择 Flutter，最核心的原因只有一条：开发效率。我们团队本身有成熟的 Flutter 技术栈积累，UI 组件、状态管理、网络层、路由方案都是现成的，如果全部用 ArkTS 重写，至少要翻一倍的人力成本和时间成本。再加上后续如果还要出 Android 甚至 iOS 版本，Flutter 一套代码多端复用的优势就更明显了。

但跨端不是免费的。OpenHarmony 毕竟是新生态，Flutter 对它的支持目前主要依赖 OpenHarmony 官方维护的 flutter_flutter 和 flutter_engine 仓库，插件生态也不如 Android/iOS 成熟。这就意味着，凡是涉及原生能力的调用，比如平台通道、生命周期管理、系统 UI 适配，都需要我们自己动手处理。

1.3 架构分层：让页面替我们挡掉复杂度

模板首页虽然是“一个页面”，但在架构上我把它拆成了四层：

• UI 层：负责页面渲染和用户交互，纯 Flutter Widget。
• 状态层：负责模板列表数据、筛选条件、搜索关键词等状态的管理。
• 数据层：负责从服务端拉取模板数据、本地缓存、数据模型转换。
• 平台层：负责和 OpenHarmony 原生系统交互，包括网络状态监听、文件存储、系统分享等。

每一层只和相邻层通信，不跨层调用。这样做的原因是，后面如果要换数据源、加新模板类型、或者调整 UI 布局，都只影响对应那一层，不会牵一发动全身。尤其是平台层，因为 OpenHarmony 的插件机制还在快速迭代，隔离出来以后，即使 API 变化也只改这一层。

2. 核心细节：Flutter 和 OpenHarmony 的通信机制

这是整个实战里技术含量最高、也最容易被忽视的部分。很多开发者从 Android 转到 OpenHarmony，想当然地把原来的 MethodChannel 代码直接搬过来，结果发现跑不通，就是因为没有理解两端的事件模型差异。

2.1 三通道的取舍：MethodChannel、EventChannel、PlatformView

Flutter 和原生端通信，官方提供了一组通道机制。在这个电子合同项目里，我系统地用了 MethodChannel、EventChannel、PlatformView 这三个，各自解决不同的问题。

MethodChannel是请求-响应模型，最常用。比如模板首页要从原生侧获取设备型号、屏幕尺寸、系统版本，或者把某个模板文件保存到本地，走 MethodChannel 是最直观的。调用方发起请求，原生侧处理后返回结果，一次一答。

EventChannel是事件流模型，适合原生侧主动往 Flutter 推数据的场景。比如网络连接状态的变化、系统回到前台的事件、下载模板文件时的进度回调。在模板首页里，预览大图需要等待下载完成时，我用 EventChannel 把下载进度从原生推到 Flutter，UI 上就能实时展示进度条。

PlatformView是把原生视图嵌到 Flutter 里。这个场景不多，但我们确实碰到了——OpenHarmony 侧有一个内置的 PDF 渲染引擎，处理起合同正文的排版比 Flutter 自带的 PDF 方案强很多。所以模板预览页面里嵌了一个 PlatformView 来展示原生 PDF 视图。

选择这三者的逻辑很清楚：一次性调用用 MethodChannel，持续事件流用 EventChannel，原生视图嵌入用 PlatformView。顺序上，优先考虑 Flutter 自身能力能不能解决，不能解决再看原生侧有没有现成方案，最后才引入新的插件。

2.2 EventChannel 的坑：OpenHarmony 上的事件流重连

EventChannel 在 Android 上很成熟，但到了 OpenHarmony 上，第一次接入就踩了坑。我们的场景是：模板首页要监听原生侧的网络状态变化，断网时展示离线提示条，恢复时自动拉取最新模板。

原生侧的写法在 OpenHarmony 上跟 Android 略有差异，关键是 EventChannel 的setStreamHandler里的onListen和onCancel回调时机。Android 上只要 Flutter 侧receiveBroadcastStream()被调用，onListen就会触发。但 OpenHarmony 上，某些版本里 EventChannel 在 Flutter 页面销毁重建时不会自动重新建立连接，导致网络状态事件丢失。

排查下来，原因是 Flutter 页面被销毁后，EventChannel 的onCancel被调用，但原生侧的监听还在持有系统回调，而 Flutter 侧重新创建页面时不会主动恢复onListen。最终的解决办法是：在页面销毁时显式取消事件流监听，页面重建时重新注册，同时原生侧在推送事件前检查是否有 Flutter 侧在监听，避免事件持续积压。

这里可以给一个 OpenHarmony 侧 ArkTS 的实现示例：

// OpenHarmony 原生侧 EventChannel 接入 import { EventChannel } from '@ohos/flutter_ohos'; let eventChannel = new EventChannel(engine, 'com.example.app/network_status'); let eventSink = null; eventChannel.setStreamHandler({ onListen: (arguments, sink) => { eventSink = sink; // 注册系统网络状态监听 connection.on('netAvailable', () => { eventSink?.success({ status: 'online' }); }); connection.on('netLost', () => { eventSink?.success({ status: 'offline' }); }); }, onCancel: (arguments) => { eventSink = null; connection.off('netAvailable'); connection.off('netLost'); } });

2.3 PlatformView 的适配：贴片模式与手势冲突

模板预览页嵌入了原生 PDF 视图，用的是 PlatformView。在 OpenHarmony 上，PlatformView 的集成方式和 Android 类似，但有个细节特别要注意：贴片模式 vs. 混合模式。

贴片模式在 Android 上体验很糟，因为 Flutter UI 和原生视图是两层，交互时会出现明显的遮挡和闪烁。但 OpenHarmony 目前的实现下，混合模式在部分低端设备上有渲染性能问题，滚动列表时会掉帧。折中方案是：静态展示用混合模式，需要频繁缩放手势时切到贴片模式，同时用一块透明的 Flutter 层承接手势事件。

这个决策背后是针对业务场景的考量——模板预览页的 PDF 内容 90% 是静态阅读，偶尔缩放查看条款细节。混合模式渲染性能足够，而且免去手势透传的麻烦。只有放大到 200% 以上时，才需要切换到贴片模式来保证流畅度。

手势冲突是另一个高频问题。PlatformView 内嵌的原生视图自己处理捏合缩放，但 Flutter 外层同时有GestureDetector监听双击放大。结果是两根手指捏合时，原生视图缩放，但 Flutter 外层的滚动也被触发了，页面跟着上下滑动，体验非常诡异。解决方案是：在捏合缩放开始时，通过 MethodChannel 通知 Flutter 外层禁用滚动，缩放结束后再恢复。这个方案实测下来很稳定，同时也保证了用户双指缩放时不会误触页面滚动。

3. 模板首页实现：从数据到UI的完整链路

数据链路是模板首页的核心动脉。数据怎么来、怎么存、怎么更新，直接决定用户的启动速度、浏览流畅度、以及弱网环境下的可用性。

3.1 模板数据的加载与缓存策略

模板数据从服务端接口拉取，接口返回的是 JSON 数组，每个元素包含模板 ID、名称、类型、缩略图 URL、使用次数、更新时间等字段。首次启动时，页面会展示一个骨架屏，同时发起网络请求；非首次启动时，优先展示本地缓存，后台静默刷新。

缓存策略上，我们没有直接存 JSON 字符串，而是把解析后的模型对象序列化到本地，用Hive这个轻量级数据库来管。选 Hive 是因为它纯 Dart 实现，不依赖原生侧插件，在 OpenHarmony 上不需要额外适配，加上读取速度极快，列表页打开就能看到数据，避免白屏等待。

// 模板数据缓存读取 final box = await Hive.openBox<TemplateModel>('template_cache'); List<TemplateModel> cachedTemplates = box.values.toList();

缓存一定要设置过期时间。我们的策略是 24 小时过期，过期后直接忽略缓存，重新拉取服务器数据。这里有一个细节：缓存更新要采用“写后失效”机制，也就是说服务端模板数据一旦有更新，本地缓存的版本号比对不一致，就直接丢弃，防止用户看到过期内容。

3.2 模板列表 UI 搭建：网格布局的细节与节奏

模板列表采用两列网格布局，每个卡片包含：

• 模板缩略图，比例固定为 3:4，模拟纸质合同的比例。
• 模板名称，最多两行，超长省略号。
• 合同类型的小标签。
• 使用次数，展示为“1.2万人使用”这种社会证明信息。

网格的每一项高度不能写死，因为不同模板名称长度不同，使用次数展示也不一样。用GridView的SliverGridDelegateWithMaxCrossAxisExtent，把每项的宽高比设为固定值，文字部分用Expanded包裹，确保布局不会溢出。

UI 性能上有一个关键细节：图片懒加载和预加载要配合使用。首屏正在展示的缩略图立即加载，下一屏的图片提前 300ms 预加载，再往后的图片等到滚动接近时才开始加载。这样既不浪费流量，又能保证滚动时不出现白块。Flutter 自带的ExtendedImage插件的loadStateChanged回调可以精确控制这个过程。

ExtendedImage.network( template.thumbnailUrl, cacheWidth: 400, loadStateChanged: (state) { if (state.extendedImageLoadState == LoadState.loading) { return Container( color: Colors.grey[200], alignment: Alignment.center, child: SizedBox( width: 24, height: 24, child: CircularProgressIndicator( strokeWidth: 2, color: Colors.grey[400], ), ), ); } return null; }, )

cacheWidth这个参数很关键。如果直接加载原图，一张 1080px 宽的大图塞进 200px 宽的卡片里，内存浪费 5 倍以上，列表一滚起来内存立刻告急。设了cacheWidth: 400之后，Flutter 会自动把图片解码到目标宽度，内存占用直接降低 60% 以上。

3.3 筛选与搜索：状态管理的选择与实践

模板分类筛选放到顶部，使用横向滚动的ChoiceChip列表，支持单选。搜索框放到 AppBar 下方，输入关键词后实时过滤。

状态管理方面，我用了Provider。没有上Riverpod或Bloc，原因是这个页面的共享状态其实只有一个模板列表和筛选条件，用轻量级的ChangeNotifier完全够用，引入 Bloc 反而要写一堆样板代码。

class TemplateListModel extends ChangeNotifier { List<TemplateModel> _templates = []; String _keyword = ''; String _selectedCategory = '全部'; List<TemplateModel> get filteredTemplates { var list = _templates; if (_selectedCategory != '全部') { list = list.where((t) => t.category == _selectedCategory).toList(); } if (_keyword.isNotEmpty) { list = list.where((t) => t.name.contains(_keyword)).toList(); } return list; } void setKeyword(String keyword) { _keyword = keyword; notifyListeners(); } void setCategory(String category) { _selectedCategory = category; notifyListeners(); } void updateTemplates(List<TemplateModel> templates) { _templates = templates; notifyListeners(); } }

筛选和搜索的逻辑全部集中在filteredTemplatesgetter 里，UI 层直接监听这个值变化即可。这样写的好处是，筛选条件变更时，只需要调用notifyListeners()，不需要手动去 rebuild 列表组件。

3.4 模板预览与进入签署的流程衔接

用户点击模板卡片后，进入预览页。预览页顶部显示模板格式（PDF/Word）和页数，中间嵌入 PlatformView 展示 PDF 正文，底部固定两个按钮：立即签署和收藏模板。

这里要处理一个新问题：PDF 内容可能很长，但 PlatformView 只展示第一页或者当前页，用户需要翻页查看全部内容。我们在 PlatformView 外层加了一个翻页控制器，点击区域左半部分翻上一页，右半部分翻下一页，同时通过 MethodChannel 把当前页码回传给 Flutter 层，方便底部显示“第 2/8 页”的提示。

用户点击立即签署后，我们把模板 ID、模板名称、模板当前页面的上下文状态都带进签署填写页。注意这里不要只传一个 ID 就完事，因为签署填写页要展示合同摘要，如果只传 ID，填单页还要自己再发一次请求，既慢又浪费。

Navigator.push( context, MaterialPageRoute( builder: (context) => SignFillPage( templateId: template.id, templateName: template.name, category: template.category, ), ), );

4. 性能优化与界面流畅度保障

模板首页是用户打开 App 的第一个页面，性能不好，用户第一印象就崩了。两块优化是必须做的：列表滚动流畅度、图片加载内存控制。

4.1 列表滚动的性能治理

Flutter 的列表滚动掉帧，最常见的原因就是列表项 build 方法里有耗时操作，或者图片解码卡顿。这次实战中，我做了三层优化保证 60fps：

第一层，GridView.builder是必须的。按需构建列表项，不会一次性把所有 item 都建出来。这块算是 Flutter 的基础操作。

第二层，列表项组件全部用const构造函数包裹，静态布局不参与 rebuild。模板名称、类型标签这些绝大多数情况下不变，做成 const 后 Flutter 可以直接跳过它们的 diff 过程。

第三层，滚动过程中不做任何 setState。之前踩过一个坑：图片加载完成后，loadStateChanged回调里去 setState 刷新 UI，导致整个列表 rebuild，滚动瞬间掉帧。解决办法是，把图片加载状态的刷新范围限制在图片组件自身，使用StatefulWidget局部刷新，不触发父级列表项的 build。

4.2 Impeller 渲染引擎在 OpenHarmony 上的表现

Flutter 3.10 之后，Impeller 成为 iOS 上的默认渲染引擎，OpenHarmony 的 Flutter 适配版本里也有 Impeller 支持。Impeller 的核心优势是，运行时不会像 Skia 那样在 UI 线程做额外的 shader 编译，因此避免了首帧白屏和滚动时的 shader 编译卡顿。

电子合同模板首页，排版元素多，卡片圆角、阴影、图片交织，如果用 Skia，首次渲染后会有一小段时间的微卡顿，因为 shader 还在后台编译。Impeller 模式下，卡片圆角、文本阴影这些全部预编译好，滚动起来丝滑很多。

不过 OpenHarmony 上启用 Impeller 要注意：不同版本的 flutter_flutter 对 Impeller 的支持程度不同，有些版本默认没开，需要在引擎初始化时手动指定。而且部分 OpenHarmony 设备上的 GPU 驱动还不支持 Vulkan，Impeller 会退回到 OpenGL ES 模式。实测下来，退回后的性能依然比 Skia 稳，只是阴影等特效略微降级。

4.3 图片内存与 OOM 的对抗

模板缩略图多，图片内存是最大的隐患。除了前面提到的cacheWidth，还有几个关键点：

• 图片缓存池限制：PaintingBinding.instance.imageCache.maximumSizeBytes默认是 100MB，模板列表这种图片密集型页面，我把它调整为 80MB，避免缓存占太多内存导致其他页面 OOM。
• 不可见区域的图片回收：利用VisibilityDetector监听列表项是否可见，不可见时主动调用imageProvider.evict()释放内存。
• WebP 格式优先：服务端返的缩略图统一转成 WebP 格式，同等画质下体积只有 JPEG 的 70% 左右，解码内存也有下降。

4.4 弱网环境的体验兜底

电子合同的使用场景经常在户外或办公环境，弱网很常见。模板首页的弱网处理，我做了三件事：

第一，请求超时时间设为 10 秒，超过就返回默认的模板列表（之前缓存的），同时展示一个“内容可能不是最新”的提示条。

第二，缩略图加载失败时，显示预设的占位图，占位图用本地资源，不依赖网络。不能因为一张图加载失败就让整个卡片难看。

第三，列表底部加载失败时，展示重试按钮，点击后重新拉取数据。同时有一个隐藏的“全部重试”功能，下拉刷新时可以强制清缓存再拉取，用于解决缓存数据和服务器不一致的问题。

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

这一部分整理了在开发、适配、测试 OpenHarmony 版模板首页过程中实际踩过的坑，按问题现象、可能原因、解决方案三个维度记录，供后续接手项目的人参考。

5.1 模板页面返回时状态丢失

用户从预览页按返回键回模板首页时，发现筛选条件和搜索关键词全部没了，又回到了全量模板列表。这个体验对电子合同这类工具型 App 很致命，用户可能已经筛选好“劳务合同”，返回后又要重新筛一遍。

排查过程：模板首页在dispose()阶段会释放TemplateListModel，返回时页面重新创建，状态自然丢失。修复方案有两种：

方案一：把TemplateListModel的生命周期提升到全局或页面栈的上层，用Provider的ChangeNotifierProvider包裹整个MainScaffold，返回时页面重建但 Model 还在。

方案二：使用PageStorageKey保存GridView的滚动位置和筛选条件，配合AutomaticKeepAliveClientMixin保持页面存活。

我最终选择了方案一，因为方案二在页面多层嵌套的场景下，保活机制容易出问题，尤其在 OpenHarmony 上，AutomaticKeepAliveClientMixin在某些页面切换动画场景下会失效。

5.2 平台通道调用超时的排查

模板首页有这样一个场景：用户点击“立即签署”后，需要从 OpenHarmony 原生侧读取用户的最近签名图片，用于预填签署信息。这里走 MethodChannel，结果在部分设备上出现调用超时。

排查思路很典型。第一步，看 Flutter 侧日志，确认 MethodChannel 是否发出调用；第二步，看 OpenHarmony 侧日志，确认onMethodCall是否收到消息；第三步，检查原生侧代码，发现读取签名图片时，直接在 UI 线程做了磁盘 IO，导致线程阻塞，MethodChannel 的回调迟迟不返回。

解决方案很简单：把磁盘 IO 放到子线程，通过协程或者 TaskPool 执行，完成后回到主线程通过result.success()返回。但排查过程暴露了一个更深层的问题——MethodChannel 在 OpenHarmony 上如果没有设置超时时间，Flutter 侧会一直等下去，UI 卡住，用户感知就是“点按钮没反应”。所以在设置 MethodChannel 时，一定要配置超时回调，超时后走异常兜底，不要让用户干等。

MethodChannel('com.example.app/signature') .invokeMethod<String>('getRecentSignature') .timeout(const Duration(seconds: 5)) .catchError((error) { // 兜底：提示用户手动选择签名图片 return ''; });

5.3 原生返回键与 Flutter 路由的冲突

OpenHarmony 设备的系统返回键（手势返回）触发的路由逻辑，默认情况下的行为跟 Android 类似。但我们测试时发现，模板预览页打开后，系统返回键直接退出了整个 App，而不是返回模板首页。

排查过程：OpenHarmony 的系统返回键事件会先传给 Flutter 的WidgetsBinding，由Navigator.of(context).maybePop()接管。但预览页里的 PlatformView 抢占了焦点，系统返回键被原生侧直接消费掉，没有传给 Flutter。

解决方案是重写预览页的返回逻辑：监听 OpenHarmony 侧的返回键事件，如果是预览页在栈顶，手动调用 Flutter 的Navigator.pop()，同时通知 PlatformView 释放资源。

// OpenHarmony 原生侧拦截返回键 onBackPressed: () { if (isPreviewPageVisible) { // 通知 Flutter 侧处理返回 methodChannel.invokeMethod('onBackPressedFromNative'); return true; } return false; }

6. OpenHarmony 适配与生态集成备忘

最后重点说一下 OpenHarmony 适配过程中那些文档里不会写清楚、但实际项目又绕不开的细节。

6.1 权限声明与 XTS 认证

模板首页的弱网提示、文件缓存、网络请求，涉及到的权限主要是网络访问和文件存储。在 OpenHarmony 上，这些权限声明需要在module.json5里配置，跟 Android 的AndroidManifest.xml类似，但字段名差异比较大。

尤其要注意的是XTS 认证。OpenHarmony 适配的 App 如果要上架官方应用市场，必须通过 XTS 认证测试，其中有一项会检查应用是否声明了非必要的权限。我们在开发阶段为了方便调试，声明了麦克风权限，结果测试包直接被判定为权限滥用。清掉无用权限后重新打包，才顺利通过认证。

还有一点，OpenHarmony 的权限分两种：system_grant（系统授权）和user_grant（用户授权）。网络访问属于 system_grant，静态声明即可；但文件存储如果要读外部存储，属于 user_grant，需要在代码里动态申请，并且 UI 层要处理用户拒绝授权的情况。

6.2 HDI 与设备能力检测

HDI（Harmony Device Interface）是 OpenHarmony 提供硬件能力调用的接口规范。模板首页不需要直接操作硬件，但我们基于 HDI 做了一个设备能力检测：检查当前设备是否支持 PDF 渲染、是否支持硬件解码、GPU 是否支持 Vulkan。

这几个能力检测很有用。比如，如果设备不支持 PDF 渲染，Preview 页就退回用 Flutter 自带的pdf库渲染；如果 GPU 不支持 Vulkan，Impeller 回退到 OpenGL ES，模板卡片阴影特效要降级，避免渲染异常。

// 设备能力检测示例 import { deviceInfo } from '@ohos.deviceInfo'; import { hdi } from '@ohos.hdi'; let isSupportPdf = hdi.getCapability('pdf.render'); let isSupportVulkan = hdi.getCapability('graphics.vulkan');

检测结果通过 EventChannel 下发到 Flutter 层，模板首页的 UI 根据能力动态调整，保证低端设备也能流畅运行。

6.3 应用图标与应用名配置

OpenHarmony 的 App 图标配置在resources/base/profile/main_palette.json和resources/base/element/string.json里，应用名、图标等资源和 Android 的资源系统类似，但路径和命名规范不同。

这里有个跨端开发容易忽略的坑：我们用 Flutter 模板工程生成项目后，OpenHarmony 目录下的app.json5默认的应用名是EntryAbility，图标是默认的 Flutter Logo。如果不改，上架后就是蓝色 Flutter Logo 的 App，一眼假。要改成自己的品牌图标和应用名，需要手动改app.json5里的label和icon字段。

6.4 三类 Flutter 工程结构选择

OpenHarmony 上接入 Flutter 有两种工程结构：Flutter 作为原生工程的一部分（原生为主 Flutter 为辅），Flutter 作为主工程，原生模块作为插件（Flutter 为主）。我们项目选择的是 Flutter 为主、OpenHarmony 原生作为插件模块嵌入，理由有两条：

• 模板首页的 UI 复杂度高，用 Flutter 实现效率最高，原生只负责 PDF 渲染、文件存储、系统能力调用。
• 后续如果要出 Android 和 iOS 版，主工程是 Flutter，原生模块按平台分别适配，复用率最高。

这种结构下，模板首页的所有页面路由、状态管理、数据请求都在 Flutter 层完成，只有 PDF 渲染等少量功能通过 MethodChannel 调原生。

最后的实操心得

模板首页做完，我的整体感受是：Flutter 在 OpenHarmony 上已经不是“能不能跑”的阶段，而是“能不能跑得稳、跑得原生”的阶段。从引擎适配到事件通道，从渲染引擎到设备能力，都在快速完善。但横在开发者和用户体验之间的，依然是那些细节——图片内存、滚动手势、返回键事件、生命周期同步。

给同样在做 Flutter + OpenHarmony 项目的朋友几个建议：

• 模板首页这类数据密集型页面，先把缓存策略想清楚再写 UI，别等列表做完了再补缓存，那会改到怀疑人生。
• EventChannel 在 OpenHarmony 上的生命周期管理比 Android 更敏感，关键事件流的注册和注销要跟页面生命周期严格绑定。
• 涉及图片的页面，cacheWidth一定要设置，这是投入产出比最高的内存优化手段。
• 多花时间在 XTS 认证要求上，权限声明宁可少不可多，等你的包因为权限问题被打回的时候再改就晚了。

模板首页只是电子合同 App 的起点，后面还有合同填写、签署流程、签名采集、合同管理、安全风控，每一块都会遇到新的跨端问题。但有了这一页打底，整个项目的 Flutter + OpenHarmony 技术方案已经验证可行，后面的路走起来会顺很多。