共计 4403 个字符，预计需要花费 12 分钟才能阅读完成。
背景：
在 flutter 的业务开发过程中，flutter 侧会逐渐丰富自己的路由管理。一个轻量的路由管理本质上是页面标识（或页面路径）与页面实例的映射。本文基于 dart 注解提供了一个轻量路由管理方案。不论是在 native 与 flutter 的混合工程，还是纯 flutter 开发的工程，当我们实现一个轻量路由的时候一般会有以下几种方法：
较差的实现，if-else 的逻辑堆叠：做映射时较差的实现是通过 if-else 的逻辑判断把 url 映射到对应的 widget 实例上，
class Router {
Widget route(String url, Map params) {
if(url == ‘myapp://apage’) {
return PageA(url);
} else if(url == ‘myapp://bpage’) {
return PageB(url, params);
}
}
}
这样做的弊端比较明显：1) 每个映射的维护影响全局映射配置的稳定性，每次维护映射管理时需要脑补所有的逻辑分支. 2) 无法做到页面的统一抽象，页面的构造器和构造逻辑被开发者自定义. 3) 映射配置无法与页面联动，把页面级的配置进行中心化的维护，导致维护责任人缺失.
一般的实现，手动维护的映射表：稍微好一点的是将映射关系通过一个配置信息和一个工厂方法来表现
class Router {
Map<String, dynamic> mypages = <String, dynamic> {
‘myapp://apage’: ‘pagea’,
‘myapp://bpage’: ‘pageb’
}
Widget route(String url, Map params) {
String pageId = mypages[url];
return getPageFromPageId(pageId);
}
Widget getPageFromPageId(String pageId) {
switch(pageId) {
case ‘pagea’: return PageA();
case ‘pageb’: return PageB();
}
return null;
}
在 flutter 侧这种做法仍然比较麻烦，首先是问题 3 仍然存在，其次是由于 flutter 目前不支持反射，必须有一个类似工厂方法的方式来创建页面实例。为了解决以上的问题，我们需要一套能在页面级使用、自动维护映射的方案，注解就是一个值得尝试的方向。我们的路由注解方案 annotation_route(github 地址:https://github.com/alibaba-flutter/annotation_route)) 应运而生，整个注解方案的运行系统如图所示：
让我们从 dart 注解开始，了解这套系统的运作。
dart 注解
注解，实际上是代码级的一段配置，它可以作用于编译时或是运行时，由于目前 flutter 不支持运行时的反射功能，我们需要在编译期就能获取到注解的相关信息，通过这些信息来生成一个自动维护的映射表。那我们要做的，就是在编译时通过分析 dart 文件的语法结构，找到文件内的注解块和注解的相关内容，对注解内容进行收集，最后生成我们想要的映射表，这套方案的构想如图示：
在调研中发现，dart 的部分内置库加速了这套方案的落地。
source_gen
dart 提供了 build、analyser、source_gen 这三个库，其中 source_gen 利用 build 库和 analyser 库，给到了一层比较好的注解拦截的封装。从注解功能的角度来看，这三个库分别给到了如下的功能：
build 库：整套资源文件的处理
analyser 库：对 dart 文件生成完备的语法结构
source_gen 库：提供注解元素的拦截 这里简要介绍下 source_gen 和它的上下游，先看看我们捋出来的它注解相关的类图：
source_gen 的源头是 build 库提供的 Builder 基类，该类的作用是让使用者自定义正在处理的资源文件，它负责提供资源文件信息，同时提供生成新资源文件的方法。source_gen 从 build 库提供的 Builder 类中派生出了一个自己的 builder，同时自定义了一套生成器 Generator 的抽象，派生出来的 builder 接受 Generator 类的集合，然后收集 Generator 的产出，最后生成一份文件，不同的派生 builder 对 generator 的处理各异。这样 source_gen 就把一个文件的构造过程交给了自己定义的多个 Generator，同时提供了相对 build 库而言比较友好的封装。在抽象的生成器 Generator 基础上，source_gen 提供了注解相关的生成器 GeneratorForAnnotation，一个注解生成器实例会接受一个指定的注解类型，由于 analyser 提供了语法节点的抽象元素 Element 和其 metadata 字段，即注解的语法抽象元素 ElementAnnotation，注解生成器即可通过检查每个元素的 metadata 类型是否匹配声明的注解类型，从而筛选出被注解的元素及元素所在上下文的信息，然后将这些信息包装给使用者，我们就可以利用这些信息来完成路由注解。
annotation_route
在了解了 source_gen 之后，我们开始着手自己的注解解析方案 annotation_route 刚开始介入时，我们遇到了几个问题：
只需要生成一个文件：由于一个输入文件对应了一个生成文件后缀，我们需要避免多余的文件生成
需要知道在什么时候生成文件：我们需要在所有的备选文件扫描收集完成后再能进行映射表的生成
source_gen 对一个类只支持了一个注解，但存在多个 url 映射到一个页面 在一番思索后我们有了如下产出
首先将注解分成两类，一类用于注解页面 @ARoute，另一类用于注解使用者自己的 router@ARouteRoot。routeBuilder 拥有 RouteGenerator 实例，RouteGenerator 实例，负责 @ARoute 注解；routeWriteBuilder 拥有 RouteWriterGenerator 实例，负责 @ARouteRoot 注解。通过 build 库支持的配置文件 build.yaml，控制两类 builder 的构造顺序，在 routeBuilder 执行完成后去执行 routeWriteBuilder，这样我们就能准确的在所有页面注解扫描完成后开始生成自己的配置文件。在注解解析工程中，对于 @ARoute 注解的页面，通过 RouteGenerator 将其配置信息交给拥有静态存储空间的 Collector 处理，同时将其输出内容设为 null，即不会生成对应的文件。在 @ARoute 注解的所有页面扫描完成后，RouteWriteGenerator 则会调用 Writer，它从 Collector 中提取信息，并生成最后的配置文件。对于使用者，我们提供了一层友好的封装，在使用 annotation_route 配置到工程后，我们的路由代码发生了这样的变化：使用前：
class Router {
Widget pageFromUrlAndQuery(String urlString, Map<String, dynamic> query) {
if(urlString == ‘myapp://testa’) {
return TestA(urlString, query);
} else if(urlString == ‘myapp://testb’) {
String absoluteUrl = Util.join(urlString, query);
return TestB(url: absoluteUrl);
} else if(urlString == ‘myapp://testc’) {
String absoluteUrl = Util.join(urlString, query);
return TestC(config: absoluteUrl);
} else if(urlString == ‘myapp://testd’) {
return TestD(PageDOption(urlString, query));
} else if(urlString == ‘myapp://teste’) {
return TestE(PageDOption(urlString, query));
} else if(urlString == ‘myapp://testf’) {
return TestF(PageDOption(urlString, query));
} else if(urlString == ‘myapp://testg’) {
return TestG(PageDOption(urlString, query));
} else if(urlString == ‘myapp://testh’) {
return TestH(PageDOption(urlString, query));
} else if(urlString == ‘myapp://testi’) {
return TestI(PageDOption(urlString, query));
}
return DefaultWidget;
}
}
使用后：
import ‘package:annotation_route/route.dart’;
class MyPageOption {
String url;
Map<String, dynamic> query;
MyPageOption(this.url, this.query);
}
class Router {
ARouteInternal internal = ARouteInternalImpl();
Widget pageFromUrlAndQuery(String urlString, Map<String, dynamic> query) {
ARouteResult routeResult = internal.findPage(ARouteOption(url: urlString, params: query), MyPageOption(urlString, query));
if(routeResult.state == ARouteResultState.FOUND) {
return routeResult.widget;
}
return DefaultWidget;
}
}
目前该方案已在闲鱼 app 内稳定运行, 我们提供了基础的路由参数，随着 flutter 业务场景越来越复杂，我们也会在注解的自由度上进行更深的探索。关于 annotation_route 更加详细的安装和使用说明参见 github 地址:https://github.com/alibaba-flutter/annotation_route，在使用中遇到任何问题，欢迎向我们反馈。
本文作者：闲鱼技术 - 兴往阅读原文
本文为云栖社区原创内容，未经允许不得转载。
