SwiftRate这个项目目前已经跑通了一个相对完整的闭环应用基于Flutter开发UI层与业务逻辑层分离在HarmonyOS 6.0设备上完成了适配和性能调优。整个开发过程中最让我意外的不是汇率接口的对接也不是图表绘制而是常用货币对这个看似不起眼的模块它牵扯到的数据模型设计、排序策略、持久化方案和交互细节远比想象中复杂。这篇文章就把这个模块从需求拆解到代码落地的全过程完整拆开包括我踩过的坑和最终采用的方案。如果你也在做汇率类应用或者正在纠结Flutter应用如何适配HarmonyOS 6.0这篇内容大概率能帮你省下几天时间。1. 常用货币对模块到底在解决什么问题1.1 为什么这个功能值得单独拿出来讲先说说我最初的想法。做汇率转换应用第一反应往往是先把汇率数据拉下来做个简单的换算页面然后重点打磨图表和资讯模块。但实际开发后发现用户打开应用后第一眼看到的、每天反复操作的恰恰是首页展示的那几个常用货币对。如果用户每次都要从几十种货币里手动挑选才能完成一次换算这个应用基本上就等于没有首页。常用货币对模块本质上是在帮用户做决策预处理——把最高频、最关心的货币对提前放到眼前。这个模块的体验好坏直接决定了用户对整款应用的第一印象。在设计SwiftRate时我对这个模块定了几个硬指标冷启动后300毫秒内展示出最近一次使用的货币对列表支持用户自定义排序且排序结果在杀掉进程后依然保留汇率刷新时列表不能出现白块、闪烁或明显的跳动这些指标看着简单真正实现时每一步都有坑。1.2 技术选型Flutter和HarmonyOS 6.0的契合点SwiftRate之所以选择Flutter核心原因是跨端一致性和渲染性能。汇率应用的核心页面是数字密集型界面数字变化非常频繁需要在刷新时保证画面稳定。Flutter自带的Skia渲染引擎在文本和数字绘制上有天然优势加上Dart的AOT编译UI线程的压力远小于传统的WebView方案。而HarmonyOS 6.0在分布式能力和系统调度上做了不少优化Flutter引擎运行在上面整体帧率表现可以接受。这里有一点值得多说一句HarmonyOS 6.0对Flutter的支持已经不再是简单的兼容层系统侧提供了原生的Ability生命周期管理和事件分发能力。也就是说Flutter应用可以通过平台通道直接感知到应用前后台切换、窗口焦点变化等系统事件这在实现汇率后台刷新策略时非常关键。1.3 本篇文章的核心线索整篇文章会以一条主线展开从货币对的数据模型设计开始到推荐排序算法再到汇率数据链路和交互实现最后是HarmonyOS 6.0适配时踩过的具体问题。每个环节都会给出可以直接照抄的代码片段和填坑经验尤其是那些不跑一遍根本发现不了的细节问题。2. 货币对数据模型设计字段、精度与扩展性2.1 一个货币对到底需要存哪些字段一开始我设计的货币对模型特别简单只有基础货币代码和目标货币代码。代码大概长这样class CurrencyPair { final String baseCurrency; final String quoteCurrency; }写完后很快发现不够用。首页列表要把货币名称、国旗图标、货币符号、小数点精度都展示出来。汇率行情卡片还要展示涨跌幅、日高日低、更新时间等字段。如果每次渲染列表都去全局货币表里现查不仅代码冗余还会产生额外的查找开销。后来我重构了模型把展示层字段和业务层字段分离开。业务层仍然只关心货币代码展示层的数据通过一个单独的扩展类去组装。这样做的好处是排序逻辑和汇率换算逻辑只依赖代码不依赖任何展示字段保证核心逻辑稳定。class CurrencyPairDisplay { final String baseCurrency; final String quoteCurrency; final String pairKey; // 形如 USD/CNY final String baseSymbol; final String quoteSymbol; final String baseFlagPath; final String quoteFlagPath; final int precision; final double orderWeight; }2.2 货币元数据表符号、精度和数字格式化的统一处理汇率转换最让人头疼的问题之一就是小数精度不一致。日元的汇率精度需要0大多数法币需要2位小数而一些数字货币可能需要6位甚至8位。如果全用同一个格式化规则页面会显得特别凌乱。SwiftRate里维护了一张货币元数据表以货币代码为key存了货币符号、默认精度、千分位分隔符样式等信息货币代码货币符号默认精度千分位分隔备注USD$2启用美元CNY¥2启用人民币JPY¥0不启用日元EUR€2启用欧元GBP£2启用英镑精度字段直接决定了汇率数字和换算结果在页面上的呈现格式。这个表本身是静态数据不会频繁变更所以用const Map硬编码放在代码里避免了首启时的异步加载。2.3 推荐排序算法不是单纯按使用次数排常用货币对的排序算法是整个模块的灵魂。市面上很多应用的做法是最近使用优先这个策略的问题在于如果用户只是偶尔一次查了个冷门货币它会瞬间排到最前面打乱用户习惯的视觉顺序。我采用的方案是加权计分排序double calculateOrderWeight({ required int baseWeight, required int recentUseCount, required int searchClickCount, }) { return baseWeight * 0.6 recentUseCount * 0.3 searchClickCount * 0.1; }基础权重在货币元数据表里预设比如USD、CNY、EUR这类全球主流货币权重很高冷门货币权重低。最近使用次数和搜索点击次数则来自本地埋点数据。每次计算排序时把当前货币对列表按加权分从大到小排序分数相同的按更新时间排。这个策略的好处是比较稳一次偶然的查询不会破坏整体排序结构用户的习惯性操作始终占据主导位置。2.4 持久化方案SharedPreferences够用但要注意写入频率用户自定义排序、最近使用次数、搜索点击次数这些数据都需要持久化。SwiftRate里用量级很轻的SharedPreferences方案来存JSON字符串没上数据库因为数据量实在不大。真正需要注意的不是存储方案选型而是写入频率。拖拽排序时如果每次移动都触发一次持久化写入会频繁唤醒磁盘IO在低端鸿蒙设备上会有肉眼可见的卡顿。我的做法是拖拽结束后延时500毫秒统一写入一次并且用debounce机制避免连续操作时的重复写入。void persistPairOrder() { orderSaveTimer?.cancel(); orderSaveTimer Timer(const Duration(milliseconds: 500), () { prefs.setString(pair_order, jsonEncode(currentOrder)); }); }这个优化做完后拖拽流畅度提升非常明显。3. 常用货币对的推荐与自定义静态与动态的平衡3.1 冷启动时的默认货币对列表首次安装打开应用时用户还没有任何操作历史这时需要一个合理的默认货币对列表兜底。SwiftRate的默认列表是USD/CNY、EUR/USD、USD/JPY、GBP/USD、EUR/CNY、USD/HKD。这组默认值是综合了跨境支付、留学汇款、旅游消费、外贸结算等几个常见场景选出来的基本覆盖了大多数用户可能的需求。冷启动时如果本地没有持久化数据就直接返回这组默认值。这里有个细节默认列表不要硬编码在UI层而是放在一个PairRepository仓库类里统一管理这样后续发版调顺序只需要改一处。3.2 用户主动增删货币对的交互设计列表页右上角放了添加按钮点击后弹出一个全屏的货币选择器。货币选择器按大洲和币种分区排列上方是搜索框支持货币代码和中文名称的模糊搜索。删除操作则直接使用长按弹出底部菜单的方式。考虑到移动端误触概率高删除操作会二次确认而不是直接移除。增删操作的数据流向货币选择器确认后新货币对插入到列表第二位第一位是用户最高频货币对如果高频货币对被删了就自动把第二位移上来并同步更新持久化数据。这里额外做了一个限制一个列表中最多展示9个货币对。超过9个后按钮置灰并提示用户删除后再添加。这么做是从排版角度考虑的9个卡片在手机上刚好超过一屏半再多就会导致页面加载过重。3.3 合并静态规则和动态行为的排序器排序器是独立的一个类叫PairOrderManager。它接收三类输入静态基础权重表本地埋点统计数据当前用户手动固定的置顶标记输出是一个最终的排序数组。内部逻辑其实不复杂但有一个容易踩坑的地方手动置顶和权重排序的冲突。如果一个用户手动置顶了A货币对权重排序又认为B货币对比A更常用到底听谁的我的方案是置顶标记拥有绝对优先级置顶的货币对始终排在最前剩余货币对继续按权重排。这个逻辑虽然简单粗暴但确实最符合用户直觉。ListCurrencyPairDisplay sortPairs(ListCurrencyPairDisplay pairs) { final sorted ListCurrencyPairDisplay.from(pairs); sorted.sort((a, b) { final pinnedA pinnedPairs.contains(a.pairKey); final pinnedB pinnedPairs.contains(b.pairKey); if (pinnedA ! pinnedB) { return pinnedA ? -1 : 1; } return b.orderWeight.compareTo(a.orderWeight); }); return sorted; }3.4 埋点统计的采集方式与去重策略为了支撑排序算法SwiftRate需要在本地记录用户行为。采集的事件只有两类货币对曝光进入首页时记录列表中的货币对滚动时也触发一次和货币对点击用户点击某个货币对查看详情时触发。采集数据落本地每类事件最多保留最近90天数据超出部分直接丢弃。数据格式是一个Mapkey是pairKeyvalue是最近30天内的累计次数。一个大坑是曝光事件去重。如果用户在首页停留3分钟每秒钟触发一次曝光事件数据就废了。我的做法是设置去重窗口同一个货币对在1小时内重复曝光只算一次且只在页面从后台恢复到前台时重新计时。4. 汇率数据链路从网络请求到页面展示4.1 汇率源的选型与数据格式约定汇率数据源我最终选择了自己搭服务器做中间层。原因有两个一是避免把第三方API的密钥直接暴露在客户端里二是可以在服务端做一层汇率缓存和聚合降低客户端对第三方服务的依赖频率。服务端返回的JSON格式如下{ pair: USD/CNY, rate: 7.2245, timestamp: 1720000000, change_pct: 0.12, high_24h: 7.2310, low_24h: 7.2100 }客户端拿到数据后直接按pair字段索引缓存到内存里。展示时只需要做一次Map查找复杂度是O(1)。4.2 刷新链路的状态机设计汇率刷新不是简单的一个请求搞定。我的做法是把它抽成了一个状态机idle空闲状态没有进行中的刷新任务refreshing刷新中已有请求在途success刷新成功数据已更新error刷新失败保留旧数据在refreshing状态下如果用户手动触发刷新会直接丢弃事件不做任何请求。这样可以防止用户疯狂点击刷新按钮导致请求雪崩。同时还有一个自动刷新计时器每10分钟触发一次。计时器只在应用处于前台时运行应用切到后台后自动暂停回到前台时先判断上次刷新时间是否超过10分钟如果超过就立即静默刷新一次。4.3 缓存策略内存缓存、本地缓存和展示层缓存的层次关系汇率缓存分了三层第一层是内存缓存。一个MapString, ExchangeRate存最新的汇率数据供首页列表渲染直接用。内存缓存的优势是速度极快但进程被杀就丢。第二层是本地缓存。每次从服务端拿到数据后同步写入SharedPreferences存成JSON串。冷启动时先用本地缓存渲染列表再异步请求最新数据数据返回后更新页面。第三层是图片缓存。货币国旗图片资源量不小几十个国家的小图标加起来也有几百KB做的处理是把图片全量打进应用包里不通过网络加载彻底规避了图片加载导致的闪烁问题。三层缓存联动后SwiftRate的冷启动流程变成了读本地缓存并立即渲染 - 同时异步发起网络请求 - 拿到新数据后平滑更新。4.4 离线状态下怎么保证基本可用汇率应用的离线方案很容易被忽略但实际用户场景里很常见地铁里没信号打开应用发现汇率还是上一次的数据只要标注清楚时间就行。SwiftRate的离线策略如果检测到网络不可用页面顶部显示一条淡淡的横幅提示当前为离线数据更新时间为xx:xx列表继续用本地缓存渲染让换算操作不受影响。提示条是可以通过点击手动关闭的且每次离线状态重新进入才展示一次避免反复打扰。5. 常用货币对页面的核心交互实现5.1 首页列表的布局与滚动性能首页列表用了Flutter自带的ListView.builder配合RepaintBoundary对每个卡片做渲染隔离。卡片数量最多9个所以没有做特别复杂的懒加载但仍然需要注意一个问题汇率数字变化时如果卡片没有隔离重绘会导致整页重建。每个汇率卡片内部把数字区域单独抽成了一个RateNumberText组件继承StatelessWidget只监听汇率数据变化时才重建自身。这样每秒一次的汇率刷新动画也只影响卡片内部的数字区域不会拖累整个页面的帧率。5.2 拖拽排序的手势识别和视觉反馈List排序可以复用ReorderableListView但在HarmonyOS 6.0上遇到过体验问题拖拽时的阴影和位移不够跟手。后来改成了自己实现拖拽排序使用LongPressDraggable配合DragTarget实现。核心思路是每个卡片外包一层LongPressDraggable拖拽数据是当前卡片的下标。当某个卡片被拖动且经过另一个卡片时触发位置交换逻辑视觉上通过真实的数组重排来表现位置变化而不是简单的固定占位符。这个方案实现成本略高但体验确实更好。拖拽过程中卡片会有轻微放大效果松手后回弹到正常大小。5.3 展开式汇率行情卡片列表里的卡片默认只显示汇率数字和涨跌幅点击卡片后展开显示当日最高价、最低价和一条简单的6小时趋势图。展开动画用的是AnimatedSize组件展开和收起都带高度动画。这个组件有一个容易踩的坑如果卡片高度是动态的显式指定高度变化区间会导致动画闪烁。正确做法是让AnimatedSize根据子组件自然高度自动过渡不要手动设置height。5.4 货币选择器的分组和搜索实现货币选择器的核心是一个CustomScrollView顶部是搜索框下面是大洲分组的列表。分组数据直接硬编码在代码里按大洲分成6个section亚洲、欧洲、北美洲、南美洲、非洲、大洋洲。搜索时使用简单的contains匹配匹配字段为货币代码和中文名称。搜索时是全部打平展示不分组。搜索这里有一个性能优化点如果输入的关键词为空直接清空搜索结果并展示分组列表如果关键词长度超过1才触发过滤逻辑。6. 在 HarmonyOS 6.0 上适配Flutter的实测记录6.1 生命周期事件与刷新策略的联动HarmonyOS 6.0对应用前后台切换的管理方式和Android原生体系有明显差异。尤其是应用切后台后Flutter引擎不会立即暂停而是继续运行一段时间如果不对刷新计时器做处理就会出现切后台后还在偷偷请求汇率数据。最终的做法是监听系统侧回调事件并把结果通过平台通道同步给Dart层。事件类型有四种onHiddenChange应用被完全隐藏onWindowFocusChanged窗口失去焦点onAbilityWillMoveToBackground即将进入后台notificationBarPanelStatusChange状态栏下拉接收到事件后Dart层的刷新管理器根据事件类型暂停或恢复自动刷新计时器。6.2 文本渲染与数字动态更新可能遇到的适配问题在HarmonyOS 6.0上跑Flutter文本测量和字体渲染这块刚开始有不少小问题。最典型的表现是同样的一个汇率数字在Android上是垂直居中的在鸿蒙上会偏上或偏下几个像素。排查后发现是系统字体回退机制导致的。HarmonyOS 6.0默认字体在部分数字字形上跟Flutter的默认字体度量有差异。解决方法是给所有数字文本组件统一指定字体族和fontFeatures并且在文本组件上显式设置字重和中线对齐方式。另一个更隐蔽的问题是局部刷新时文本溢出。当汇率数字从7.2245变为7.2310时如果宽度没有预留足够余量会出现数字被截断的情况。我给数字文本组件加了一个强制约束最小宽度固定为当前字体大小对应8个数字1个小数点的宽度。6.3 低内存场景下的Channel通信稳定性问题在鸿蒙设备上测试时发现一个奇怪的现象内存压力较大时Dart层调用平台通道偶尔会超时导致汇率刷新失败。针对这个问题我给平台通道的调用增加了一层超时保护和重试机制。每次调用Native方法时设置3秒超时超时后自动降级为不调用Native仅依赖本地缓存。重试次数最多2次超过后不再继续。超时机制代码FutureT invokeWithTimeoutT(MethodChannel channel, String method, [MapString, dynamic? arguments]) async { return channel .invokeMethodT(method, arguments) .timeout(const Duration(seconds: 3)) .catchError((e) { return FutureT.error(e); }); }这个改动在低端鸿蒙设备上效果明显至少没有再出现过刷新过程白屏卡死的情况。6.4 性能实测帧率、内存占用和启动耗时最后说一组实际数据供参考。测试机型为中端鸿蒙6.0设备测试场景是反复进入退出首页、反复拖拽排序和持续自动刷新1小时。指标优化前优化后首页冷启动耗时1.4秒0.9秒列表滑动帧率45帧58帧拖拽排序帧率38帧55帧内存峰值320MB268MB1小时自动刷新失败率2.3%0.6%启动耗时的大头优化来自于本地缓存的预加载和图片资源的本地化。内存峰值的下降则主要归功于图片缓存复用和ListView的懒加载。6.5 这个模块还可以怎么扩展SwiftRate的常用货币对模块目前已经完全跑通处于稳定维护状态。后续如果继续做有几个方向值得思考。第一智能预测排序。结合用户一天内的时间因素比如早上用户可能更关注汇率波动大的货币对下午可能更关注固定列表。这个方向需要更细颗粒度的行为数据采集以及一套在线侧的轻量规则引擎。第二跨设备同步。HarmonyOS 6.0主打的分布式能力如果能和常用货币对排序打通比如手表上查看汇率数据时自动同步手机端的常用列表会是一个不错的加分项。第三多语言场景扩展。当前货币名称支持中英文后续可以加入更多语言。翻译数据的结构要考虑好。做这个模块最大的感悟是汇率应用看着是一个工具型应用但真正决定产品口碑的恰恰是那些用户每天都在用的基础模块。把常用货币对这类小事做到极致比堆砌大而全的图表模块更能留得住用户。