01-超级App软件平台@路由规则设计-【总纲】

本文介绍软件平台的路由规则设计，不限于移动端，涵盖 移动端（手机、平板）、Web、电脑（桌面）、手表与手环等智能穿戴。结合官方文档与业界实践，系统介绍路由的理论、演进与工程实现；软件体系覆盖 iOS、Android、HarmonyOS、Flutter、MacOS、WinOS、WebApp、ReactNative、WatchOS 及智能穿戴形态，适用于多端统一路由架构设计参考。

---

一、引言与定义

1.1 什么是软件平台路由

软件平台路由（Software Platform Routing）指在任意端态的应用内部，根据某种规则（通常是 URL、Path 或路由名）将请求解析并分发到对应页面、视图、组件或服务的过程。其本质是「地址 → 目标」的映射与执行链路，是模块化、组件化架构下解耦与导航的基础设施。

覆盖范围（不限于移动端）：

端态	说明	典型平台/形态
移动端	手机、平板上的原生或跨平台 App	iOS、Android、HarmonyOS、Flutter、ReactNative
Web	浏览器内的单页/多页应用、PWA	WebApp、History/Hash 路由、React Router / Vue Router
电脑（桌面）	桌面操作系统上的应用	MacOS、WinOS
手表、手环等智能穿戴	手表、手环及其他可穿戴设备上的应用	WatchOS、HarmonyOS 穿戴、第三方手环/手表系统

• 狭义：页面/视图跳转（如 Activity、ViewController、Widget、Web 路由、穿戴界面栈）。
• 广义：除页面外，还包括功能唤醒（调用能力、获取服务、打开弹窗/浮层、执行动作等）、跨进程通信、Web 与 Native 互跳等，即「通过统一入口到达任意可寻址能力」。

本专题同时考虑两类路由诉求：

路由类型	含义	典型场景	执行结果
页面跳转路由	根据 path 打开一个完整页面/视图并压栈或替换	列表→详情、设置页、Web 内路由切换	导航栈变化，用户看到新页面
功能唤醒路由	根据 path 触发某种能力或获取某种服务，不必然打开整页	打开分享面板、调起登录弹窗、获取用户服务实例、执行埋点/动作、打开浮层、调用模块能力	可能无新页面（仅执行逻辑）、或弹出模态/浮层、或返回服务实例

功能唤醒示例：/action/share 调起分享、/service/user 获取用户服务、/modal/login 打开登录弹窗、/action/track 执行埋点。与页面跳转共用同一套 path 协议与路由表，通过 路由项类型（page / action / service）区分执行方式。

在超级 App 或跨端统一产品（日活千万级、多业务线、多端发布）中，路由还承担动态下发、权限控制、埋点与降级等职责，成为稳定性与性能的关键环节。[^1]

1.2 为什么需要路由规则

需求	说明
解耦	调用方不依赖目标页面的具体类名或模块，仅依赖「路径」协议。
统一入口	外部（H5、推送、短链）与内部跳转共用一套规则，便于运营与数据分析。
动态化	通过服务端下发路由表或配置，实现 A/B 测试、活动页替换、降级。
可观测	所有跳转经统一路由层，便于埋点、鉴权与监控。
同体系跨端协同	同一产品在手机、Web、电脑、手表等多端共用 path 协议，一条链接多端一致打开、设备间可接力与状态同步。

1.3 同体系跨端跨平台协同

同体系指同一产品/业务域下的多端应用（如同一款 App 的 iOS 版、Android 版、Web 版、手表版、桌面版）。跨端跨平台协同要求路由设计在体系内保持一致，使同一 path 在不同端打开同一业务目标，并在需要时实现设备间协同。

协同维度	含义	路由设计要点
协议统一	各端采用同一套 path、query、路由类型（页面/功能唤醒）规范	统一 path 命名空间（如 /app/detail/:id），各端适配层将 path 映射到本端页面或能力
同一链接多端一致	同一 URL/path 在 Web 打开即 Web 页，在 App 打开即 App 页，在手表打开即手表页	深链接与 Web URL 使用相同 path；各端路由表对同一 path 指向等价业务目标
跨端互跳与续传	Web 跳 App、App 跳 Web、「在电脑上继续」等	通过 Universal Links / App Links / 自定义 Scheme 传递 path+query；未安装时 Web 承载，安装后 App 打开同一 path
设备间路由同步	手表与手机、手机与电脑等同一用户多设备间路由状态或意图同步	手表点击某 path 可同步到手机打开；或通过服务端/账号侧记录「当前 path」，多端拉取后一致展示
配置与表跨端一致	路由表、动态下发、降级策略在体系内统一或可按端裁剪	服务端按端态下发路由配置；path 冲突检测、灰度在同一体系内统一管理

上述协同建立在统一 path 协议与各端适配层之上：协议保证「说什么」，适配层保证「在各端怎么做」；同体系内 path 语义一致，跨端链接、接力与状态同步才可行。详见 08-软件体系与多平台路由对照 与 07-通用路由管理组件设计。

参考：鸿蒙超级终端思想（HarmonyOS 超级终端）
华为鸿蒙提出的超级终端，强调多设备像「一台设备」一样协同工作，而非简单互联。其核心依赖分布式软总线（设备发现与连接）、分布式数据管理（跨设备数据与状态同步）、分布式任务调度（任务与界面在设备间迁移、硬件能力共享）。与本专题的对应关系可理解为：统一 path 协议相当于在应用层约定「同一任务/同一目标」的寻址方式；设备间路由同步与接力（同一 path 在多端打开、续传）对应分布式任务调度与「在另一台设备上继续」；路由表与配置跨端一致则支撑跨设备状态与能力的一致体验。设计多端路由时，可借鉴超级终端「一个账号、多设备一体」的理念，让 path 成为跨端任务与状态迁移的公共契约。参见 08-软件体系与多平台路由对照 中「鸿蒙超级终端与路由设计」小节。

同体系跨端协同示意（同一 path 在多端一致打开，设备间可同步/接力）：

flowchart LR
    subgraph 同体系
        P[统一 path 协议]
    end
    subgraph 多端
        A[iOS App]
        B[Android App]
        C[Web]
        D[桌面]
        E[手表]
    end
    subgraph 协同
        F[同一链接 多端一致打开]
        G[设备间 path 同步 接力]
    end
    P --> A
    P --> B
    P --> C
    P --> D
    P --> E
    A --> F
    B --> F
    C --> F
    A --> G
    E --> G

1.4 路由规则全貌（思维导图）

mindmap
  root((软件平台路由规则设计))
    端态 不限于移动端
      移动端 Web 电脑 手表手环等穿戴
    定义与价值
      地址到目标的映射
      解耦 统一入口 动态化 可观测
    路由类型
      页面跳转 打开整页/压栈
      功能唤醒 能力/服务/弹窗/动作
    三要素
      Path / URL
      路由表
      导航方式
    路由表来源
      编译期 APT
      运行时注册
      动态下发
    执行链路
      解析 path query
      查表
      拦截器链
      执行跳转或服务
    同体系跨端协同
      协议统一 同一链接多端一致
      跨端互跳 设备间路由同步
    多平台 九端
      iOS Android HarmonyOS
      Flutter MacOS WinOS
      WebApp ReactNative WatchOS
    超级 App 扩展
      SPI 按需 分层表
      拦截器并行与熔断
      编译期校验

---

二、历史演进

2.1 阶段概览

timeline
    title 软件平台路由技术演进（多端）
    原生直接引用 : 硬编码类名跳转 : 强耦合、难维护
    URL Scheme / Intent : 系统级跨应用与深链接 : 深链接雏形
    组件化与路由框架 : ARouter、MGJRouter 等 : 注解 + 路由表
    声明式与 Navigator 2.0 : 状态驱动、Web 对齐 : Flutter / 现代 Web 路由
    超级 App 路由体系 : 动态表、分层缓存、拦截链 : 千万级 DAU 实践

2.2 各阶段简述

1. 原生直接引用（2010 年前后）
   直接 startActivity(new Intent(this, TargetActivity.class)) 或 pushViewController(TargetVC())。模块间强依赖，难以支持 H5/运营链接统一跳转。

2. URL Scheme / Intent Filter（约 2010–2015）

   • iOS：myapp://page/detail?id=1，在 Info.plist 声明 CFBundleURLSchemes。
   • Android：<intent-filter> 声明 scheme + host + path，通过 Intent.ACTION_VIEW 打开应用并解析 Uri。
     实现了「链接 → 打开 App」的深链接雏形，但 Scheme 易冲突、无法校验归属，且部分容器（如微信）会拦截自定义 Scheme。[^2][^3]

3. Universal Links / App Links（2015 至今）

   • iOS Universal Links：使用 HTTPS URL（如 https://example.com/detail/1），通过 apple-app-site-association 证明域名归属，系统级跳转、可突破部分容器限制。[^2]
   • Android App Links：同样基于 HTTPS + assetlinks.json 验证，Android 6.0+ 支持，可免歧义对话框。[^4]
     深链接从「自定义 Scheme」升级为「可验证的 Web URL」，与 Web 和 SEO 对齐。

4. 组件化路由框架（约 2015–2020）
   为解决多模块、多团队下的解耦与编译隔离，出现基于注解 + 编译期代码生成的路由框架：

   • ARouter（阿里）：APT 扫描 @Route 生成路由表，支持分组、拦截器、服务发现。[^5][^6]
   • MGJRouter、JLRoutes（iOS）等：运行时注册 URL → Block，配合 Scheme 做统一跳转。
     特点：编译期生成映射、避免反射、支持按模块分组加载。

5. 声明式路由与 Navigator 2.0（2020 至今）

   • Flutter Navigator 2.0：路由栈由「状态」驱动，通过 Router、RouteInformationParser、RouterDelegate 将 URL 解析为 List<Page>，便于深链接、多 Tab、复杂返回栈。[^7][^8]
   • go_router 等：在 Navigator 2.0 之上封装 path/query、redirect、refreshListenable，与 Web 路由语义一致。

6. 超级 App 路由体系（大厂实践）
   在 ARouter 等基础上，针对冷启动、内存、拦截链延迟、AGP 升级等问题，演进为：

   • 动态 SPI / 按需加载路由表；
   • 热/温/冷分层路由表（LRU 内存 → MMAP → SQLite）；
   • 拦截器并行化与超时熔断；
   • 编译期路由冲突校验与动态下发。[^1]

---

三、核心概念与原理

3.1 路由三要素与路由类型

要素	含义	示例
Path / URL	唯一标识一个目标（页面或能力/服务）	/detail, /action/share, myapp://goods/123
路由表（Route Table）	Path → 目标（页面 Class、Handler、服务工厂、Action）的映射	Map<Path, RouteMeta> 或生成类
导航方式	如何执行目标：页面用 push/replace/present；功能唤醒用 invoke/getService/openModal 等	由路由项类型与框架决定

路由类型（同一 path 协议下区分执行方式）：

类型	说明	典型执行方式
页面跳转	打开一个完整页面/视图，改变导航栈	push、replace、present
功能唤醒	触发能力、获取服务、打开弹窗/浮层、执行动作，不必然打开整页	getService、invokeAction、openModal、openOverlay

3.2 路由表从何而来

• 编译期生成：通过 APT（Annotation Processing Tool）扫描 @Route(path = "/detail") 等注解，生成如 ARouter$$Group$$main 的类，在初始化或首次访问时加载。[^5][^6]
• 运行时注册：应用启动或模块加载时调用 register(path, handler)，将 path 写入内存表。
• 动态下发：从服务端拉取 JSON 路由表，覆盖或合并本地表，实现活动页、灰度、降级。[^9]

3.3 拦截器链（Interceptor Chain）

路由在「查表 → 执行」之间，通常插入拦截器链，用于：

• 登录态校验、权限检查
• 埋点、风控
• 降级（如目标不可用时跳转兜底页）
• 异步预处理（如预拉取数据）

链式结构便于按优先级顺序执行与提前中断（如未登录则拦截并跳转登录页）。在千万级 App 中，拦截器会做并行/异步化与超时熔断，以控制主线程阻塞与跳转延迟。[^1]

3.4 深链接与路由的衔接

• 外部：用户点击 Universal Link / App Link / 短链 → 系统或 WebView 打开 App，并传入 URL。
• 内部：App 将 URL 交给路由层解析：
  • 解析 path、query、fragment；
  • 查路由表得到目标页面或 Action；
  • 经拦截器后执行跳转或服务调用。

因此，统一的路由规则是「外链进 App」与「App 内跳转」一致性的基础。

深链接与 App 内路由的关系可概括为：

flowchart TB
    subgraph 外部
        A["Universal Link / App Link / 短链"]
    end
    subgraph App 内
        B["系统 / WebView 唤起 App 并传入 URL"]
        C["路由层解析 path + query"]
        D["查路由表 → 拦截器 → 执行跳转"]
    end
    A --> B
    B --> C
    C --> D

---

四、路由匹配算法

4.1 问题抽象

给定一个输入路径（如 /user/123/profile）和一组路由规则（可能含静态段、动态段、正则），求：

• 命中的规则；
• 解析出的参数（如 userId=123）。

4.2 常见规则类型

• 静态路径：/home、/setting，精确匹配。
• 动态段：/user/:id、/detail/[id]，一段匹配任意非空字符串。
• 正则：如 \/user\/\d+，用于更复杂约束（部分框架如 TheRouter 支持）。[^9]
• 通配符：/file/*，匹配剩余 path。

4.3 路由匹配算法（伪代码）

以下给出一种基于分段 + 优先精确匹配的算法，与常见路由库（如 go_router、Express）思路一致。

算法：RouteMatch(path, routeTable)
输入：path（如 "/user/123/profile"），routeTable（规则列表，每条含 pattern、handler、priority）
输出：匹配的 route 及解析出的 params，若无则返回 null

1. 将 path 按 '/' 分割为 segments[]，去掉首尾空串
2. 将 routeTable 按优先级排序（精确 > 动态 > 通配符）
3. FOR EACH route IN routeTable:
     a. 将 route.pattern 按 '/' 分割为 patternSegments[]
     b. 若 patternSegments.length != segments.length 且 route 非通配符，则 CONTINUE
     c. params = {}
     d. FOR i = 0 TO min(segments.length, patternSegments.length) - 1:
          - 若 patternSegments[i] 以 ':' 或 '[' 开头，则视为动态段，params[name] = segments[i]
          - 否则若 patternSegments[i] != segments[i]，则 BREAK 内层循环，CONTINUE 外层
     e. 若全部段匹配（或通配符匹配成功），返回 (route, params)
4. 返回 null

复杂度：规则数 R，路径段数 S，单次匹配 O(R·S)。生产环境会通过 Trie 或树形结构 将公共前缀合并，减少比较次数；带正则时需在命中候选后再做正则校验。[^10]

4.4 路由表查找结构示意

flowchart LR
    subgraph 输入
        A["path: /user/123"]
    end
    subgraph 路由表结构
        B["Trie / Map"]
        C["/user/:id"]
        D["/user/list"]
    end
    A --> B
    B --> C
    B --> D
    C --> E["RouteMeta + params(id=123)"]

4.5 匹配示例（伪代码）

以 path = /user/123 与两条规则 /user/list、/user/:id 为例：

segments = ["user", "123"]
规则1: patternSegments = ["user", "list"] → 第二段 "list" != "123"，不匹配
规则2: patternSegments = ["user", ":id"]  → 第二段为动态段，params["id"] = "123"，匹配
→ 返回 (RouteMeta(DetailPage), { id: "123" })

---

五、路由执行流程（含拦截器）

整体流程可概括为：解析 → 查表 → 拦截链 → 执行。下图给出带拦截器的路由执行流程。

sequenceDiagram
    participant C as 调用方
    participant R as Router
    participant T as RouteTable
    participant I as InterceptorChain
    participant H as Handler/Page

    C->>R: navigate(path, params)
    R->>R: 解析 path + query
    R->>T: lookup(path)
    T-->>R: RouteMeta
    R->>I: process(meta, callback)
    loop 拦截器
        I->>I: 校验/埋点/权限
        alt 拦截
            I-->>C: onInterrupt()
        end
    end
    I->>H: 执行跳转或服务调用
    H-->>C: 完成

---

六、多平台路由机制概览（九大平台）

本专题软件体系覆盖 iOS、Android OS、HarmonyOS、Flutter、MacOS、WinOS、WebApp、ReactNative App、WatchOS。下表为各平台深链接与 App 内路由的简要对照，详见 08-软件体系与多平台路由对照。

平台	深链接机制	App 内路由 / 导航
iOS	URL Scheme + Universal Links	Router 单例、UINavigationController、push/present
Android	Intent Filter + App Links	ARouter/TheRouter、startActivity、Fragment
HarmonyOS	Want / scheme、HTTPS 关联	路由表、router.pushUrl、页面栈
Flutter	宿主配置 + app_links	Navigator 2.0、go_router
MacOS	URL Scheme + Universal Links（同 iOS）	NSWindow/ViewController、与 iOS 类似
WinOS	协议关联、启动参数	Frame.Navigate、框架内路由
WebApp	同源/多域即“深链接”	History / Hash、React Router / Vue Router
ReactNative	原生 Scheme + App Links，Linking API	React Navigation、linking 配置
WatchOS	简化 Scheme、与 iPhone 协同	简化路由、WKInterfaceController

6.1 iOS

• URL Scheme：Info.plist 中 CFBundleURLSchemes，打开 myapp://path。[^2]
• Universal Links：域名下配置 apple-app-site-association，App 内通过 NSUserActivity（NSUserActivityTypeBrowsingWeb）接收 URL 并交给路由层解析。[^2][^3]
• App 内路由：多为基于 URL 的 Target-Action 或 Router 单例，将 URL 映射到 UIViewController 或工厂 Block。

6.2 Android

• Intent + Intent Filter：<data android:scheme="myapp" android:host="page" android:pathPrefix="/detail" />，通过 Intent.getData() 获取 Uri 并解析。[^4]
• App Links：HTTPS + assetlinks.json 验证，自动打开 App 无选择框。[^4]
• 路由框架：ARouter、TheRouter 等通过注解生成路由表，path 对应 Activity/Fragment 或服务。

6.3 Flutter

• Navigator 1.x：命令式 push/pop，MaterialApp.routes + onGenerateRoute 做命名路由与参数传递。[^11]
• Navigator 2.0：声明式，由 Router、RouteInformationParser、RouterDelegate 将 RouteInformation（如 URL）解析为 List<Page>，再交给 Navigator.pages。[^7][^8]
• go_router：封装 path/query、redirect、refreshListenable，与 Web 与深链接场景对齐。[^11]

6.4 HarmonyOS

• 深链接：通过 Want 的 uri 或 scheme 打开指定 Ability；支持 HTTPS 关联配置，思路与 Android App Links 相近。
• App 内路由：Stage 模型下使用路由表或注解将 path 映射到页面 Ability，通过 router.pushUrl() 等 API 导航；可与统一 Router 协议对齐（path + query）。

6.5 MacOS

• 深链接：与 iOS 类似，在 Info.plist 中配置 URL Scheme；支持 Universal Links（同一 AASA 域名）。
• App 内路由：使用 NSWindow、NSViewController 或 SwiftUI 窗口栈；可复用与 iOS 一致的 path 协议与 Router 门面，适配层实现 openPage/replacePage 为窗口或 VC 切换。

6.6 WinOS

• 深链接：通过包清单或注册表关联自定义协议；部分场景使用启动参数传递 path/query。
• App 内路由：WinUI / WPF / UWP 等框架内使用 Frame.Navigate 或等效 API；适配层将 path 映射到对应 Page/View，与统一 Router 协议对齐。

6.7 WebApp

• “深链接”：即 URL 本身（同源或多域）；通过 location.pathname、searchParams 获取 path 与 query。
• 路由：SPA 使用 History API 或 Hash 路由；React Router、Vue Router 等维护 path 与组件的映射，与 Native 共用 path 规范可实现 H5 与 App 内同一套 path。

6.8 ReactNative App

• 深链接：依赖原生 iOS/Android 的 URL Scheme 与 App Links 配置；在 JS 层通过 Linking API（getInitialURL、addEventListener）接收 URL，再交给 React Navigation 的 linking 配置解析为路由 state。
• App 内路由：React Navigation 声明式维护导航 state；与统一 Router 协议对齐时，可将 path + query 作为 linking 的 path 规范，各端共用一套 path。

6.9 WatchOS

• 深链接：多与 iPhone 端协同，使用简化 URL Scheme 或通过 Watch Connectivity 传递 path；一般不单独配置 Universal Links。
• App 内路由：界面层级较浅，可用简单路由表或少量界面名映射；适配层可实现精简版 openPage（如 push 到指定 WKInterfaceController），与主 App 共用 path 规范便于联动。

---

七、超级 App 路由设计要点（业界实践）

以下要点综合自腾讯云开发者社区对「千万级 APP 路由系统」的拆解 [^1]、阿里 ARouter [^5][^6]、货拉拉 TheRouter [^9]、滴滴 DRouter [^12] 等公开资料。

7.1 动态 SPI 与按需加载

• 问题：ARouter 全量加载路由表，模块多时类加载与 DEX 扫描耗时长（如 1.2s+），影响冷启动。
• 思路：按模块使用 SPI（ServiceLoader）或类似机制，在首次访问某模块时再加载该模块的路由表并合并。
• 效果：启动耗时与内存占用显著下降（文中示例：1.2s → 300ms，内存约降 60%）。[^1]

7.2 分层路由表（防 OOM）

• 热路由：最近访问的 path 放在内存（如 LRU，约 1000 条、30 分钟过期）。
• 温路由：周访问 ≥N 次的放在 MMAP 文件。
• 冷路由：低频路由放 SQLite，按需加载。
  → 在保证命中率的前提下控制内存占用，避免路由表过大导致 OOM。[^1]

7.3 拦截器并行与熔断

• 并行：将可异步的拦截器（如埋点、日志）并行执行，仅强依赖顺序的（如鉴权 → 业务）保持顺序；文中示例 200ms → 80ms。[^1]
• 熔断：为单次路由执行设超时（如 500ms），超时则 onInterrupt，避免长时间阻塞主线程。

7.4 编译期路由冲突校验

• 在 Gradle 构建阶段收集所有 @Route 的 path，若存在重复则构建失败并报冲突 path。
• 可将线上路由冲突故障率压到接近 0。[^1]

7.5 动态下发与安全

• 路由表 JSON 由服务端下发，支持按版本、灰度覆盖本地表。
• 差分更新（如 BSDiff）、签名校验（RSA + CRC32）、降级开关（回退本地表）是常见做法。[^1]

7.6 框架能力对比（简表）

能力	ARouter	TheRouter	DRouter
动态路由下发	✓	✓	✓
路径正则匹配	✗	✓	✓
跨进程通信	✗	✗	✓
模块自动初始化	✗	✓	✓

资料来源：公开技术博客与社区文章 [^1][^9][^12]。

---

八、应用场景小结

页面跳转类：

• App 内页面跳转：Tab、首页入口、列表进详情等，统一走路由。
• H5 / 运营链接：同一套 path 规则，H5 跳 Native 或 Native 打开 H5。
• 推送 / 短链：点击后解析 URL，经路由打开对应页并带参数。
• 动态化与灰度：通过下发路由表或配置，将某 path 指向新页面或活动页，实现 A/B 与降级。

功能唤醒类：

• 跨模块服务调用：路由表映射到「获取某 Service 实例」的 Provider（如 /service/user 返回用户服务），不打开页面。
• 能力/动作唤醒：如 /action/share 调起分享、/action/track 执行埋点、某 path 触发业务 Action，无需整页跳转。
• 弹窗/浮层唤醒：如 /modal/login 打开登录弹窗、/overlay/picker 打开选择器浮层，路由表映射到 openModal/openOverlay。
• 混合：同一 path 协议下，按路由项类型（page / action / service / modal）决定是打开页面还是唤醒功能。

8.1 应用场景与入口（泳道图）

flowchart TB
    subgraph 入口
        E1[App 内点击]
        E2[H5 / 运营链接]
        E3[推送 / 短链]
        E4[页面跳转诉求]
        E5[功能唤醒诉求]
    end
    subgraph 路由层
        R1[解析 path + query]
        R2[查路由表]
        R3[拦截器链]
        R4[按 type 分发]
    end
    subgraph 结果_页面跳转
        O1[打开 Native 页]
        O2[打开 H5 / WebView]
        O3[打开目标页并带参]
    end
    subgraph 结果_功能唤醒
        O4[返回 Service 实例]
        O5[执行动作 分享 埋点等]
        O6[打开弹窗 浮层]
    end
    E1 --> R1
    E2 --> R1
    E3 --> R1
    E4 --> R1
    E5 --> R1
    R1 --> R2 --> R3 --> R4
    R4 --> O1
    R4 --> O2
    R4 --> O3
    R4 --> O4
    R4 --> O5
    R4 --> O6

8.2 路由管理门面伪代码（通用逻辑）

以下给出「路由门面」的通用逻辑，各端可据此实现具体 Router 类。

类 Router:
  依赖: RouteTable table, InterceptorChain chain, PlatformAdapter adapter

  方法 navigate(path, params, options):
    1. result = table.lookup(path, params)
    2. 若 result 为 null，返回 false（或走兜底页）
    3. 遍历 chain 中拦截器（按 order 排序）:
        若 拦截器.process(result) 为 false:
          调用 拦截器.onInterrupt(result)
          返回 false
    4. 根据 result.type 分发（页面跳转 vs 功能唤醒）:
        若 type 为 service: 返回 adapter.resolveService(result)
        若 type 为 action: 返回 adapter.invokeAction(result)
        若 type 为 modal: adapter.openModal(result)；返回 true
        若 type 为 page: 若 options.mode 为 replace 则 adapter.replacePage(result)，否则 adapter.openPage(result)
    5. 返回 true

  方法 handleOpenURL(url):
    1. (path, params) = parseURL(url)   // 解析 scheme/host/path/query
    2. 若 path 为空，返回 false
    3. 返回 navigate(path, params)

---

九、小结与学习路径

• 基础：理解 Path、路由表、拦截器、深链接（Scheme / Universal Links / App Links）。
• 进阶：掌握编译期注解（APT）生成路由表、路由匹配算法与 Trie/树形优化。
• 高级：针对超级 App / 跨端统一产品的 SPI 按需加载、分层路由表、拦截器并行与熔断、编译期冲突校验与动态下发。

将「软件平台路由规则设计」视为协议 + 查找 + 执行链的统一模型，不限于移动端，涵盖 移动端、Web、电脑（桌面）、手表与手环等智能穿戴；同体系跨端跨平台协同依赖统一 path 协议与各端适配层，使同一链接多端一致打开、设备间可接力与状态同步，有助于在多端与多框架间迁移与选型。

9.1 路由方案选型指引（思维导图）

mindmap
  root((路由方案选型))
    仅 App 内跳转
      小项目 直接类名或简单 Map
      多模块 组件化路由表 + 拦截器
    需要外链打开 App
      Scheme 简单 易被拦截
      Universal Links / App Links 推荐 需域名
    需要与 Web 同构
      声明式 状态驱动栈
      Flutter go_router / Web Router
    同体系多端协同
      统一 path 协议 各端一致
      同一链接 多端打开 设备间接力
    千万级 DAU
      SPI 按需 分层表
      拦截器并行与熔断
      编译期校验 动态下发

---

延伸阅读（本专题详细展开）

以下专题文档在本文基础上分别展开，含多端代码示例、流程图、思维导图、泳道图，并给出通用路由管理工具组件的跨平台设计：

主题	文档
URL Scheme / Intent Filter	02-URL-Scheme与Intent-Filter详解
Universal Links / App Links	03-Universal-Links与App-Links详解
组件化路由框架	04-组件化路由框架详解
声明式路由与 Navigator 2.0	05-声明式路由与Navigator2.0详解
大规模与跨端路由体系	06-大规模与跨端路由体系详解
通用路由管理组件设计	07-通用路由管理组件设计
软件体系与多平台路由对照	08-软件体系与多平台路由对照

详见 00-README-软件平台路由规则设计-索引。

---

参考文献

[^1] AntDream. 从 ARouter 到自研框架：拆解千万级 APP 路由系统的 6 大核心设计. 腾讯云开发者社区, 2025. cloud.tencent.com/developer/a…

[^2] iOS 深度跳转（Scheme、Universal Link）. 极光社区 / CSDN 等.

[^3] Apple. Supporting Universal Links. Apple Developer Documentation.

[^4] Android. 创建深层链接 / App Links. Android 官方文档. developer.android.google.cn/training/ap…

[^5] 阿里云开发者社区. ARouter 功能介绍以及实现原理. 腾讯云 / 阿里云等转载.

[^6] Android 开源系列-组件化框架 Arouter-(三)APT 技术详解. 阿里云开发者社区. developer.aliyun.com/article/116…

[^7] Flutter. Understanding Navigator 2.0. Flutter 社区文档. docs.flutter.cn/community/t…

[^8] Flutter Navigator 2.0 的原理和 Web 端实践. 搜狐技术 / CSDN.

[^9] TheRouter. 页面跳转能力介绍. therouter.cn/docs/2022/0…

[^10] TanStack. How we accidentally made route matching more performant. TanStack Blog.

[^11] Flutter. 导航与路由 / Deep linking. docs.flutter.dev/cookbook/na…, docs.flutter.dev/ui/navigati…

[^12] DRouter：滴滴乘客端自研的 Android 路由框架. 百度开发者中心等.