Flutter for OpenHarmony: Flutter 三方库 icon_font_generator 自动化将 SVG 图标集转化为字体文件(鸿蒙矢量资源全自动管理)

Flutter for OpenHarmony: Flutter 三方库 icon_font_generator 自动化将 SVG 图标集转化为字体文件(鸿蒙矢量资源全自动管理)

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net

请添加图片描述

前言

在 OpenHarmony 应用中,为了保证在不同分辨率屏幕(手机、折叠屏、平板)下图标都能保持绝对清晰,且为了减小 HAP 包体积,使用“字体图标”取代“位图图片”是业界公认的标准方案。

icon_font_generator 是一个强大的命令行工具。它能将一整组 SVG 图标自动打包成一个 .ttf 字体文件,并同步生成 Dart 类。开发者只需关注 SVG 文件的增删,剩余的同步工作全部自动化。

一、全自动构建链路

命令行扫描

强类型访问

assets/ohos_icons/*.svg (原始素材)

icon_font_generator

assets/fonts/OhosIcons.ttf (单字体文件)

lib/generated/ohos_icons.dart (自动生成类)

鸿蒙 Flutter UI

在鸿蒙开发中,我们绝不推荐手写 IconData 的内存地址。通过以下流程,可以实现资产的自动化转换:

1. 准备 SVG 素材

将设计师导出的 .svg 图标文件统一放入工程资产目录:

  • 存储路径:assets/ohos_icons/*.svg

2. 执行自动化构建指令

在项目根目录运行以下命令,工具会自动扫描 SVG、生成字体文件并创建 Dart 调用类:

# 💡 核心指令:一键生成鸿蒙图标资产 flutter pub run icon_font_generator \ --from=assets/ohos_icons \ --to=assets/fonts/OhosIcons.ttf \ --out=lib/generated/ohos_icons.dart \ --class-name=OhosIcons 

3. 在 pubspec.yaml 中注册

生成的 .ttf 必须在配置文件中声明方可生效:

flutter:fonts:-family: OhosIcons fonts:-asset: assets/fonts/OhosIcons.ttf 

二、核心 API 实战

2.1 字体图标基础加载

通过工具生成的静态变量,你可以像使用 Icons.home 一样访问自定义图标,无需记忆十六进制代码。

// 💡 核心 API: 访问生成的自定义图标 (OhosIcons 为自动生成的类)Icon(OhosIcons.home, size:24, color:Colors.blue)
在这里插入图片描述

2.2 自定义图标样式

字体图标本质上是文本。它们可以完美支持颜色叠加、阴影、渐变以及混合模式。

// 💡 核心 API: 为字体图标添加特定的阴影效果Icon(OhosIcons.scanner, shadows:[Shadow(color:Colors.black26, offset:Offset(0,4), blurRadius:10)],)
在这里插入图片描述

2.3 动态映射图标

当图标选择来自后端(如后台配置的任务列表)时,配合 Map 映射表,可以极大地简化业务逻辑。

// 💡 核心 API: 建立 API 响应与字体图标的动态映射staticconstMap<String,IconData> iconMapping ={'home':OhosIcons.home,'user':OhosIcons.person,};
在这里插入图片描述

三、OpenHarmony 平台适配

3.1 资产注册注意

在鸿蒙工程中,生成的 .ttf 文件必须在 pubspec.yamlfonts 节点下正确声明,且 family 名称必须与生成的 Dart 代码中 fontFamily 固定值完全匹配,否则会出现显示为“方块(乱码)”的问题。

3.2 高刷性能优势

💡 提示:相比于加载大量的 .png 图片导致鸿蒙设备主线程解码压力过大,字体图标加载极为迅速。在滑动长列表(如金刚区菜单)时,字体图标几乎不会造成任何掉帧(Jank)。

四、完整实战示例:鸿蒙风格图标资产中心

本示例演示如何通过模拟生成的 OhosIcons 类构建一套标准的鸿蒙金刚区菜单系统。

classOhosIconMenuextendsStatelessWidget{@overrideWidgetbuild(BuildContext context){returnGridView.count( crossAxisCount:4, children:[_buildItem(OhosIcons.scanner,"扫一扫"),_buildItem(OhosIcons.payment,"钱包"),_buildItem(OhosIcons.message,"行程"),_buildItem(OhosIcons.settings,"更多"),],);}Widget_buildItem(IconData icon,String label){returnColumn( children:[// 💡 字体图标加载性能极佳Icon(icon, color:Colors.blueAccent, size:30),Text(label, style:TextStyle(fontSize:12)),],);}}
在这里插入图片描述

五、总结

icon_font_generator 将 OpenHarmony 应用的资源管理提升到了自动化水平。它通过单一字体文件解决了碎片化图片的管理难题,不仅极大地优化了应用的运行性能,还统一了 UI 层的调用标准。对于任何追求极致轻量化和视觉一致性的鸿蒙项目,这都是一套必选的基本建设。

Read more

【算法】连通块问题(C/C++)

【算法】连通块问题(C/C++)

目录 连通块问题 解决思路 步骤: 初始化: DFS函数: 复杂度分析  代码实现(C++) 题目链接:2060. 奶牛选美 - AcWing题库 解题思路: AC代码:  题目链接:687. 扫雷 - AcWing题库  解题思路: AC代码: 总结: 连通块问题 连通块问题(Connected Component Problem)是一个经典的图论问题,通常用来找出图中的所有连通分量。给定一个无向图,连通块问题的目标是确定图中有多少个连通分量(即有多少个互相连通的节点组成的集合) 解决思路 1. 深度优先搜索(DFS) 或 广度优先搜索(BFS): * 可以从任意未访问的节点出发,进行DFS或BFS,标记所有能够访问到的节点,代表这个连通分量。 * 重复这个过程,直到所有节点都被访问为止。每次从新的未访问节点出发时,就代表发现了一个新的连通分量。 2.

By Ne0inhk
【C++:继承】C++面向对象继承全面解析:派生类构造、多继承、菱形虚拟继承与设计模式实践

【C++:继承】C++面向对象继承全面解析:派生类构造、多继承、菱形虚拟继承与设计模式实践

🔥艾莉丝努力练剑:个人主页 ❄专栏传送门:《C语言》、《数据结构与算法》、C/C++干货分享&学习过程记录、Linux操作系统编程详解、笔试/面试常见算法:从基础到进阶 ⭐️为天地立心,为生民立命,为往圣继绝学,为万世开太平 🎬艾莉丝的简介: 🎬艾莉丝的C++专栏简介: 目录 C++的两个参考文档 4  ~>  派生类的默认成员函数专题 4.4  实现一个不可继承类实现 4.4.1  间接实现:【C++98】构造函数私有的类不能被继承 4.4.2  直接实现:final关键字修改基类 4.4.3  代码实现 4.4.4  final关键字

By Ne0inhk
c++之inline关键字从基础到通天(一篇即毕业系列)

c++之inline关键字从基础到通天(一篇即毕业系列)

文章目录 * inline 是一个请求(而非命令) * inline 函数通常用于小函数 * inline 函数的定义通常放在头文件中 * inline 函数不能包含复杂的控制结构 * 编译器可能忽略 inline 请求 * 验证是否 inline * 代码块 * 汇编代码分析 * 其他验证方法 * 推荐阅读 欢迎收看一篇即毕业系列,本系列的其它内容如同本篇一样优秀喔!! 那么话不多说! 关于 inline,我们直接了解以下几个知识点即可。 inline 是一个请求(而非命令) inline 关键字用于向编译器发出一个请求,建议将函数体在每个调用点内联展开。这意味着编译器在编译过程中,可能会将函数的代码直接插入到调用该函数的地方,而不是通过通常的函数调用机制来执行。 需要注意的是,inline 只是一个建议,编译器可以选择是否接受这个建议。编译器可能会基于多种因素(如函数的大小、复杂性、调用频率以及整体代码的优化目标)来决定是否进行内联展开。 inline 函数通常用于小函数 inline 函数通常用于那些执行速度快且调用频繁的小

By Ne0inhk
从二叉树到 STL:揭开 set 容器的本质与用法

从二叉树到 STL:揭开 set 容器的本质与用法

前言:         上次介绍完二叉搜索树后,更新中断了一段时间,先向大家致歉。最近学习状态有些起伏,但我正在努力调整,相信很快会恢复节奏。今天我们继续深入探讨——关联容器,它在算法和工程中都非常常见和重要。 1.之前的遗漏         我之前写的二叉搜索树其实没有写完,我仅仅写了一个节点只能存储一个值的二叉搜索树。在我们日常的工作中,这种树的使用率其实还是比较低的。最受欢迎的是里面存储两个值的二叉搜索树,这个可以类比Python中的字典。相信学过python的读者对此不陌生,字典其实存放了一对值,分别是Key和Value,类比英文字典中的英语和汉字,我们通过英文(Key)来找到对应的中文(Value)。这其实才是我们常使用到的二叉搜索树,下面我通过举例来帮助各位理解这两棵树的区别。 1.1.Key搜索场景         举个例子,现在很多小区配有地下停车库。业主的车牌号会录入系统中,车辆进入时由系统识别并判断是否允许进入。这就是典型的 Key 搜索场景 —— 只需根据一个关键字(车牌号)进行查找。 1.2.Key/Value搜索场景         还是以我们

By Ne0inhk