阿里ARouter源码分析

开源最佳实践：Android平台页面路由框架ARoute

ARoute源码分析

                

         上面2篇博客已经介绍了ARouter的原理和作用， 我补充一下自己的想法：

1、 ARouter应该是参考了SpringMVC， 通过URI字符串打开Activity/Service/Fragment。 

2、ARouter要缓存ApplicationContext或者当前Activity的上下文， 在打开Activity时必然遇到是否配置Intent.FLAG_ACTIVITY_NEW_TASK的问题， 影响正常的界面跳转逻辑；

3、ARouter使用静态变量缓存context， 如果保存的是Activity的上下文则必须要在Activity的onDestory函数里置空；

4、ARouter的核心作用就是通过URI找到类完整路径后反射并实例化。

5、ARouter使用了Android的APT技术，跟常用的ButterKnife原理是一样的； ARoute会在编译时动态注入uri和类完整路径的映射关系； 是由AutowiredProcessor,InterceptorProcessor和RouteProcessor这3个类实现的。

6、初始化ARoute时， 会反射出注解生成的类并拿到URI和类路径对应关系；

以ARouter源码的demo为例：

运行时加载映射关系：

以打开Activity为例， 出入路径URI后从Warehouse.routes里取出对应的类路径， postcard.getDestination()反射出类。

问题：ARouter真的适用于项目吗？

答：我觉得作用有限，即使是大型项目也不建议使用。我的理由：

1、 ARouter的核心是通过APT在dex文件中添加*$$*.java，配置并读取uri与类路径的对应关系； 说到底还是本地逻辑，不够灵活；

2、如果真想实现作者的解耦目的， 我建议通过后台接口实现； 即服务端配置uri和类路径的对应关系， 客户端通过网络连接获取并解析。 既能实现类之间的解耦， 也更加灵活可配置。

3、不适用于插件化的app， 因为ARouter无法打开未安装包中的组件， ARouter只能打开已安装app的组件；

ARouter的想法是好的， 即通过URI映射出类实例， 但由于是本地逻辑不够灵活， 应该做成像A/B Test那样使用网络接口配置uri对应哪个类。