滴滴开源DRouter：一款高效的Android路由框架(3)-CSDN博客

本文链接：https://blog.csdn.net/2401_84011132/article/details/138678198

随着业务不断的发展，业务变的种类繁多，项目代码集中且耦合在一起，导致编译速度慢、开发效率低、维护困难、牵一发动全身。这时无论是从工程效能还是业务迭代稳定性的角度考虑，都需要把项目代码拆分成独立的组件。当组件拆分后，在没有代码耦合的前提下，如何快速、方便、灵活的进行组件间跳转、数据通信、生命周期控制是DRouter要解决的问题。

支持的功能

使用URI字符串导航Activity、Fragment、View、RouterHandler
路由注解支持正则表达式、占位符
回调式onActivityResult
RouterHandler、Activity支持等待异步完成(hold)，并可设置超时时间
RouterHandler指定执行线程
注入拦截器，支持全局拦截器和局部拦截器，面向切面编程
更为多样化的Fragment页面跳转能力
使用接口或基类导航到实现类Service的Class以及实例
支持Service别名以及多维过滤器查找
导航Service可指定任意构造器、支持单例
支持动态注册RouterHandler、Service，绑定生命周期自动解绑
简单易用的跨进程执行RouterHandler、Service
跨进程访问无需提前绑定、如同本地调用一样进行访问
支持客户端进程和服务端进程自动重连
支持VirtualApk

2.为什么要开发DRouter

=================================================================================

滴滴乘客端包容万象，拥有众多的业务和组件，早在15年就已经启动组件化重构。使用滴滴自研的基于JavaSPI插件技术，动态的生成从接口到实现的映射关系，完成了组件化的通信功能，并且应用到了整个滴滴的Android体系中。虽然SPI性能优良、使用便捷，但同时功能单一、支持的场景少也是一直存在的问题。随着组件化实践的常态化，急需要一款功能强大，适合滴滴的场景，定制化程度高的路由框架。

目前市面上已经存在几款路由框架了，比如ARouter，WMRouter。不过滴滴业务繁多，平台化遍布各种场景，对路由的定制化需求强烈，很多功能市面上的路由是不支持的，比如：

ARouter作为路由的先行者，由于开发较早功能简单，路由查找过程性能损耗较大
WMRouter在路由的性能上仍然有一定优化空间，没有导航到Fragment/View、回调式ActivityResult，使用ServiceLoader稍显繁琐且无法动态注册以及多维过滤
现今没有一款路由框架对完整的跨进程和跨应用有较好的支持，这在滴滴定制车团队有着强诉求
同时没有一款路由对Fragment提供更多的扩展能力，DRouter在鸿鹄和车载屏项目以及更多Fragment的场景可以提供支持

基于以上问题，从2018年开始自研了DRouer路由框架，为滴滴的平台化服务几十种场景。

3.DRouter有哪些亮点

================================================================================

1. 插件增量编译、多线程扫描，运行时异步加载路由表

路由表在编译期通过插件动态生成。插件会启动多线程同时异步处理所有的组件；增量扫描功能可以帮助开发者在第二次编译时，只对修改过的代码进行处理，极大地缩短路由表生成的时间。

在本人的开发机上测试，19年滴滴乘客端扫描5.5万个类，全量需要不到6s的时间；如果是修改了application模块，增量扫描只需要处理修改的单类，耗时0.4s时间；如果是修改了library组件，增量扫描需要扫描整个jar包，根据jar包的大小时间会稍多一些，例如滴滴专快组件增量耗时3.9s。

另外框架初始化的时候启动子线程去加载路由表，不阻塞主线程的执行，尽其所能提高效率。

2. 完整的Router功能

支持使用URI字符串导航Activity、Fragment、View、RouterHandler，支持优先级、正则表达式、占位符、回调式onActivityResult、拦截器；RouterHandler还支持异步完成（不阻塞）、指定执行线程等等；同时针对Fragment，支持单Page、栈Page、ViewPager三种形式的Fragment加载。

3. 强大的ServiceLoader能力

DRouter同样是基于SPI的理念，路由表会生成接口或基类对实现类的映射。

获取实例时可以指定执行任意构造器、单例、优先级排序、自动拆解所有接口和基类作为key
可以通过alias，以及任意数量多的维度对目标进行过滤
动态注册

4. 像调用本地方法一样进行跨进程通信和回调

无需编写繁琐的aidl文件实现跨进程调用，使用方式几乎等同本地导航RouterHandler和Service，只需增加一些配置即可。

不需要异步去bindService等待，同步执行
支持跨应用
替代反射，服务端使用本地方法执行，提高执行效率
支持任意类型的对象跨进程传递，包括Context、自定义类，支持RemoteCallback回调
服务端异常崩溃重启后，客户端按需自动重新执行已发送的跨进程命令

5. 框架内部尽可能减少使用反射，提升性能

加载路由表、实例化路由、以及跨进程命令到达服务端后的分发这些常规应该使用反射的场景，使用预占位或动态生成代码来替换成java的new创建和显式方式执行，最大限度的去避免反射执行，提高性能。

考虑到功能的全面性，使用ServiceLoader时如指定非默认构造函数以及跨进程时传递自定义类，在框架内部会使用到反射，不过可以使用默认构造函数以及对跨进程对象实现Parcelable来避免。

6. 动态下载与api匹配的plugin，插件自升级

很多项目包括DRouter需要搭配gradle插件和java依赖来使用，正常来讲升级java依赖时大概率需要同时升级gradle插件，这在滴滴这种业务线繁多，各业务线除了有自己的组件同时又有自己的壳工程场景是一个非常痛的点。当业务线的组件因平台的同学在公共层升级了java依赖后，但又没有同时手动更新自己业务壳工程的gradle插件，大概率就会编译失败。

DRouter利用plugin-proxy壳插件来解决这个问题，壳插件会在编译期自动检查java依赖的版本，同时获得应该匹配的插件版本。接着plugin-proxy会去下载这个匹配的gradle插件，并最终执行。这样就解决了因升级java依赖而gradle插件不匹配导致的编译问题。

7. 无需手动添加混淆规则

DRouter把混淆规则隐藏到了java依赖里，当启用混淆功能时会自动应用混淆规则。这样即使升级了DRouter版本也无需关心混淆规则是否需要升级。

4.DRouter的原理和架构

=================================================================================

Architecture

架构设计

整体架构分三层，自下而上是数据流层、组件层、开放接口层。

1. 数据流层

数据流层是DRouter最重要的核心模块，这里承载着插件生成的路由表、路由元素、动态注册、以及跨进程功能相关的序列化数据流。所有的路由流转都会从这里取得对应的数据，进而流向正确的目标。

2. 组件层

这一层是功能组件层，核心的路由分发、拦截器、生命周期、异步暂存和监控、ServiceLoader、多维过滤、Fragment路由，以及跨进程命令打包等。

3. 开放接口层

DRouter在接口层做了大量的精简和优化，在灵活性和易用性方面做了很多权衡，主要目的是减少冗余API，使框架更为简单的使用和接入。比如Request和ServiceLoader作为最核心的API方法数非常少，一些不常用的功能会放到Extend中。

最后

总之啊，家里没矿的同学们，如果你们想以后的日子过得好一些，多想想你们的业余时间怎么安排吧；

技术方面的提升肯定是重中之重，但是技术外的一些“软实力”也不能完全忽视，很多时候升职确实是因为你的技术足够强，但也与你的“软实力”密切相关

在这我也分享一份大佬自己收录整理的 Android学习PDF+架构视频+面试文档+源码笔记 ，还有高级架构技术进阶脑图、Android开发面试专题资料，高级进阶架构资料这些都是我闲暇还会反复翻阅并给下属员工学习的精品资料。在脑图中，每个知识点专题都配有相对应的实战项目，可以有效的帮助大家掌握知识点。

总之也是在这里帮助大家学习提升进阶，也节省大家在网上搜索资料的时间来学习，也可以分享给身边好友一起学习