然后通过一个统一的方式进行管理，这就是所谓的路由表。当应用进行跳转时，输入虚拟的地址，经过路由表进行查询得到实际的地址，然后就可进行跳转。并且有了这一层转换，我们就可以做很多扩展，例如降级、拦截等等

下面就让我们一起来看看一些业内的优秀实践。

业内优秀实践

[ARouter](

)

ARouter

《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》
浏览器打开：qq.cn.hn/FTe 免费领取

主要采用的也是路由表的方式，具体的使用和原理，网上有很多资料。这里主要列出官网上介绍的一些主要的功能。

• 支持直接解析标准 URL 进行跳转，并自动注入参数到目标页面中

• 支持多模块工程使用

• 支持添加多个拦截器，自定义拦截顺序

• 支持依赖注入，可单独作为依赖注入框架使用

• 映射关系按组分类、多级管理，按需初始化

支持用户指定全局降级与局部降级策略 页面、拦截器、服务等组件均自动注册到框架 支持多种方式配置转场动画

• 支持获取 Fragment

• 完全支持 Kotlin 以及混编

• 支持第三方 App 加固(使用 arouter-register 实现自动注册)

• 支持生成路由文档

• 提供 IDE 插件便捷的关联路径和目标类

更多详细的介绍和使用说明，可以参考[Github 上的介绍](

)

这里我们从 Github 上的介绍发现，同样采用了注解和 Gradle 插件在编译时生成文件，但 ARouter 并没有像 Hilt 那样有完善的测试套件支持，所以如果使用 Robolectric 在 JVM 上进行测试会有影响。

[DeepLinkDispatch](

)

DeepLinkDispatch 是 airbnb 开源的一个路由框架，原理也是采用路由表的方式。

提供声明性的、基于注释的 API 来定义应用程序深度链接。 可以注册一个 Activity 来处理特定的深度链接，方法是使用 @DeepLink 和 URI 对其进行注释。DeepLinkDispatch 将解析 URI 并将深度链接与 URI 中指定的任何参数一起发送到适当的 Activity。

相比之下，功能没有 ARouter 强大，且国内的社区活跃度没有 ARouter 高，具体的使用方式可以参考[官方的介绍](

)

CloudDisk 路由重构示例

经过对比，我们决定使用功能相对强大且社区活跃度高的 ARouter，对 CloudDisk 进行改造。具体的完整代码示例[Github](

)。这里我们贴出前后代码使用的比较。

改造前：

fragments.add(FileFragment.newInstance());

改造后：

//声明 @Route(path = "/bundle/file")public class FileFragment extends Fragment

//调用 fragments.add((Fragment) ARouter.getInstance().build("/bundle/file").navigation()）;

但当我们运行冒烟测试的时候发现出现空异常，如下

ARouter 的 navigation 并不能找到实例，上面我们有提到 ARouter 同样采用了注解和 Gradle 插件在编译时生成文件，但 ARouter 并没有像 Hilt 那样有完善的测试套件支持，在 JVM 上进行测试会有影响。这里我们采用的方案是 Shadow，将实际 ARouter 的跳转 Mock 掉。

@Implements(Postcard.class)public class ShadowPostCard {

@RealObjectpublic Postcard postcard;

@Implementationpublic Object navigation() {if ("/bundle/file".equals(postcard.getPath())) {try {return Class.forName("com.cloud.disk.bundle.file.FileFragment").newInstance();} catch (ClassNotFoundException | IllegalAccessException | InstantiationException e) {e.printStackTrace();}}return null;}}

我们还可以考虑把测试用例放入 androidTest，使用真机运行测试。但为了得到更快的反馈速度，我们决定先沿用 shadow 的方案。

总结

使用路由除了能解耦开编译时的依赖，统一了路由地址也能更好的满足应用的跳转场景。目前 CloudDisk 已经解耦了 lib 和 file bundle 2 个模块，并且基础的注入和路由也已经有了，下一篇单体移动应用“模块化”演进之旅（10）- 解耦重构演示篇（二）我们将继续分享对 platform、user、dynamic 进行依赖解除重构，将会分享更多的实战解耦手法。