去年底接了个需求用户要在一款鸿蒙生态 App 里快速上线一个节日“红包雨”活动页。当时团队的情况很现实——没人写过 ArkTS但大家手里都握着一套成熟的 Flutter 代码库。调研了一圈发现开源社区的 Flutter OpenHarmony 适配分支已经实用化于是我们定了方案用 Flutter 实现红包雨页面再通过鸿蒙原生壳子接进主应用。整个开发过程踩了很多文档里没有的坑也沉淀了不少可复用的经验这篇就把它完整拆开讲清楚从环境搭建、动画实现到鸿蒙平台适配和性能调优全部过一遍。如果你是 Flutter 老手想把手上的项目扩展到鸿蒙或者你是鸿蒙新手想找一个完整的跨平台业务实战来练手这篇应该都对得上。红包雨这个场景虽然看着花哨但它把动画、随机逻辑、事件通信、生命周期管理、性能优化这几个高频技术点全串起来了属于典型的小功能大考卷。我会按我实际开发的顺序来写中间穿插踩坑记录和代码片段尽量还原真实的操作现场。1. 项目背景与整体方案设计1.1 为什么用 Flutter 做鸿蒙业务页先说结论不是所有页面都适合用 Flutter 写但“红包雨”这类强 UI 交互、弱系统依赖的页面用 Flutter 做反而比 ArkTS 原生更省事。鸿蒙原生开发现在生态还不算完全成熟尤其是 ArkTS 的组件库、第三方插件、动效方案跟 Flutter 沉淀多年的生态比还有差距。而红包雨这种页面核心诉求是“动画够炫、掉落实时、点击跟手”这些恰恰是 Flutter 的强项。Flutter 自研的渲染引擎 Skia新版本走 Impeller能保证在 Windows、Android、iOS 和鸿蒙上渲染结果高度一致这意味着你只需要写一套 Dart 逻辑就能在多个平台复用。对团队的意义很简单不养一个只会写鸿蒙的人现有 Flutter 团队可以直接接活。另外要提一个现实点鸿蒙目前主要覆盖手机、平板和部分设备而很多业务线的用户还在 Android/iOS 上。用 Flutter 做跨端一套代码覆盖四个平台后续红利活动要同步上线成本优势非常明显。如果纯用 ArkTS那就等于每个活动都要单独维护一版原生代码时间一长撑不住。1.2 红包雨应用的核心能力拆解把“红包雨”拆成一个开发任务清单大概有六件事红包实体从屏幕顶部随机位置生成并下落下落轨迹可调速、可加速。红包在移动过程中持续渲染视觉上有立体感或光效。用户点击红包后产生命中反馈例如拆红包动画、加分数字飘字。活动有明确的时间窗口例如 30 秒倒计时结束后进入结算页。红包有类型区分普通红包和特殊红包概率触发逻辑上要可配置。页面切后台、切前台、被来电打断时时钟和动画不能乱掉。别小看这六条每一条都对应一组 Flutter 知识点。比如第一条对应 AnimationController、Transform 和路由栈的关系第二条对应 RepaintBoundary 和绘制优化第三条对应 GestureDetector 和命中测试第四条对应 Timer 与组件生命周期的协作第六条对应 WidgetsBindingObserver 和混合生命周期事件。我在设计阶段就画了一张很简单的模块图分四层视图层UI Widget、动画控制层AnimationController 与 Ticker、业务状态层得分、倒计时、红包数据流、平台适配层EventChannel、MethodChannel、生命周期桥接。模块之间用简单的状态回调做通信尽量不引入重型状态管理框架毕竟红包雨页面本身没那么复杂杀鸡不用牛刀。1.3 技术选型与依赖准备Dart 侧我建议只引入必要依赖。当时我们用的是官方标准库加两个辅助包一个是随机数工具其实 Dart 自带 Random 够用另一个是音频反馈的插件点击红包时播放短促提示音。如果你不想在鸿蒙真机上折腾音频插件可以先不做声音纯视觉也能上线。状态管理我推荐在这个项目里用最朴素的 setState。很多人一上来就上 Provider、Riverpod、Bloc结果这个红包雨页面本身状态就没几个倒计时、得分、红包集合三个状态而已。用 setState 完全够而且代码更好懂。如果你想练练 Cubit 这类轻量方案也行但我不建议为了展示技术而给活动页上重型框架后期维护的人会很痛苦。渲染层面红包雨场景里有大量重复移动的 Widget一定要考虑重绘范围。常见的做法是给每个红包包一层 RepaintBoundary让它在平移时只重绘自身不拖累整个页面。等到后面讲性能优化时我再细说但你在项目初期就养成这个习惯后面会少改很多代码。配套工具方面开发鸿蒙用的 IDE 和 Flutter 用的 IDE 可能会需要同时打开。我建议用 DevEco Studio 维护鸿蒙壳工程用 VS Code 写 Dart 代码两边的构建流程都跑通之后再考虑合并成一条编译命令。这个后面环境篇会讲具体步骤。2. 鸿蒙开发环境的搭建与工程创建2.1 Flutter SDK 与 OpenHarmony 适配环境配置网上关于 Flutter 鸿蒙环境的文章很多但版本之间的差异非常大写的时候一定要对齐版本号不能看到一篇就照搬。我是这么配置的安装 OpenHarmony 的命令行工具和 DevEco Studio完成 SDK 的下载与环境变量配置。拉取 Flutter 的鸿蒙适配分支。这个分支由社区维护通常跟 upstream 的稳定版保持同步安装后可以用flutter doctor检查设备和工具链。设置PUB_HOSTED_URL和镜像源这一步大家应该很熟了Dart 包管理在国内环境必须配置镜像不然flutter pub get会卡到怀疑人生。在 Android Studio 或 VS Code 里安装 Flutter 和 Dart 插件确保flutter devices能识别鸿蒙设备或模拟器。实际操作时最容易出问题的点是 OpenHarmony SDK 版本与 Flutter 分支的匹配。社区分支一般会注明它基于哪个 Flutter 版本开发、兼容哪个 OpenHarmony API Level一定要严格按表格对应。版本不匹配最常见的报错是编译时找不到ohos平台目录或者运行时段错误一堆。配置完成后记得在终端跑一遍flutter doctor -v如果输出里能看到 OpenHarmony 相关的检查项并且通过那说明环境基本ok。这里有个细节鸿蒙的真机调试需要打开开发者模式每个版本开启无线调试的位置不一样鸿蒙 4.2 是在“设置-系统-开发者选项”里开无线调试然后用 DevEco Studio 的设备管理器配对不要老想着用老套路连 USB 就行。2.2 创建 Flutter 工程并建立鸿蒙壳工程环境就绪后创建工程这一步很简单flutter create --platforms ohos red_packet_rain我特意指定了ohos平台如果你不指定创建出来的工程默认只带 Android、iOS 三个目录还需要手动补鸿蒙壳。创建完成后目录里会多出一个ohos文件夹那就是鸿蒙工程模块。这里有一个容易忽略的点ohos目录里entry/src/main下面有module.json5和应用级配置文件它跟你平时 Android 的AndroidManifest.xml作用类似。初次打开工程需要手动确认一下应用包名、权限声明、页面入口等配置是否正确。尤其是入口 Ability要确保它指向 Flutter 的FlutterAbility或是官方模板生成的页签否则编译能过但启动白屏。鸿蒙壳工程里默认会生成一个MainAbility它的核心任务就是把 Flutter 引擎加载起来。说实话这块如果完全手动写还是比较繁琐的建议直接用模板生成再改包名效率高很多。模板生成后我会习惯性地清理一遍无用代码把默认的计数器示例删掉换成自己的 Flutter UI。2.3 DevEco Studio 与 Flutter 命令的协同工作流开发过程中最常见的状态是Dart 代码改完需要在鸿蒙壳工程里同步编译运行。我试过几种方案最省心的还是把 Flutter 工程作为子模块或者源码依赖放进鸿蒙工程里。鸿蒙的构建工具在编译时会把 Flutter 的产物打包进 HarmonyOS 的应用包。具体有两种方式第一种是用社区提供的插件式集成在鸿蒙工程里指定 Flutter SDK 路径构建时自动输出 Flutter so 和 assets。第二种是把 Flutter 作为三方库源码依赖直接引用flutter/packages/flutter下的 OHOS 平台工程。我强烈建议优先选第一种因为第二种会把 Flutter SDK 的源码暴露到业务工程中一不小心改了内部实现排查问题的时候极其痛苦。日常开发时我习惯先写好 Dart 代码并跑单测确认逻辑没问题后再在 DevEco Studio 里跑鸿蒙真机构建。你会发现因为 Flutter 是 AOT 编译到鸿蒙所以整个构建周期比 Android 还要长一点尤其是第一次全量编译。耐心等多构建几次后有了增量缓存速度会快很多。3. 红包雨核心界面与动态下落实现3.1 红包元素的数据模型与视觉设计开始写代码之前先把红包的数据模型确定下来。我在 Dart 里定了这样一个轻量级模型class RedPacket { final int id; final double x; // 当前横坐标 final double y; // 当前纵坐标 final double fallSpeed; // 下落速度 px/s final double size; // 红包尺寸 final int score; // 命中得分 final bool isSpecial; // 是否特殊红包 bool collected; // 是否已被点击 RedPacket({ required this.id, required this.x, required this.y, required this.fallSpeed, required this.size, required this.score, required this.isSpecial, this.collected false, }); }为什么要把速度、位置、尺寸都放进去因为动画循环每帧都要读这些数据如果把它们散落在不同的 Map 或者各 Widget 里后面做性能优化和命中判定时你会疯狂找 Bug。模型集中定义还有个好处后续想把红包雨扩展成“飞花”“飘雪”或者其他节日元素只需要改贴图逻辑完全复用。视觉设计上我强烈建议不要用 Flutter 自带组件硬画一个红包而是用 PNG 图片。原因很简单图片的质感和阴影效果比代码绘制好太多而且替换节日素材时只需换资源不用改代码。图片要准备两套普通红包和特殊红包比如金色版再准备一张点击后的拆开状态图。三张图足矣。如果你想把图片加载优化做彻底一点可以把红包图片预加载到内存里用precacheImage提前加载这样动画开始后不会因为图片解码而产生首帧卡顿。3.2 下落动画的坐标系与速度设计红包雨下落本质上是一个不断更新 y 坐标的过程。不用复杂的物理引擎自己算就行。最简单的实现是用一个AnimationController驱动整个游戏循环然后每帧遍历当前的红包列表按y y fallSpeed * dt更新位置。树形 Widget 只负责渲染位置数据的更新放在控制器层。速度设计上要注意屏幕尺寸适配。我最初写死了一个固定速度结果在平板上红包像在散步在手机上又像子弹飞。后来改成按设备屏幕高度比例计算double baseSpeed screenHeight / 6.0; // 大约6秒穿过全屏 double randomSpeed baseSpeed * (0.8 random.nextDouble() * 0.6);这算下来普通红包从屏幕顶部掉到底部要 5-8 秒左右。这个速度区间在 30 秒的局里大概能产生 40-60 个红包既不会冷场也不至于眼花缭乱。想要递增难度就每隔 5 秒把速度整体乘以 1.15感受非常明显。还有一个小细节容易忽略用户手指点击红包时动画不能停但红包的点击反馈应该跟下落独立。我的做法是把“拆开动画”做成一个短暂的缩放 透明度动画用独立控制器驱动。它跟下落主循环互不干涉点击后红包立即从下落列表中移除同时把拆开动画叠加在移除位置这样视觉上才衔接自然。3.3 随机生成与位置避让策略红包出现的位置如果完全随机很容易出现一堆红包叠在屏幕某一侧另一侧空着观感很差。我处理时加了两个策略把屏幕宽度分成若干列例如 5 列每列按权重选一个横坐标随机性保留但分布更均匀。同一时刻下落的红包数量设一个上限比如 8 个超过就暂停生成。这样避免小屏手机同时出现十几个红包点击命中率严重下降。生成频率前面提过是每秒 2-4 个。每次生成时随机决定是普通红包还是特殊红包特殊红包概率我设在 10%点击得分乘以 2 或者给额外奖励。整体规则用一张配置表管理方便运营调整参数初始值说明游戏时长30 秒通过倒计时决定结束时间红包生成间隔0.35-0.5 秒动态增加或者随机普通红包分数1 分点击后累加特殊红包概率10%可配置下落速度基数屏幕高度/6 每秒随难度系数增加同时在场红包上限8 个防止屏幕过密生成逻辑最好集中在一个SpawnController里不要散落在每个 Widget 中。SpawnController内部持有随机数种子、定时器、当前红包列表对外只暴露“下一帧的红包列表”和维护倒计时的回调。后续想要调整玩法只改这个控制器就行。4. 点击交互、计分逻辑与生命周期管理4.1 红包点击命中判定与手势细节点击红包第一反应是给红包包一层GestureDetector。但这有一个性能隐患十几个红包各自维护一个手势识别器虽然数量不大但在低端鸿蒙设备上仍会有一定的命中测试开销。另一种更优的做法是页面级统一用手势监听然后做坐标命中判定。我们实现的思路是在 Stack 根部放一个GestureDetector它的onTapDown会拿到全局坐标然后遍历当前红包列表判断坐标是否落在某个红包的 Rect 内。这个判定在每个屏幕刷新周期只执行一次比每个红包单独注册手势更可控避免了手指点下去触发多个回调的边界问题。判定命中后不要立刻从列表删除红包我踩过这个坑先记录它被收集的状态并在下一帧渲染时播放拆开动画动画结束后再从列表移除。为什么如果点击瞬间就把 Widget 从树里移除你会看到拆开动画完全来不及播放体验像“红包直接消失了”缺少拆红包的快感。手指触点会有一定的偏移尤其是用户快速点击时命中判定框不要做成跟图片完全一样大的方形稍微放大一点比如把判定矩形向外扩 8-10 个逻辑像素。这是一个很小但很影响手感的细节我管它叫“容错命中区”。测试过容错区在 6 像素以下点击感受会变差12 像素以上又容易误触旁边的红包8-10 是甜点区间。4.2 倒计时、得分与结算逻辑倒计时的实现有两种方式一个是Timer.periodic每秒减一另一个是在动画帧里算累计时间。我推荐后者因为刷新帧非常稳定不受 Timer 被其他任务延迟的影响。原理很简单在 Ticker 的回调里维护_elapsed每一帧累加dt剩余时间 总时长 -_elapsed小于等于 0 就触发结束。结束流程分三步停止红包生成、把在场红包做淡出清场、展示结算面板。结算面板包含本局得分、领取数量、特殊红包命中数不过要注意从“游戏界面”切到“结算界面”时不要用 Navigator push 整页切换而是用同一个页面内的状态切换。原因跟 Flutter 路由有关系Navigator.push会触发完整的页面路由动画可能会把优先级提高导致红包雨动画的 Ticker 收到暂停/恢复事件如果代码没处理好切到结算页再返回时动画就乱了。我更倾向于在同一个Stack里用AnimatedSwitcher做页面状态切换这样既能保留页面生命周期又能控制过渡效果。另外一个很容易被忽略的问题页面被切到后台比如用户接了个电话回来发现倒计时已经“自动结束”了得分为 0。这在活动运营上是灾难性的。正确的姿势是监听应用生命周期切后台时暂停 Ticker并把暂停时的剩余时间保存下来回前台时恢复 Ticker从保存的时间继续倒计时。Flutter 里用WidgetsBindingObserver的didChangeAppLifecycleState回调处理鸿蒙壳工程也能正确上报这些生命周期前提是你得在 Dart 侧处理不能只写在原生层。4.3 状态更新与异步任务处理建议因为整个页面状态集中在控制器里我设了三个单独的状态集合倒计时状态、得分状态、红包列表状态。每次倒计时刷新只更新数字得分刷新只更新分数展示不要让整页 rebuild。代码里用ValueNotifier或者StreamBuilder分开监听收益立竿见影。还有一个经常被面试官问到的点Flutter 的Future.then回调是放在微任务队列还是事件循环队列这个在红包雨项目里也会遇到。比如我点击红包后做异步加载奖励资源回调里如果是微任务会在当前帧结束前执行如果是事件任务可能拖到下一帧。如果处理不当点击后 UI 反馈可能延迟一帧感觉不够跟手。实际上 Dart 里Future.then注册的回调是放到微任务队列的正常事件循环里微任务会在当前同步代码执行完后立即处理。但如果你在回调里又发起了另一个Future它的执行时机就可能变。我的经验是不要在动画帧更新逻辑里写太重的异步链奖励结算这类操作放到用户停止点击后再处理或者用一个延时任务批量提交。你在答题或者写业务代码时可以把“微任务执行时机”作为一个检查点出现卡顿先看是不是异步回调把帧间隔拖长了。5. 鸿蒙平台适配与组件通信细节5.1 从 Flutter 页面跳转原生鸿蒙页面鸿蒙壳工程和 Flutter 工程虽然代码上分开但运行时是一个进程这给“互跳”提供了基础。从 Flutter 侧跳转原生鸿蒙页面最典型的做法是使用 MethodChannel// Dart 侧 const platform MethodChannel(com.example.redpacket/native); final result await platform.invokeMethod(openNativePage, {page: RankList});鸿蒙侧对应的实现其实没有 Android 那种直观的插件注册接口这类东西更多需要在 Ability 里识别 MethodChannel 调用的方法名再通过路由或者拉起另一个 Ability 的方式打开原生页面。时序上Dart 侧等待回调返回原生页面打开成功或失败都会把结果回传。我遇到的坑是MethodChannel 即使两边方法名都对只要签名类型不匹配Dart 侧会直接抛出MissingPluginException而且鸿蒙端的错误日志往往不那么直观。所以建议写一个小的测试按钮每次新增原生能力时先点一遍确认基础通道通了再做业务逻辑开发。5.2 EventChannel 接收原生侧的事件另一种场景是原生侧主动推送消息给 Flutter比如系统音量变化、网络状态切换、或者运营后台下发红包雨开关。这时候用 EventChannel 比轮询强太多。初始化一个 EventChannelDart 侧通过receiveBroadcastStream()订阅事件流鸿蒙侧在有事件产生时把数据塞给 Flutter 引擎即可。我在红包雨项目里用 EventChannel 接收了一个真实场景的事件原生侧有一个全局的“活动开关”运营后台在 0 点打开活动开关原生侧检测到变化后通过 EventChannel 推送“开始下雨”的信号给 Flutter 页面。这样 Flutter 页面不需要自己写轮询也不需要用户手动刷新体验非常智能。实现时注意事件流的生命周期页面销毁前一定要取消订阅不然内存泄漏且事件会派发到已经销毁的 UI 上概率性崩溃。EventChannel 的事件类型也是严格匹配的鸿蒙侧发过来的是字符串数组还是 MapFlutter 侧接收时就要按对应类型解析。我这边习惯约定所有事件统一用一个 JSON 字符串包一层把所有结构化信息序列化成MapString, Object到了 Dart 侧再用jsonDecode解防御性最强。5.3 PlatformView 嵌入鸿蒙原生控件如果把 Flutter 页面嵌进鸿蒙原生应用或者反过来在 Flutter 页面里放置一块原生播放器、原生地图就会用到 PlatformView。这个知识点在红包雨里用到的场景是我需要往页面里嵌入一个原生小组件显示用户当前的金币余额而余额组件是原生团队写的我这边不想再造轮子。PlatformView 在 Android 上有虚拟显示和混合叠加两条路线鸿蒙的适配分支也在早期实现了一套混合模式。说实话稳定性方面还有提升空间如果你的红包围场景里混入原生组件可能在快速滚动时出现原生组件卡在最上层的问题。所以我的建议是适配鸿蒙初期尽量少用 PlatformView能不用就不用。如果实在要用把原生组件固定放在某个角落避免与高频动画区域重叠这样能把稳定性风险降到最低。PlatformView 的调试比普通页面困难得多因为它涉及两套渲染引擎的合成。遇到白屏或闪烁先看看是不是 Surface 叠加顺序的问题再看生命周期是否同步。你可以在鸿蒙壳工程里临时添加一段日志输出确认onSurfaceCreated的调用时机这对定位问题非常有帮助。6. 性能优化与常见问题排查实录6.1 渲染性能优化从 RepaintBoundary 到 Impeller红包雨页面最大的性能压力来自动画每个红包都在持续移动大量区域每帧都会标记为“需要重绘”。如果这里不处理中低端鸿蒙设备上很容易掉到 30 帧以下用户体感就是“红包一顿一顿”的。第一层优化是把红包自身包上RepaintBoundary避免红包移动时把背景、文字等静态内容也重绘一遍。每一帧只有红包局部区域被重绘页面整体重绘范围大幅收敛。这招对 GPU 负载的降低立竿见影。第二层优化是控制 Widget 数量。如果同一时刻在屏幕上有超过 8 个红包再加上飘字、按钮、倒计时等元素Widget 树虽然不庞大但也不能掉以轻心。我建议把“点击后的飘字”做成一个共享组件用一个独立的列表维护不要每个点击都生成一个长期存活的 Widget。飘字动画结束后立即从树里移除绝不让不可见 Widget 留在页面里空转。第三层是刷新机制。Flutter 新版渲染引擎Impeller在部分平台已经默认启用它对复杂动画的渲染效率有明显提升。鸿蒙适配分支的渲染引擎暂时还以 Skia 为主但你在自定义绘制时也要尽量用Canvas的位移变换而不是创建新的 Paint 对象。省去创建对象的开销长时间运行的动画才能稳定。性能自测时在WidgetsBinding.instance.addTimingsCallback里监听帧构建耗时或者直接用 DevTools 的 Performance Overlay可以直观看到哪一帧卡顿。如果一帧的构建时间超过 16ms就得考虑减少Widget层级或合并绘制逻辑。6.2 生命周期状态丢失与页面切后台处理红包雨这种“有时长限制”的活动页最怕的就是用户切后台。系统会在后台冻结 UI 渲染如果代码不处理等你从后台切回来Ticker 恢复时红包已经全部掉到底部倒计时也结束了。哪怕你只切后台几秒钟用户的游戏体验也被毁了。解决方案我前文提过就是监听生命周期。但还有一个细节值得单独强调在鸿蒙上应用从后台回前台时AppLifecycleState.resumed的回调时机可能比你预期稍晚不能保证你在用户看到界面的那一刻就恢复动画。一个稳妥的做法是在暂停时记录当时的elapsed恢复时计算recoverElapsed pausedElapsed (now - pausedTime)如果超过总时长就直接进结算避免倒计时出现负数的诡异状态。6.3 常见报错与问题速查表开发过程中我整理了一批高频问题这里以表格形式分享给大家都是真实踩过或者群里高频出现的问题现象可能原因处理方法编译报could not close i之类异常Flutter 缓存与鸿蒙工程缓存冲突清理build/、.gradle/、ohos下的临时目录后重新编译真机flutter run找不到设备无线调试权限未开或端口未配对鸿蒙 4.2 在开发者选项里打开无线调试重新配对Flutter 页面白屏鸿蒙入口 Ability 未正确加载 Flutter 引擎检查module.json5的入口配置和路由指向点击无反应命中率低命中判定 Rect 与视觉尺寸不一致调整容错命中区按实际图片尺寸加 padding切后台回来倒计时秒数跳跃未记录暂停时间戳使用时间戳差值恢复而非简单 resumeAssertionError出现在打包阶段插件平台目录缺失或版本不兼容核对 Flutter 分支与 OpenHarmony SDK 的版本矩阵抓包看不到请求鸿蒙系统的证书和代理设置不同用 DevEco 自带的抓包工具或配置系统级代理证书这套速查表是我把这几个月的挣扎浓缩出来的建议读者直接保存一份到项目 README 里。版本迭代期间这类问题复现率极高有文档照着查能省下一个下午。6.4 多端一致性与统一构建链路最后说一个工程层面的要点跨平台项目一旦加了鸿蒙适配最怕“各端行为漂移”。为了尽可能保持一致我把所有业务逻辑都收敛在 Dart 层原生壳只做最基础的“加载引擎”和“通道桥接”。红包雨相关的所有判断、UI 表现、倒计时逻辑都和平台解耦。这样即使未来 Android 或 iOS 端也上线同样的活动只需把 Flutter 工程各自打包逻辑完全一致运营配置也只有一份。构建链路我们最终搭成了这样本地开发时Flutter 代码改动后直接在 VS Code 里跑flutter build ohos或者通过 DevEco 构建持续集成里再统一跑脚本。脚本会先执行 Dart 分析和单元测试通过后触发鸿蒙构建产出最终的 HAP 包几个平台共用一个主干效率比之前翻了一倍。有一点要提前坦诚现在 Flutter 适配鸿蒙的方案还在快速演进API 和目录结构每隔几个版本就可能微调。我写这篇时基于的适配分支是当时最新的稳定版你要是拿到的版本比我新一些个别细节比如插件名、平台目录可能会不一样。但整体架构思路和实现路径是通用的照着我这套拆解结构去对新的分支文档不会走偏。说到最后给我印象最深的一点是鸿蒙生态里 Flutter 的价值其实比在传统 Android 上更大。它让你不用为了一套活动页面专门储备一个鸿蒙原生团队也不用在业务爆发时临时抱佛脚学一门新语言用存量团队和存量代码就能快速覆盖新平台。红包雨这个项目做完团队里连原本对鸿蒙完全没概念的同事也能照着这套思路独立接手后续的节日活动了。如果你要做的活动页也是以 UI 交互为主完全可以按这篇的思路走一遍省下的时间比你想的多得多。