Flutter路由管理代码这么长长长长长，阿里工程师怎么高效解决？（实用）

背景：

在flutter的业务开发过程当中，flutter侧会逐渐丰富本身的路由管理。一个轻量的路由管理本质上是页面标识（或页面路径）与页面实例的映射。本文基于dart注解提供了一个轻量路由管理方案。 
不管是在native与flutter的混合工程，仍是纯flutter开发的工程，当咱们实现一个轻量路由的时候通常会有如下几种方法：

1. 较差的实现，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)映射配置没法与页面联动，把页面级的配置进行中心化的维护，致使维护责任人缺失.

1. 通常的实现，手动维护的映射表： 
   稍微好一点的是将映射关系经过一个配置信息和一个工厂方法来表现

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 
刚开始介入时，咱们遇到了几个问题：

1. 只须要生成一个文件：因为一个输入文件对应了一个生成文件后缀，咱们须要避免多余的文件生成
2. 须要知道在何时生成文件：咱们须要在全部的备选文件扫描收集完成后再能进行映射表的生成
3. 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 ，在使用中遇到任何问题，欢迎向咱们反馈。

原文连接