阅读视图

发现新文章,点击刷新页面。

彻底淘汰老旧 SVG 插件:unplugin-icons 与 Tailwind CSS v4 自定义图标最佳实践

最近在打包项目的时候发现打包极其的慢,直接vite打包栈溢出,打包失败 进行了一下排查,优化,最终发现罪魁祸首是 vite-plugin-svg-icons

主要原因是:loader 的时候每次都会完整构建一遍,复杂度随着项目文件数目和 svg 文件数目指数上升

  • 依赖极其老旧,停止维护:仓库最后一次更新定格在 4 年前。

  • 严重的性能与内存问题:由于其处理机制的问题,在大型项目中会导致打包极其缓慢,甚至出现栈溢出(OOM)报错(详见 Issue #112#124)。

  • 安全风险:安全扫描工具频频报出底层依赖的漏洞(详见 Issue #123)。

image.png

为了彻底解决这些痛点,我决定将图标系统重构。采用知名开源大佬 Anthony Fu (antfu) 维护的unplugin-icons来处理组件化图标,并结合最新的 Tailwind CSS v4 及 Iconify 官方插件来实现 CSS 类的自定义图标方案。这不仅极大提升了打包速度,还让图标的使用变得前所未有的灵活。

image.png

下面是详细的迁移与配置流程。

第一步:安装插件

pnpm i -D unplugin-icons

第二步:安装图标数据

使用 Iconify 作为图标数据源(支持 100+ 个图标集)

VS Code 用户:安装 Iconify IntelliSense 扩展以获得内联预览、自动完成和悬停信息

pnpm i -D @iconify/json

完整安装 这将安装所有图标集(约 120MB)。只有你实际使用的图标才会在生产环境中被打包。

安装单个图标集

仅安装你需要的图标集:

pnpm i -D @iconify-json/mdi @iconify-json/carbon

自动安装(实验性)

让 unplugin-icons 在你导入图标集时自动安装它们:

Icons({
  autoInstall: true, // Auto-detects npm/yarn/pnpm
})

构建工具配置

// vite.config.ts
import Icons from 'unplugin-icons/vite'

export default defineConfig({
  plugins: [
    Icons({ /* options */ }),
  ],
})

依据使用的框架配置 compiler 选项

Icons({ compiler: 'vue3' })

通过在导入路径中添加 ?raw 来将图标作为原始 SVG 字符串导入。适用于直接在 HTML 模板中嵌入 SVG。

<script setup lang='ts'>
import RawMdiAlarmOff from '~icons/mdi/alarm-off?raw&width=4em&height=4em'
import RawMdiAlarmOff2 from '~icons/mdi/alarm-off?raw&width=1em&height=1em'
</script>

<template>
  <!-- raw example -->
  <pre>
    import RawMdiAlarmOff from '~icons/mdi/alarm-off?raw&width=4em&height=4em'
    {{ RawMdiAlarmOff }}
    import RawMdiAlarmOff2 from '~icons/mdi/alarm-off?raw&width=1em&height=1em'
    {{ RawMdiAlarmOff2 }}
  </pre>
  <!-- svg example -->
  <span v-html="RawMdiAlarmOff" />
  <span v-html="RawMdiAlarmOff2" />
</template>

每一个图标就是一个组件

自定义图标

unplugin-icons 默认支持通过 @iconify/json 使用海量的开源图标库,但由于我们是从旧插件迁移,项目里肯定有大量业务专属的本地 SVG 文件。

我们需要通过 FileSystemIconLoader 来加载这些自定义图标。

// vite.config.ts
import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue' // 如果你使用的是 Vue
import Icons from 'unplugin-icons/vite'
import { FileSystemIconLoader } from 'unplugin-icons/loaders'
import tailwindcss from '@tailwindcss/vite'

export default defineConfig({
  plugins: [
    vue(),
    tailwindcss(), // Tailwind v4 的 Vite 插件
    
    // unplugin-icons 配置
    Icons({
      // 指定编译器,根据你的框架选择 'vue3', 'react', 'svelte' 等
      compiler: 'vue3', 
      autoInstall: true,
      customCollections: {
        // 这里的 'custom' 是你自定义图标集合的名称
        // 参数一是你本地 SVG 文件夹的相对路径
        // 参数二是可选的转换函数,通常用于将 svg 的 fill 或 stroke 替换为 currentColor 以支持 CSS 动态改色
        'custom': FileSystemIconLoader(
          './src/assets/svg', 
          svg => svg.replace(/^<svg /, '<svg fill="currentColor" ')
        ),
      },
    }),
  ],
})

使用方式为

import IconAccount from '~icons/my-icons/account'
import IconFoo from '~icons/my-other-icons/foo'
import IconBar from '~icons/my-yet-other-icons/bar'

使用解析器自动导入

使用自动导入时,注册你的自定义集合名称:

// vite.config.ts
IconResolver({
  customCollections: [
    'local',
    'my-other-icons',
    'my-yet-other-icons',
  ],
})

直接使用

<i-local-account/>

组件命名

图标按照以下命名规则自动导入:

{prefix}-{collection}-{icon}

prefix : 组件名称前缀(默认值: i )

collection : Iconify 集合 ID(例如, mdi 、 carbon 、 fa-solid )

icon : 图标名称(kebab-case)

自定义前缀

IconsResolver({
  prefix: 'icon', // Use 'icon' instead of 'i'
})
无前缀: false
  <icon-mdi-account />
 <mdi-account />

设置图标集别名

IconsResolver({
  alias: {
    park: 'icon-park',  // Use <icon-park-* /> instead of <icon-icon-park-* />
    fas: 'fa-solid',    // Use <icon-fas-* /> instead of <icon-fa-solid-* />
  }
})

配置 Tailwind CSS v4 及自定义图标(CSS 类方案)

安装

pnpm i -D @iconify/tailwind4

插件不包含图标。您需要添加要使用的图标集。

您也可以通过安装 @iconify-json/{prefix} 依赖项(其中"{prefix}"是图标集前缀)来仅安装您想要使用的图标集,例如 @iconify-json/mdi-light

Tailwind CSS v4 带来了革命性的变化,最大的区别就是去掉了 tailwind.config.js,所有的配置直接在 CSS/全局样式文件中通过 CSS At-rules(@规则)完成。

借助 @iconify/tailwind4 插件,我们不仅能用原子类写公共开源图标,还能直接把本地存放 SVG 的文件夹映射为 Tailwind 的原子类!

修改你的主 CSS 文件(例如 src/style.csssrc/main.css):

/* 引入 Tailwind v4 核心 */
@import "tailwindcss";

/* 1. 全局配置:直接引入完整的 Iconify 支持(如果需要用到海量开源图标) */
@plugin "@iconify/tailwind4";

/* 2. 自定义本地 SVG 配置 */
@plugin "@iconify/tailwind4" {
  /* from-folder(前缀名, 文件夹路径)
    这里我们将 src/assets/svg 文件夹映射为 `local` 集合
  */
  icon-sets: from-folder(local, "./src/assets/icons");
}

注意:Iconify 插件在底层会自动清理并优化 from-folder 加载的 SVG,如果图片是单色,它会自动转化为 mask,以完美支持 Tailwind 的 text-red-500 等颜色类名。

要使用图标,请为图标添加动态选择器,例如

<span class="icon-[mdi-light--home]"></span>

还可以自定义设置图标的前缀和大小(默认为1em)

@plugin "@iconify/tailwind4" {
  prefix: "iconify";
  scale: 1.2;
}

自定义图标

加载图标集有两种方法:

  • 加载以 IconifyJSON 格式预解析的图标集。
  • 加载本地文件夹中的所有svg文件

配置示例

@plugin "@iconify/tailwind4" {
  icon-sets: from-json(test, "./icon-sets/test.json"), from-folder(test2, "./icon-sets/svgs");
}

在 CSS 的插件配置中添加“icon-sets”选项,选项集以逗号分隔。

从 JSON 文件加载速度更快,因为无需进行清理操作

文件必须为 IconifyJSON 格式,可使用 Iconify Tools 生成。

如果您项目里的本地 SVG 图标非常多(比如几百上千个),每次项目启动时使用 from-folder 让 Vite 在运行时去逐个读取、清理和转化 SVG,依然会消耗一定的构建时间。

更优雅且极致的解决方案是:使用 Iconify 官方提供的 @iconify/tools,编写一个独立js脚本或是vite插件,将所有的本地 SVG 预先处理、压缩,并打包成一个 .json 文件。 之后无论是 Tailwind v4 还是 unplugin-icons,直接读取这个 JSON 文件即可,实现“零运行时开销”。

具体详细配置可查看文档@iconify/tools

弊端:脚本在处理文件时会把所有颜色都换成了 currentColor。如果你的图标全是单色的菜单 Icon,这很完美。但如果你的文件夹里混入了一个多色的插画 SVG(比如带有蓝色衣服、黄色帽子的彩色 Logo),经过脚本处理后,它会变成黑乎乎的一团(也就是失去了原本的彩色)

额外类名

每个图标有 2 个类名:

图标的类名,例如“mdi-light--home”。

渲染模式的类名:"iconify" 或 "iconify-color"(可配置)。

所有图标均遵循相同的规则,图片 URL 除外。

为避免代码重复,通用规则已被拆分为实用类。此外,这还允许您选择图标的渲染方式:

“iconify” 会将图标渲染为蒙版图像,因此图标会采用与文本相同的颜色。若要更改图标颜色,请更改文本颜色。此方法适用于未硬编码配色方案的图标。

“iconify-color” 将图标渲染为背景图像。此功能适用于具有硬编码调色板的图标。

为什么需要配置?

Tailwind CSS 的工作原理是查找代码中的类名,并为这些类名生成相应的 CSS 样式。

在使用动态类名(例如“icon-[mdi-light--home]”)时,Tailwind CSS 会查找所有此类类名,并将它们传递给插件以生成 CSS。这意味着插件知道使用了哪些图标,并仅加载所需的图标。

然而,当使用普通类名(例如“mdi-light--home”)时,Tailwind CSS 需要先通过插件为所有可能的类名生成 CSS,然后再在项目中查找类名,最后移除未使用的类名。这意味着插件必须为所有可能存在的图标生成 CSS。

为每个图标生成 CSS 并非快速的过程。鉴于可用的图标超过 275,000 个,这可能会耗费大量时间。此外,Tailwind CSS 会将所有内容保存在内存中,这可能会导致 Tailwind CSS 内存不足。为避免这种情况,您必须指定要使用的图标集列表。

配置完后直接通过类名生成图标

<i class="text-blue-500 text-xl icon-[local--user]" />

总结

通过移除四年前的 vite-plugin-svg-icons,并引入 unplugin-icons + @iconify/tailwind4

  1. 彻底告别了项目打包时的内存泄漏(OOM) ,打包速度肉眼可见地提升。
  2. 我们享受到了 antfuIconify 社区持续活跃维护带来的红利,告别了安全漏洞警告。
  3. 拥抱了下一代构建工具 Tailwind CSS v4 的极简 CSS 架构。

希望这篇文章能帮助正在使用老旧 Vben 等模板架构的开发者们成功渡劫!如果有问题,欢迎在评论区交流。

使用micro-app 多层嵌套的问题

micro-app 多层嵌套问题解决方案

版本说明:本文讨论的 micro-app 版本为截止发稿日期的最新版 1.0.0-rc.27

一、问题背景

1.1 业务场景

在实际开发中,我们遇到了一个三层嵌套的微前端场景:

基座应用 → 中间应用 → 子应用
  • 技术栈:Vue 3 + Vite
  • 架构层级:三层嵌套结构
  • 业务需求:中间应用和子应用需要进行频繁的数据交互的场景

1.2 官方文档说明

micro-app 官方文档针对 Vite 项目给出了使用 iframe 模式的建议: image.png 官方文档虽然提到了支持多层嵌套,但并未给出具体的实现示例和注意事项: image.png

1.3 问题现象

当中间层应用使用 iframe 模式时,第三层子应用会出现**栈溢出(Stack Overflow)**错误:

Maximum call stack size exceeded

image.png

这个问题在 GitHub Issues 中也有多人反馈,但官方尚未给出明确的解决方案。


二、问题原因分析

2.1 根本原因

经过深入分析和测试,问题的根本原因如下:

  1. 资源查找机制问题:当基座应用和中间层应用都启用 iframe 模式后,第三层子应用在查找 iframe 标签资源时,会向上查找父级应用。

  2. 循环查找导致栈溢出

    • 第三层应用向上查找时,找到的是基座应用而非中间层应用
    • 基座应用再次下发资源
    • 第三层应用继续向上查找
    • 形成无限循环,最终导致栈溢出
  3. iframe 标签的资源查找逻辑:micro-app 在处理 Vite 项目的 iframe 模式时,资源查找机制在多层级嵌套场景下存在缺陷。

2.2 测试验证

我们对不同技术栈和框架进行了测试,测试结果如下: image.png

基座应用 中间应用 子应用 是否出现栈溢出
Vite + iframe Vite + iframe Vite ❌ 是
Vite + iframe Vite + iframe Webpack ❌ 是
Vite + iframe Webpack Vite ✅ 否
Vite + iframe Webpack Webpack ✅ 否

结论:不论第三层使用什么技术栈,只要第二层(中间应用)使用了 iframe 模式,就会出现栈溢出问题。


三、解决方案

方案一:使用原生 iframe 标签(不推荐)

实现方式

第三层子应用使用原生的 `` 标签,而不是 micro-app 标签。

优点
  • ✅ 完全避免栈溢出问题
  • ✅ 实现简单,无需额外配置
缺点
  • ❌ 失去了 micro-app 的所有优势(样式隔离、JS 沙箱、通信机制等)
  • ❌ 需要重新实现微前端的各种能力
  • ❌ 与现有架构不兼容,需要大量改造工作
  • ❌ 性能较差,用户体验不佳
适用场景

仅适用于对微前端能力要求不高的简单嵌入场景。 不需要频繁的进行数据交互及ui风格统一等。


方案二:中间层不使用 iframe 模式(不推荐)

实现方式

中间层应用不使用 iframe 模式,改用 Webpack 构建或其他方式。

优点
  • ✅ 可以避免栈溢出问题
  • ✅ 保持 micro-app 的完整能力
缺点
  • ❌ 需要将 Vite 项目改回 Webpack,技术倒退
  • ❌ 失去 Vite 的快速构建和开发体验
  • ❌ 不符合当前主流技术趋势
  • ❌ 团队需要重新学习 Webpack 配置
适用场景

仅适用于可以接受技术栈变更的项目。


方案三:第三层使用基座应用的标签(推荐⭐)

这是本文重点推荐的解决方案,通过让第三层子应用直接使用基座应用的 micro-app 标签,绕过中间层的资源查找问题。

3.1 核心思路
  • 第三层子应用不再通过中间层应用加载
  • 直接使用基座应用的 micro-app 标签进行渲染
  • 通过基座应用实现中间层和子应用之间的通信
3.2 实现步骤
步骤一:将基座应用的 micro-app 挂载到全局

在基座应用中,将 micro-app 实例挂载到全局对象,以便子应用能够访问:

// 基座应用:main.js 或 bootstrap.js
import microApp from '@micro-zoe/micro-app';

// 权限校验函数(可选)
function accessMicroAppName(appName) {
  // 根据业务需求实现权限校验逻辑
  // 例如:检查当前子应用是否有权限访问指定的子应用
  return true;
}

// 将 micro-app 方法挂载到全局
window.microApp = {
  setData(...args) {
    if (!accessMicroAppName(args[0])) {
      return;
    }
    microApp.setData(...args);
  },

  addDataListener(...args) {
    if (!accessMicroAppName(args[0])) {
      return;
    }
    microApp.addDataListener(...args);
  },

  getData(...args) {
    if (!accessMicroAppName(args[0])) {
      return null;
    }
    return microApp.getData(...args);
  },

  removeDataListener(...args) {
    if (!accessMicroAppName(args[0])) {
      return;
    }
    microApp.removeDataListener(...args);
  },
};

注意事项

  • 建议添加权限校验,防止子应用越权访问
  • 可以根据业务需求选择性暴露方法
步骤二:基座应用设置动态标签名称

基座应用在初始化时,设置动态标签名称,并通过 setGlobalData 传递给子应用:

// 基座应用:micro-app 初始化
import microApp from '@micro-zoe/micro-app';

// 定义动态标签名称常量
const MICRO_APP_TAGNAME = 'micro-app-base';

// 初始化 micro-app
microApp.start({
  tagName: MICRO_APP_TAGNAME, // 使用自定义标签名
  lifeCycles: {
    // 生命周期钩子
  },
  preFetchApps: [
    // 预加载应用列表
  ],
});

// 通过 setGlobalData 将标签名传递给子应用
microApp.setGlobalData({
  microAppTagName: MICRO_APP_TAGNAME,
});

子应用接收 image.png

步骤三:中间层应用创建动态组件

在中间层应用中,创建一个动态组件,使用基座应用的标签名称:



  



import { ref, computed, onMounted } from 'vue';

interface Props {
  appName: string;
  appUrl: string;
  embedPath?: string;
  appData?: Record;
}

const props = defineProps();

// 从全局数据中获取基座应用的标签名
const microAppTagName = ref('micro-app');

// 监听全局数据变化,获取标签名
onMounted(() => {
  if (window.microApp) {
    window.microApp.addDataListener((data: any) => {
      if (data?.microAppTagName) {
        microAppTagName.value = data.microAppTagName;
      }
    }, true); // true 表示立即执行一次

    // 获取初始数据
    const globalData = window.microApp.getData();
    if (globalData?.microAppTagName) {
      microAppTagName.value = globalData.microAppTagName;
    }
  }
});

const handleDataChange = (e: CustomEvent) => {
  // 处理子应用数据变化
  emit('dataChange', e.detail.data);
};

const emit = defineEmits(['dataChange']);

简单版: image.png

步骤四:使用动态组件并传递参数

在中间层应用的页面中,使用动态组件:



  <div class="sub-app-container">
    
  </div>



import { ref, watch } from 'vue';
import MicroApp from './MicroApp.vue';

const subAppName = ref('sub-app-name');
const subAppUrl = ref('https://sub-app.example.com');
const embedPath = ref('/page1'); // 通过 default-page 传递路由参数
const appData = ref({});

// 监听参数变化,更新子应用
watch(embedPath, (newPath) => {
  // 参数变化时,子应用会自动更新
});

const handleSubAppDataChange = (data: any) => {
  // 处理子应用数据变化
  console.log('子应用数据变化:', data);
};

简版: image.png

步骤五:实现参数传递和数据通信

中间层应用通过基座应用的 setData 方法向子应用传递数据:

// 中间层应用:参数传递
import { ref } from 'vue';

const embedPath = ref('/page1');

// 更新子应用参数
const updateSubAppPath = (newPath: string) => {
  embedPath.value = newPath;

  // 通过基座应用向子应用传递数据
  if (window.microApp) {
    window.microApp.setData(subAppName.value, {
      path: newPath,
      timestamp: Date.now(),
    });
  }
};

// 监听子应用数据变化
if (window.microApp) {
  window.microApp.addDataListener((data: any) => {
    console.log('收到子应用数据:', data);
    // 处理子应用返回的数据
  }, subAppName.value);
}

image.png

3.3 方案优势
  • 解决栈溢出问题:第三层直接使用基座应用的标签,绕过中间层的资源查找
  • 保持微前端能力:仍然可以使用 micro-app 的所有功能
  • 支持频繁交互:通过基座应用实现中间层和子应用之间的数据通信
  • 避免白屏问题:子应用不会因为参数变化而重新加载,提升用户体验
  • 支持多子应用:每个子应用都可以使用独立的标签,互不干扰
  • 技术栈兼容:支持 Vite + Vue 3 技术栈
3.4 注意事项
  1. 通信机制:中间层应用和子应用的通信需要通过基座应用进行,不能直接通信
  2. 权限控制:建议在基座应用中实现权限校验,防止子应用越权访问
  3. 标签名称:确保基座应用的标签名称唯一,避免冲突
  4. 数据管理:需要合理设计数据传递机制,避免数据混乱
3.5 架构示意图
┌─────────────────────────────────────┐
│           基座应用                   │
│  ┌───────────────────────────────┐  │
│  │  micro-app (tagName: 'base')  │  │
│  │  ┌─────────────────────────┐  │  │
│  │  │    中间层应用             │  │  │
│  │  │  ┌───────────────────┐  │  │  │
│  │  │  │  动态组件          │  │  │  │
│  │  │  │             │  │  │  │
│  │  │  │    ┌───────────┐  │  │  │  │
│  │  │  │    │ 子应用    │   │  │  │  │
│  │  │  │    └───────────┘  │  │  │  │
│  │  │  └───────────────────┘  │  │  │
│  │  └─────────────────────────┘  │  │
│  └───────────────────────────────┘  │
└─────────────────────────────────────┘

四、方案对比

方案 解决栈溢出 保持微前端能力 技术栈兼容 实现复杂度 推荐度
方案一:原生 iframe ⭐⭐
方案二:中间层不用 iframe ⭐⭐⭐ ⭐⭐
方案三:使用基座标签 ⭐⭐⭐⭐ ⭐⭐⭐⭐⭐

五、总结

5.1 问题根源

micro-app 1.x 版本在处理 Vite 项目的多层嵌套场景时,当中间层应用使用 iframe 模式,会导致第三层子应用在资源查找时出现循环查找,最终引发栈溢出。

5.2 最佳实践

推荐使用方案三:让第三层子应用直接使用基座应用的 micro-app 标签,通过基座应用实现中间层和子应用之间的通信。这样既解决了栈溢出问题,又保持了微前端的完整能力。

5.3 注意事项

  1. 确保基座应用的标签名称唯一且可配置
  2. 实现完善的权限校验机制
  3. 合理设计数据传递和通信机制
  4. 注意处理子应用的生命周期管理

5.4 未来展望

希望 micro-app 官方能够在后续版本中:

  • 修复多层嵌套场景下的资源查找问题
  • 提供更完善的多层嵌套示例和文档
  • 优化 Vite 项目的 iframe 模式支持

【更新】有人已经给出了解决方案,大家如果遇到同类问题,可以用此方案试试~ github.com/jd-opensour…

image.pnggithub.com/jd-opensour…

企业微信截图_5798ebde-4dc0-4c49-a0b2-4eb23d46cb9a.png

六、参考资料


SwiftUI路由管理架构揭秘:从混乱到优雅的蜕变

引言

想象一下:当你打开一个 App,点击不同标签页,切换页面时,所有导航状态都能完美保持;当你从详情页返回时,TabBar 能智能地重新出现;当你需要传递数据时,类型安全的导航能让你告别字符串硬编码的烦恼。这一切,都离不开一个优秀的路由管理架构。

在现代 iOS 应用开发中,路由管理常常被视为"基础设施"而被忽视,但其重要性却不亚于任何核心功能。一个设计良好的路由系统,不仅能让代码结构更清晰,还能显著提升用户体验。今天,我将带大家深入剖析我项目中的路由管理架构,分享从设计到实现的全过程,希望能为你的项目带来启发。

路由架构概览

我项目的路由管理基于 SwiftUI 的 NavigationStackNavigationPath,采用了集中式的路由管理方案。核心组件包括:

  • Router 类:全局导航路由器,管理所有 Tab 的导航路径
  • MainTab 枚举:定义应用的标签页结构
  • MainContainerView:主容器视图,负责整合标签页和导航逻辑
  • App 启动注入:在应用启动时将 Router 注入到环境中

路由的启动注入

EviApp.swift 中,我们通过 @StateObject 创建 Router 实例,并通过 environmentObject 将其注入到应用环境中:

import SwiftUI

@main
struct EviApp: App {
    // 把 AppDelegate 接进来,系统会照常调用 didFinishLaunchingWithOptions 等
    @UIApplicationDelegateAdaptor(AppDelegate.self) var appDelegate
    
    // 全局弹框管理器
    @StateObject private var overlay = GlobalOverlayManager.shared
    // 全局导航路由器
    @StateObject private var router = Router()
    
    var body: some Scene {
        WindowGroup {
            MainContainerView()
                .environmentObject(overlay)
                .environmentObject(router)
        }
    }
}

这样,在应用的任何视图中,都可以通过 @EnvironmentObject 来访问 Router 实例,实现全局路由管理。

核心组件分析

1. Router 类:路由管理的核心

import SwiftUI

/// 全局导航路由器,管理所有Tab的导航路径
class Router: ObservableObject {
    
    // 当前选中的Tab
    @Published var selectedTab: MainTab = .home
    
    // 为每个tab单独存储NavigationPath
    @Published var homePath = NavigationPath()
    @Published var hotPath = NavigationPath()
    @Published var creationPath = NavigationPath()
    @Published var stylePath = NavigationPath()
    @Published var profilePath = NavigationPath()
    
    // MARK: - 获取导航路径
    
    /// 获取指定tab的导航路径
    func getNavigationPath(for tab: MainTab) -> NavigationPath {
        switch tab {
        case .home: return homePath
        case .hot: return hotPath
        case .creation: return creationPath
        case .style: return stylePath
        case .profile: return profilePath
        }
    }
    
    /// 获取指定tab的导航路径绑定
    func getNavigationPathBinding(for tab: MainTab) -> Binding<NavigationPath> {
        switch tab {
        case .home: return binding(for: \.homePath)
        case .hot: return binding(for: \.hotPath)
        case .creation: return binding(for: \.creationPath)
        case .style: return binding(for: \.stylePath)
        case .profile: return binding(for: \.profilePath)
        }
    }
    
    // MARK: - 清空导航路径
    
    /// 清空指定tab的导航路径
    func clearPath(for tab: MainTab) {
        switch tab {
        case .home: clear(\.homePath)
        case .hot: clear(\.hotPath)
        case .creation: clear(\.creationPath)
        case .style: clear(\.stylePath)
        case .profile: clear(\.profilePath)
        }
    }
    
    /// 清空所有导航路径
    func clearAllPaths() {
        clear(\.homePath)
        clear(\.hotPath)
        clear(\.creationPath)
        clear(\.stylePath)
        clear(\.profilePath)
    }
    
    // MARK: - 当前Tab操作
    
    /// 获取当前选中Tab的导航路径
    func getCurrentNavigationPath() -> NavigationPath {
        return getNavigationPath(for: selectedTab)
    }
    
    /// 获取当前选中Tab的导航路径绑定
    func getCurrentNavigationPathBinding() -> Binding<NavigationPath> {
        return getNavigationPathBinding(for: selectedTab)
    }
    
    /// 清空当前选中Tab的导航路径
    func clearCurrentPath() {
        clearPath(for: selectedTab)
    }
    
    // MARK: - 私有辅助方法
    
    /// 创建导航路径的绑定
    private func binding(for keyPath: ReferenceWritableKeyPath<Router, NavigationPath>) -> Binding<NavigationPath> {
        Binding {
            self[keyPath: keyPath]
        } set: {
            self[keyPath: keyPath] = $0
        }
    }
    
    /// 清空指定的导航路径
    private func clear(_ keyPath: ReferenceWritableKeyPath<Router, NavigationPath>) {
        self[keyPath: keyPath].removeLast(self[keyPath: keyPath].count)
    }
}

设计亮点

  • 集中管理:所有路由逻辑集中在一个类中,便于统一管理
  • Tab 隔离:为每个标签页维护独立的导航路径,确保切换标签时不会影响其他标签的导航状态
  • 响应式设计:使用 @Published 修饰符,实现路由状态的自动更新
  • 便捷方法:提供了丰富的方法来操作导航路径,如获取路径、清空路径等

2. MainTab 枚举:标签页定义

import SwiftUI

/// 主标签栏枚举
enum MainTab {
    case home
    case hot
    case creation
    case style
    case profile
}

extension MainTab {
    
    /// 根据选中状态返回对应的图标名称
    func iconName(isSelected: Bool) -> String {
        switch self {
        case .home:
            return isSelected ? "tabbar_home_sel" : "tabbar_home_nor"
        case .hot:
            return isSelected ? "tabbar_hot_sel" : "tabbar_hot_nor"
        case .creation:
            return "tabbar_add"
        case .style:
            return isSelected ? "tabbar_style_sel" : "tabbar_style_nor"
        case .profile:
            return isSelected ? "tabbar_me_sel" : "tabbar_me_nor"
        }
    }
}

设计亮点

  • 类型安全:使用枚举定义标签页,避免了字符串硬编码
  • 扩展功能:通过扩展为枚举添加了获取图标名称的功能,使代码更整洁

3. MainContainerView:路由的实际应用

import SwiftUI

/// 主容器视图,包含悬浮TabBar
struct MainContainerView: View {
    
    // 获取指定tab的导航路径
    private func getNavigationPath(for tab: MainTab) -> NavigationPath {
        return router.getNavigationPath(for: tab)
    }
    
    /// 创建带有NavigationStack的标签页视图
    private func tabView(_ tab: MainTab) -> some View {
        NavigationStack(path: router.getNavigationPathBinding(for: tab)) {
            switch tab {
            case .home:
                HomeView()
            case .hot:
                HotHomeView()
            case .creation:
                CreationHomeView()
            case .style:
                StyleHomeView()
            case .profile:
                ProfileHomeView()
            }
        }
        .tag(tab)
    }
    
    @StateObject private var appConfigManager = AppConfigManager.shared
    
    @EnvironmentObject private var overlay: GlobalOverlayManager
    @EnvironmentObject private var router: Router
    
    var body: some View {
        if appConfigManager.appConfig != nil {
            ZStack {
                
                // 真正负责页面生命周期的容器
                TabView(selection: $router.selectedTab) {
                    tabView(.home)
                    tabView(.hot)
                    tabView(.creation)
                    tabView(.style)
                    tabView(.profile)
                }
                
                // 你的悬浮TabBar,根据当前选中标签的导航路径长度控制显示
                if isTabBarVisible {
                    VStack {
                        Spacer()
                        FloatingTabBar(selectedTab: $router.selectedTab)
                            .padding(.horizontal, 16)
                            .padding(.bottom, 20)
                    }
                }
                
                // 全局弹框显示
                if let current = overlay.current {
                    
                    // 遮罩
                    Color.black.opacity(0.4)
                        .ignoresSafeArea()
                        .onTapGesture {
                            overlay.dismiss()
                        }
                    
                    switch current {
                    case .login:
                        LoginOverlayView(onClose: {
                            overlay.dismiss()
                        })
                        .transition(.flipFromBottom)
                    }
                }
                
            }
            .animation(.easeInOut(duration: 0.25), value: overlay.current)
        } else {
            // 显示空View
            EmptyView()
                .background(ThemeManager.Background.global)
        }
    }
    
    var isTabBarVisible: Bool {
        return getNavigationPath(for: router.selectedTab).count == 0
    }
}

设计亮点

  • NavigationStack 集成:为每个标签页创建独立的 NavigationStack
  • TabBar 智能显示:根据当前导航路径长度控制 TabBar 的显示/隐藏
  • 环境对象注入:使用 @EnvironmentObject 注入 Router,实现全局访问
  • 动画效果:添加了平滑的过渡动画,提升用户体验

路由管理的实现细节

1. 路径管理机制

路由系统的核心是 NavigationPath 的管理。NavigationPath 是 SwiftUI 4.0+ 引入的类型,它是一个类型擦除的容器,可以存储任意类型的导航目的地。

在我们的实现中:

  • 每个标签页都有自己的 NavigationPath 实例
  • 通过 getNavigationPathBinding 方法获取路径的绑定,用于 NavigationStack
  • 提供了 clearPathclearAllPaths 方法来清空导航路径

2. 标签页切换逻辑

当用户切换标签页时:

  1. router.selectedTab 的值会更新
  2. TabView 会根据新的 selectedTab 显示对应的标签页
  3. 由于每个标签页有独立的 NavigationPath,切换标签不会影响其他标签的导航状态

3. 导航路径的实际使用

在具体的视图中,可以通过以下方式使用路由:

// 在视图中注入 Router
@EnvironmentObject private var router: Router

// 使用全局路由管理进行导航
let currentPath = router.getCurrentNavigationPathBinding()
// 向当前路径添加新页面
currentPath.wrappedValue.append(AppNavigationDestination.materialDetail(material))

// 清空当前标签页的导航路径
router.clearCurrentPath()

4. 导航目的地定义

项目使用 AppNavigationDestination 枚举来定义导航目的地:

import Foundation
import SwiftUI

/// 导航目标枚举
enum AppNavigationDestination: Hashable {
    case accountLogin
    case materialDetail(MaterialListDTOElement)
}

这种方式的优势:

  • 类型安全:使用枚举定义导航目的地,避免了字符串硬编码
  • 参数传递:可以在导航时传递相关数据,如 materialDetail 中的 MaterialListDTOElement
  • 可扩展性:可以轻松添加新的导航目的地

5. NavigationStack 中处理导航目的地

在使用 NavigationStack 时,需要处理导航目的地的显示逻辑。通常在根视图中添加 navigationDestination 修饰符:

NavigationStack(path: router.getNavigationPathBinding(for: tab)) {
    HomeView()
        .navigationDestination(for: AppNavigationDestination.self) { destination in
            switch destination {
            case .accountLogin:
                AccountLoginView()
            case .materialDetail(let material):
                MaterialDetailView(material: material)
            }
        }
}

这样,当我们通过 currentPath.wrappedValue.append(AppNavigationDestination.materialDetail(material)) 导航时,NavigationStack 会自动显示对应的目标视图。

6. 完整导航流程示例

下面是一个完整的导航流程示例,展示从触发导航到显示目标页面的全过程:

// 1. 在视图中注入 Router
@EnvironmentObject private var router: Router

// 2. 定义导航触发事件
Button("查看素材详情") {
    // 3. 获取当前路径绑定
    let currentPath = router.getCurrentNavigationPathBinding()
    // 4. 向路径添加导航目的地
    currentPath.wrappedValue.append(AppNavigationDestination.materialDetail(selectedMaterial))
}

// 5. 在根视图中处理导航目的地
NavigationStack(path: router.getNavigationPathBinding(for: .home)) {
    HomeView()
        .navigationDestination(for: AppNavigationDestination.self) { destination in
            switch destination {
            case .materialDetail(let material):
                MaterialDetailView(material: material)
            default:
                EmptyView()
            }
        }
}

// 6. 从详情页返回
Button("返回") {
    // 清空当前路径,返回根视图
    router.clearCurrentPath()
}

7. 导航路径与 TabBar 显示的关联

MainContainerView 中,通过 isTabBarVisible 计算属性控制 TabBar 的显示:

var isTabBarVisible: Bool {
    return getNavigationPath(for: router.selectedTab).count == 0
}

当导航路径为空时(即处于标签页的根视图),显示 TabBar;当导航路径不为空时(即进入了子页面),隐藏 TabBar,为用户提供更大的内容显示区域。

优势与最佳实践

优势

  1. 清晰的职责分离:路由逻辑与 UI 逻辑分离,使代码更易于维护
  2. 类型安全:使用枚举和类型化的导航路径,减少运行时错误
  3. 状态管理:集中管理路由状态,避免状态分散
  4. 灵活性:可以轻松添加新的标签页和导航目的地
  5. 用户体验:标签页切换时保持各自的导航状态,提升用户体验

最佳实践

  1. 统一的路由入口:所有导航操作都通过 Router 进行,避免直接操作 NavigationPath
  2. 合理的路径清理:在适当的时机清理导航路径,避免内存占用过高
  3. 导航目的地的类型定义:为导航目的地创建明确的类型,提高代码可读性
  4. 错误处理:添加适当的错误处理,确保导航操作的稳定性
  5. 测试:为路由逻辑编写单元测试,确保其正确性

代码优化建议

  1. 导航目的地类型化

    // 建议为每个标签页创建导航目的地枚举
    enum HomeDestination {
        case detail(id: String)
        case search
    }
    
    // 然后在导航时使用
    router.homePath.append(HomeDestination.detail(id: "123"))
    
  2. 添加导航日志

    // 添加导航日志,便于调试和分析用户行为
    func appendToPath(_ value: some Hashable, for tab: MainTab) {
        let path = getNavigationPathBinding(for: tab)
        path.wrappedValue.append(value)
        print("Navigate to \(value) in tab \(tab)")
    }
    
  3. 导航路径持久化

    // 可以考虑在应用进入后台时保存导航状态,在应用启动时恢复
    func saveNavigationState() {
        // 保存导航状态到 UserDefaults 或其他存储
    }
    
    func restoreNavigationState() {
        // 从存储中恢复导航状态
    }
    
  4. 添加路由拦截器

    // 可以添加路由拦截器,用于处理登录验证等场景
    func appendToPath(_ value: some Hashable, for tab: MainTab) {
        if needsAuthentication(for: value) {
            // 显示登录界面
            overlay.present(.login)
        } else {
            let path = getNavigationPathBinding(for: tab)
            path.wrappedValue.append(value)
        }
    }
    

总结

通过以上分析,我们可以看到,一个良好的路由管理架构对于 iOS 应用的重要性。我项目中的路由架构采用了集中式管理、Tab 隔离、响应式设计等原则,通过 Router 类、MainTab 枚举和 MainContainerView 的配合,实现了清晰、灵活、用户友好的导航体验。

这种路由架构不仅适用于当前项目,也可以作为其他 SwiftUI 项目的参考。通过不断优化和扩展,可以构建更加完善的路由系统,为用户提供更加流畅的应用体验。

希望这篇文章能够帮助大家更好地理解和实现 iOS 项目中的路由管理架构。如果你有任何问题或建议,欢迎在评论区留言讨论!

❌