共计 10928 个字符,预计需要花费 28 分钟才能阅读完成。
TheRouter 是什么
TheRouter 是货拉拉开源的 Android 平台中对页面、服务模块化整合开发、提供路由性能的中间件,提倡的是简略且够用。
Github: https://github.com/HuolalaTech/hll-wp-therouter-android
官网: https://therouter.cn
简略应用示例
Activtiy 跳转
TheRouter.build("http://therouter.cn/test/activity").withString("name", "姓名").navigation();
获取依赖服务
// 假如以后有一个用户信息获取服务
public interface IUserService {String getUserInfo();
}
// 服务提供方
@ServiceProvider(returnType = IUserService.class)
public static UserServiceImpl test() {xxx}
// 服务应用方
TheRouter.get(IUserService::class.java)?.getUserInfo()
次要代码构造
TheRouter
├─app
│ └──代码应用示例 Demo
├─business-a
│ └──用于模块化业务模块的演示模块
├─business-b
│ └──用于模块化业务模块的演示模块
├─business-base
│ └──用于模块化根底模块的演示模块
├─apt
│ └──注解处理器相干代码
├─plugin
│ └──编译期 Gradle 插件源码
└─router
└──路由库外围代码
外围源码剖析
TheRouter.build("http://therouter.cn/test/activity").withString("name", "姓名").navigation();
从最罕用的跳转开始剖析,根本可理解到 TheRouter 的运行原理。这行实现跳转的代码最终成果是携带参数跳转到对应的 Activity,在 Android 层面来说最初肯定是通过调用 startActivity 或是 startActivityForResult 来实现跳转。
分为几步来看:
- TheRouter 调用 Build 生成 Navigator,过程是怎么的
- Navigator 是什么
- Navigator 调用 navigation 是怎么执行到 startActivity 的
生成 Navigator
通过查看源码 TheRouter.build()
实际上调用的是 Navigator
的构造方法,
@JvmStatic
fun build(url: String?): Navigator {return Navigator(url)
}
而在构造方法外面,能够看到代码的实现比较复杂,但要害局部都有正文,根本都能看得懂,次要能够分为两局部:
- 拦截器批改 url
- 解析存储 url 上的参数
init {require(!TextUtils.isEmpty(url), "Navigator", "Navigator constructor parameter url is empty")
for (handle in fixHandles) {
handle?.let {url = it.fix(url)
}
}
uri = Uri.parse(url ?: "")
// queryParameterNames() 会主动 decode,造成内部逻辑谬误,所以这里须要依据 & 手动截取 k =v
uri.encodedQuery?.split("&")?.forEach {val idx = it.indexOf("=")
val key = if (idx > 0) it.substring(0, idx) else it
val value: String? = if (idx > 0 && it.length > idx + 1) it.substring(idx + 1) else null
// 通过 url 取到的 value,都认为是 string,autowired 解析的时候会做兼容
extras.putString(key, value)
}
}
Navigator 是什么
依据 官网文档的介绍 https://therouter.cn/docs/2022/08/28/01
TheRouter 的页面跳转都由 Navigator 导航器去操作的。
外部大抵能够分为四局部:
- ur/path 的解析与填充
- 路由表匹配
- 执行跳转
- 参数解析
参数的解析
我看的是 1.1.1-rc1
版本的代码,url 的解析基本上就是通过 uri 去解析的。看到正文上,写了一个老版本的问题:
uri = Uri.parse(url ?: "")
// for (key in uri.queryParameterNames) {
// // 通过 url 取到的 value,都认为是 string,autowired 解析的时候会做兼容
// extras.putString(key, uri.getQueryParameter(key))
// }
// queryParameterNames() 会主动 decode,造成内部逻辑谬误,所以这里须要依据 & 手动截取 k =v
uri.encodedQuery?.split("&")?.forEach {val idx = it.indexOf("=")
val key = if (idx > 0) it.substring(0, idx) else it
val value: String? = if (idx > 0 && it.length > idx + 1) it.substring(idx + 1) else null
// 通过 url 取到的 value,都认为是 string,autowired 解析的时候会做兼容
extras.putString(key, value)
}
下面被正文掉的代码就是老版本的解析,正文写的很分明,因为 uri.queryParameterNames() 会主动 decode,造成内部逻辑谬误,所以新版本就改成了依据 & 手动截取 k = v 的形式做了。
在执行解析 uri 之前,其实还做了一次拦截器的替换。
依照官网文档:Path 修改器的利用场景是用于修复客户端上路由 path 谬误问题。
例如:相对路径转绝对路径,或因为服务端下发的链接无奈固定 https 或 http,但客户端代码写死了 https 的 path,就能够用这种形式对立。
注:所有的拦截器必须在 TheRouter.build() 办法调用前增加处理器,否则解决前的 path 不会被批改。这个倒也正当。
for (handle in fixHandles) {
handle?.let {url = it.fix(url)
}
}
路由表
TheRouter 是个动静路由,所以路由表其实被弱化为一个很泛的概念了。
感觉有很多套路由表,最终都会被汇总到一个反对正则表达式的 Map 外面。
首先讲路由表的创立起源,我能找到的就是这四种:
- 从以后模块,通过 APT 解析 @Route 生成的
- 从依赖 aar 的路由表中读取的
- 从 json 文件中读取的
- 代码增加的路由表
APT 生成的路由表
先看第一种,最好了解的,就是注解处理器解析生成的。
@Route(path = "http://therouter.com/home", action = "action://scheme.com",
description = "第二个页面", params = {"hello", "world"})
public class HomeActivity extends AppCompatActivity {}
参数释义
- path: 路由 path【必传】。
倡议是一个 url。path 内反对应用正则表达式(为了匹配效率,正则必须蕴含反双斜杠 \),容许多个 path 对应同一个 Activity(Fragment)。 - action: 自定义事件【可选】。
个别用来关上指标页面后做一个执行动作,例如自定义页面弹出广告弹窗 - description: 页面形容【可选】。
会被记录到路由表中,不便前期排查的时候晓得每个 path 或 Activity 是什么业务 - params: 页面参数【可选】。
主动写入 intent 中,容许写在路由表中动静下发批改默认值,或通过路由跳转时代码传入。
AAR 依赖传递的路由表
所有的 aar,只有是蕴含有路由表的,都会有一个叫 RouterMap__TheRouter__202xxxxx
最初面是一段 hashcode。
这个文件其实在源码编译的时候也能找到,在 build/source/kapt/debug/a/RouterMap__TheRouter__202xxxxx
外面。
这个文件蕴含两局部:
ROUTERMAP
是一个 json 格局的路由表,上面的addRoute
办法,是路由表的代码实现,这应该也是为什么 TheRouter 能号称无反射的起因。
public static final String ROUTERMAP = "[{\"path\":\"http://kymjs.com/business_a/testinject\",\"className\":
\"com.therouter.demo.shell.TestInjectActivity\",\"action\":\"\",\"description\":\"\",\"params\":{}},{\"path\":\"http://kymjs.com/business_a/testinject3\",
\"className\":\"com.therouter.demo.shell.TestActivity\",\"action\":\"\",
\"description\":\"\",\"params\":{}},{\"path\":\"http://kymjs.com/business_a/testinject4\",\"className\":\"com.therouter.demo.shell.MultiThreadActivity\",
\"action\":\"\",\"description\":\"\",\"params\":{}},{\"path\":\"http://kymjs.com/therouter/demo_service_provider\",\"className\":
\"com.therouter.demo.shell.MainActivity\",\"action\":\"\",\"description\":\"\",\"params\":{}}]";
public static void addRoute() {com.therouter.router.RouteItem item1 = new com.therouter.router.RouteItem("http://kymjs.com/business_a/testinject","com.therouter.demo.shell.TestInjectActivity","","");
com.therouter.router.RouteMapKt.addRouteItem(item1);
com.therouter.router.RouteItem item2 = new com.therouter.router.RouteItem("http://kymjs.com/business_a/testinject3","com.therouter.demo.shell.TestActivity","","");
com.therouter.router.RouteMapKt.addRouteItem(item2);
com.therouter.router.RouteItem item3 = new com.therouter.router.RouteItem("http://kymjs.com/business_a/testinject4","com.therouter.demo.shell.MultiThreadActivity","","");
com.therouter.router.RouteMapKt.addRouteItem(item3);
com.therouter.router.RouteItem item4 = new com.therouter.router.RouteItem("http://kymjs.com/therouter/demo_service_provider","com.therouter.demo.shell.MainActivity","","");
com.therouter.router.RouteMapKt.addRouteItem(item4);
}
从 json 文件读取的路由表
TheRouter 我的项目每次编译后,会在 apk 内生成一份路由表,默认门路为:/assets/therouter/routeMap.json
同时这份路由表也反对远端动静下发,例如远端能够针对不同的 APP 版本,下发不同的路由表达到配置目标。因而有两种举荐的形式可供使用方抉择:
- 将打包零碎与配置零碎买通,每次新版本 APP 打包后主动将 assets/ 目录中的配置文件上传到配置零碎,下发给对应版本 APP。长处在于全自动不会出错。
- 配置零碎无奈买通,线上手动下发须要批改的路由项,因为 TheRouter 会主动用最新下发的路由项笼罩包内的路由项。长处在于准确,且流量资源占用小。
注:一旦你设置了自定义的 InitTask,原框架内路由表初始化工作将不再执行,你须要本人解决找不到路由表时的兜底逻辑,一种倡议的解决形式见如下代码。
// 此代码 必须 在 Application.super.onCreate() 之前调用
RouteMap.setInitTask(new RouterMapInitTask() {
/**
* 此办法执行在异步
*/
@Override
public void asyncInitRouteMap() {
// 此处为纯业务逻辑,每家公司远端配置计划可能都不一样
// 不倡议每次都申请网络,否则申请网络的过程中,路由表是空的,可能造成 APP 无奈跳转页面
// 最好是优先加载本地,而后开异步线程加载远端配置
String json = Connfig.doHttp("routeMap");
// 倡议加一个判断,如果远端配置拉取失败,应用包内配置做兜底计划,否则可能造成路由表异样
if (!TextUtils.isEmpty(json)) {List<RouteItem> list = new Gson().fromJson(json, new TypeToken<List<RouteItem>>() {}.getType());
// 倡议远端下发路由表差别局部,用远端包笼罩本地更正当
RouteMap.addRouteMap(list);
} else {
// 在异步执行 TheRouter 外部兜底路由表
initRouteMap()}
}
});
执行跳转
执行跳转的次要办法总共有三个,别离是:跳转到 Activity、获取跳转的 Fragment、获取跳转的 Intent。
次要逻辑都差不多,咱们次要看 Activity 的跳转。
代码很长,我就不全贴了。Activity 的跳转分五个局部:
- 判断是否提早跳转
- 拦截器解决
- 解析跳转的路由表
- 执行跳转
- 跳转页面参数解析
提早跳转
提早跳转是个比拟翻新的设计,装置官网的说法,提早跳转次要利用场景有两种:
- 第一种:初始化期间,如果路由表的量十分微小时。这种状况在别的路由框架上要么会白屏一段时间,要么间接抛弃这次跳转。在 TheRouter 中,框架会暂存以后的跳转动作,在路由表初始化实现后立即执行跳转。
- 第二种:从 Android 8.0 开始,Activity 不能在后盾启动页面,这对于业务判断造成了很大的影响。因为可能会有前台 Service 的状况,不能单纯以 Activity 生命周期判断前后台。在 TheRouter 中,框架容许业务自定义前后台规定,如果为后盾状况,能够将跳转动作暂存,当进入前台后再复原跳转。
// 暂存的动作能够有多个,会在复原时按程序执行
TheRouter.build("http://therouter.com/home")
.withInt("key1", 12345678)
.padding()// 暂存以后跳转动作
.navigation(context);
// 复原
//toplevel 办法,无需类名调用,Java 请通过 NavigatorKt 类名调用
sendPendingNavigator();
又是拦截器
在这一步其实是有两个拦截器,一个是在路由表解析之前,一个是在路由表解析之后。
这里我就一起讲了。
- 路由表解析之前的,叫 页面替换器
利用场景:须要将某些 path 指定为新链接的时候应用。也能够用在修复链接的场景,然而与 path 修改器不同的是,修改器通常是为了解决通用性的问题,替换器只在页面跳转时才会失效,更多是用来解决个性问题。
例如模块化的时候,首页壳模板组件中开发了一个 SplashActivity
广告组件作为利用的 MainActivity,在闪屏广告完结的时候主动跳转业务首页页面。然而每个业务不同,首页页面的 Path 也不雷同,而不心愿让每个业务线本人去改这个首页壳模板组件,此时就能够组件中先写占位符https://kymjs.com/splash/to/home
,让接入方通过 Path 替换器解决。
Navigator.addPathReplaceInterceptor(new PathReplaceInterceptor() {
@Override
public String replace(String path) {if ("https://kymjs.com/splash/to/home".equals(path)) {return "https://kymjs.com/business/home";}
return path;
}
});
2 . 路由表解析之后的,叫 路由替换器
利用场景:罕用在未登录不能应用的页面上。例如拜访用户钱包页面,在钱包页申明的时候,能够在路由表上申明本页面是须要登录的,在路由跳转过程中,如果落地页是须要登录的,则先替换路由到登录页,同时将原落地页信息作为参数传给登录页,登录流程解决实现后能够继续执行之前的路由操作。
路由替换器的拦挡点更靠后,次要用于框架曾经从路由表中依据 path 找到路由当前,对找到的路由做操作。
这种逻辑在所有页面跳转前写不太适合,以前的做法通常是在落地页写逻辑判断用户是否具备权限,但其实在路由层实现更适合。
Navigator.addRouterReplaceInterceptor(new RouterReplaceInterceptor() {
@Override
public RouteItem replace(RouteItem routeItem) {if (user.age() < 18 && routeItem.getClassName().contains("ChildrenProhibitActivity")) {RouteItem target = new RouteItem();
target.setClassName(HomeActivity.class.getName());
String[] path = {"https://kymjs.com/too/young"};
target.setPathArray(path);
target.setDescription("也能够在这里批改原有路由的参数信息");
return target;
}
return routeItem;
}
});
解析跳转的路由表
导航器跟路由表的交互,最外围的办法就是这个 match 办法,他是负责将一个 url 转换成 TheRouter 路由项的次要办法。
@Synchronized
fun matchRouteMap(url: String?): RouteItem? {var path = TheRouter.build(url ?: "").simpleUrl
if (path.endsWith("/")) {path = path.substring(0, path.length - 1)
}
// copy 是为了避免内部批改影响路由表
val routeItem = ROUTER_MAP[path]?.copy()
// 因为路由表中的 path 可能是正则 path,要用入参替换掉
routeItem?.path = path
return routeItem
}
最初的跳转
最终的跳转,实质上还是调用的 context.startActivity 去做的,所以所有 Activity
的跳转办法,TheRouter 也都反对。
if (fragment != null) {debug("Navigator::navigation", "fragment.startActivity ${routeItem.className}")
fragment.startActivity(intent)
} else {debug("Navigator::navigation", "startActivity ${routeItem.className}")
context.startActivity(intent)
}
val inAnimId = routeItem.getExtras().getInt(KEY_ANIM_IN)
val outAnimId = routeItem.getExtras().getInt(KEY_ANIM_OUT)
if (inAnimId != 0 || outAnimId != 0) {if (context is Activity) {debug("Navigator::navigation", "overridePendingTransition ${routeItem.className}")
context.overridePendingTransition(routeItem.getExtras().getInt(KEY_ANIM_IN),
routeItem.getExtras().getInt(KEY_ANIM_OUT)
)
} else {if (TheRouter.isDebug) {throw RuntimeException("TheRouter::Navigator context is not Activity, ignore animation")
}
}
}
跳转的回调
如果应用 TheRouter 跳转,传入了一个不辨认的的 path,则不会有任何解决。你也能够定义一个默认的全局回调,来解决跳转状况,如果落地页是 Fragment 则不会回调。
当然,跳转后果的回调不止这一个用处,能够依据业务有本人的解决。
回调也能够独自为某一次跳转设置,navigation()办法有重载能够传入设置。
NavigatorKt.defaultNavigationCallback(new NavigationCallback() {
// 落地页 Activity 关上后,执行到 onCreate 会回调
@Override
public void onActivityCreated(@NonNull Navigator navigator, @NonNull Activity activity) {super.onActivityCreated(navigator, activity);
}
// startActivity 执行后会立即回调
@Override
public void onArrival(@NonNull Navigator navigator) {super.onArrival(navigator);
}
// 找到待跳转的落地页时就会回调(startActivity 之前)@Override
public void onFound(@NonNull Navigator navigator) {super.onFound(navigator);
}
// 找不到落地页的时候会回调
@Override
public void onLost(@NonNull Navigator navigator) {super.onLost(navigator);
}
});
页面参数解析
TheRouter 的所有页面跳转参数解析都能够通过 @Autowired
解析的,当然也能通过 Intent
去解析。Intent 解析咱们都会,就不说了,上面讲一下 @Autowired
的实现。
所有加了 @Autowired
注解的类,在编译当前都会生成一个独自的工具类,XXX__TheRouter__Autowired
,这个类就是用来填充变量内容的。实际上咱们调用的inject()
办法:
TheRouter.inject(this);
就会间接调用生成类去做填充变量。
而这个填充过程的实现,实际上是由 AutowiredParser
去实现的。
这个 Parser 是容许咱们自定义的,也就是说如果咱们心愿替换掉 TheRouter 的解析,也能够通过自定义的形式实现对 @Autowired
的解析。TheRouter 内默认的解析形式是这样的:
class DefaultUrlParser : AutowiredParser {override fun <T> parse(type: String?, target: Any?, item: AutowiredItem?): T? {if (item?.id != 0) {return null}
when (target) {
is Activity -> {return parseValue(target.intent?.extras?.get(item.key), type) as T?
}
is Fragment -> {return parseValue(target.arguments?.get(item.key), type) as T?
}
is androidx.fragment.app.Fragment -> {return parseValue(target.arguments?.get(item.key), type) as T?
}
}
return null
}
private fun <T> parseValue(value: Any?, type: String?): T? {if (value == null || type == null) {return null}
if (value.javaClass.name.equals(transformNumber(type), true)) {return value as T?}
if (value.javaClass.name.equals("java.lang.String")) {
try {return transform(type, value.toString()) as T?
} catch (e: NumberFormatException) {}}
return null
}
}
其余 API
判断一个 url 是否为路由 Path
如果返回为空,示意以后 url 不是路由表内的 path
// kotlin toplevel 办法,Java 调用请应用 RouteMapKt 类
matchRouteMap("url 填这里") == null