引言：打破认知壁垒，Flutter不止是App
在鸿蒙生态中，原子化服务（Atomic Service）和Service Card（卡片）是其“流转”能力的核心载体。很多开发者认为“卡片只能用ArkTS/JS开发”，或者“Flutter做不了卡片”。
这是一个误区。
虽然鸿蒙原生卡片（ArkTS）在交互上更轻量，但在某些场景下，我们希望App和卡片使用同一套UI逻辑（例如：音乐播放器进度条、股票K线图、复杂数据仪表盘）。此时，利用Flutter开发卡片就成为了最佳解决方案。
本文将带你探索如何在鸿蒙中使用Flutter开发卡片，并解决其中的通信与性能难题。
一、 核心架构：Flutter卡片是如何运行的？
在鸿蒙中，卡片是由**卡片提供方（Provider，即Ability）和卡片宿主（Host，如桌面）**组成的。
当我们使用Flutter开发卡片时，架构如下：
+----------------------------+ | 鸿蒙桌面 (卡片宿主) | | - 显示卡片UI | | - 触发点击事件 | +------------+-------------+ | | (Binder通信) v +----------------------------+ | FormAbility (卡片提供方) | | - 管理卡片生命周期 | | - 调用Flutter引擎渲染 | +------------+-------------+ | | (Platform Channel) v +----------------------------+ | Flutter Engine (Dart层) | | - 绘制Widget | | - 处理业务逻辑 | | - 生成Bitmap或RemoteView | +----------------------------+关键点：Flutter卡片并不是直接把Flutter的SurfaceView扔给桌面，而是通过**离屏渲染（Off-screen Rendering）**生成一张图片（Bitmap）或者利用系统能力合成View，推送给桌面显示。
二、 实战步骤：手把手构建Flutter卡片
2.1 创建卡片配置文件
在config.json中声明卡片信息：
{"module":{"forms":[{"name":"flutter_card","type":"js","orientation":"unspecified","formVisibleNotify":true,"updateDuration":30,"defaultHeight":2,"defaultWidth":2,"supportDimensions":["2*2","2*4"],"description":"$string:form_desc","formProviderInfo":{"provider":"FlutterCardProvider"}}]}}2.2 实现FormAbility（原生层）
这是连接鸿蒙系统与Flutter的桥梁。
publicclassFlutterFormAbilityextendsAbility{privatestaticfinalStringCARD_PROVIDER="FlutterCardProvider";@OverridepublicvoidonStart(Intentintent){super.onStart(intent);// 1. 获取卡片管理器FormManagerformManager=FormManager.getInstance(this);// 2. 设置卡片提供方formManager.setFormProvider(CARD_PROVIDER,newIFormProvider(){@OverridepublicvoidonUpdateForm(Formform){// 3. 核心逻辑：这里触发Flutter渲染renderCardByFlutter(form);}@OverridepublicvoidonFormEvent(Formform,inteventId){// 处理卡片点击事件，可通过MethodChannel通知Dart层}});}// 调用Flutter引擎进行渲染privatevoidrenderCardByFlutter(Formform){// 此处需要启动Flutter引擎（或复用已有引擎）// 将Form的ID传递给Dart层，告诉它“我要绘制ID为xxx的卡片”FlutterChannel.sendFormRenderRequest(form.getFormId());}}2.3 Dart层接收指令并绘制
在Dart侧监听来自原生层的“绘制请求”，并返回UI数据。
// 监听卡片事件通道finalEventChannel_formEventChannel=EventChannel('flutter.card.events');voidinitCardListener(){_formEventChannel.receiveBroadcastStream().listen((data){finalStringformId=data['formId'];finalStringaction=data['action'];// 'render', 'click'if(action=='render'){// 1. 根据formId获取对应的数据模型finalcardData=fetchCardData(formId);// 2. 构建Widget树（这里可以复用App内的组件）finalwidget=buildFlutterCardWidget(cardData);// 3. 关键：将Widget渲染为图像数据或布局描述// 方案A：使用RepaintBoundary截图（适合静态或低频更新）// 方案B：将Widget转为JSON描述，回传给原生层用鸿蒙原生组件绘制（适合高性能需求）renderAndSubmitToNative(widget,formId);}});}三、 关键挑战与解决方案
3.1 性能挑战：离屏渲染的开销
Flutter卡片通常需要将Widget渲染成Bitmap传递给系统桌面。如果卡片更新频繁（如秒级刷新的股票行情），频繁的RepaintBoundary截图会导致GPU占用过高和发热。
优化方案：
- 降低刷新频率：非必要不实时刷新，利用鸿蒙的
updateDuration配置。 - 局部更新：如果卡片内容只有数字变化，不要重绘整个背景，只更新文本部分。
- 混合模式：对于纯展示类卡片，Dart层只负责计算布局和颜色，最终生成一个JSON描述文件，通过通道传回原生层，由原生层调用鸿蒙的
ComponentAPI进行最终绘制。这样既复用了逻辑，又保证了性能。
3.2 交互限制：卡片不支持复杂手势
鸿蒙桌面卡片不支持滑动、长按等复杂手势（除了点击跳转）。
开发建议：
- 保持简洁：Flutter卡片应以信息展示和快捷开关为主。
- 点击跳转：利用
router.push或原生startAbility，点击卡片后拉起完整的Flutter App页面。
3.3 包体积控制
如果仅仅为了一个卡片引入整个Flutter引擎，会导致包体积膨胀。
策略：
- 懒加载引擎：只有当用户添加卡片到桌面时，才去初始化Flutter相关的资源。
- 代码分割：将卡片专用的Widget和逻辑剥离成独立的Dart包，避免引入App主工程的庞大依赖。
四、 典型应用场景
- 可视化数据看板
- App内是详细的折线图，卡片上是今日关键指标的简版图表。使用Flutter可以保证图表绘制逻辑（如计算坐标、颜色）在App和卡片上完全一致。
- 音乐播放器
- 卡片上显示专辑封面旋转、进度条和播放/暂停按钮。利用Flutter的动画能力，可以做出比原生更酷炫的视觉效果。
- 多设备状态同步
- 例如智能家居控制，卡片显示设备当前状态（开/关）。当在手机上操作后，利用鸿蒙的分布式数据管理，卡片内容能实时在平板或车机的桌面上同步更新。
五、 总结
使用Flutter开发鸿蒙卡片，本质上是一种**“逻辑复用”和“视觉统一”**的高级技巧。
虽然它在性能上不如原生ArkTS卡片极致，但在开发效率和UI一致性上具有巨大优势。掌握这一技能，你就能让自己的Flutter应用在鸿蒙桌面上“活”起来，真正融入鸿蒙的原子化服务生态。
思考题：
如果让你设计一个“股票行情监控”的Flutter卡片，你会选择“Dart层截图传给原生”还是“Dart层生成JSON由原生绘制”？为什么？
点赞 ▲ 收藏 ⭐ 评论 💬 转发 ➡️
欢迎大家加入开源鸿蒙跨平台开发者社区，一起共建开源鸿蒙跨平台生态。
